# Order Intake - Cockpit The Order Intake value stream automates the processing of orders submitted through the [Order Intake Cockpit](https://app.gitbook.com/o/z8MNPigQv25NZe33g3AV/s/NXembrzntBOyi7ynrVRB/), where they can also be managed and tracked. It enables users to capture incoming orders by uploading purchase order documents and providing minimal required data. ## Process template flow The process begins when an operator uploads an order document in the Order Intake Cockpit, or when a new email with order is received. The system collects the attached documents and the intake metadata provided by the operator. AI-based components interpret the input, extract order details, and validate the resulting normalized order model: * If validation succeeds, the template transfers the order into the connected systems. * If validation fails, the process creates an exception item that users can review and resolve. ## Process triggers The process is configured with two triggers. When either trigger condition is met, the process is initiated and the subsequent steps are executed.

The available triggers are: * **New Order Data event** The process starts when a New Order Data event is received. This event is typically generated from an incoming email containing an order and its associated attachments. * **Media asset created** The process can also be triggered when a media asset in a PDF format is uploaded to the Order Intake Cockpit.

Additional filters can be configured for the trigger to control which uploads initiate the process, for example a filter for the media asset:

This filter limits the `Media asset created` trigger to files that are linked to order intake data. The condition is true if the first reference entry has the `ORDER_INTAKE_DATA` type. If the value matches, the process starts. If not, the upload is ignored by this trigger. ## Conditional media asset check The conditional step determines how the process should continue based on the media asset type from the trigger payload. The condition evaluates `context:'media.asset-created'.type` and routes the flow through one of two paths so that the file-based intake scenarios are handled correctly.

When the media asset type is `null`, the process continues on the default path without invoking additional file handling. When the media asset type is `BLOB` (Binary Large Object), the process routes execution to the Media Asset Handler step, where the uploaded file is prepared for downstream extraction and validation. After either path is completed, the flow merges back into the main process and proceeds to customer, product, and price validations. ## Customer, product and price validations When the order is placed, it has to include customer, shipping and billing addresses, product and price data for all the ordered items. After the media asset is checked the process continues to the next points. First, the process validates the customer using the identifiers available in the payload. If no customer data is present, validation cannot continue and the customer remains unvalidated. If a customer ID is provided, validation runs by ID first, and if the ID check fails while an email is available, the process retries validation by email. Then, the process validates each ordered product and checks availability. For each line item, the process checks whether the product exists in the catalog and whether it is available for ordering. Based on this evaluation, the items are grouped into products that are available, not found, or out of stock. If products cannot be identified, they are flagged in the document for review. If products are identified but are out of stock, the process searches for alternative products and generates suggestions using a RAG database. The document can then be reviewed and updated in the Order Intake Cockpit. The next step is the valdidation of price availability for each product. This check requires a valid price for each product in scope. If a price is missing for any item, the process still completes the step but marks the product-level pricing status accordingly.

### Conditional branching routing The conditional logic is applied to evaluate extracted data and determine the appropriate execution path. Based on predefined conditions, the process follows one of several outcomes to ensure that all required information is available and aligned with system requirements. Customer-related conditions are evaluated first. If a matching customer is identified, the corresponding data is loaded and the appropriate legal entity is assigned. If no match is found, the process attempts to create a new customer record using the available data. When sufficient customer information (such as address details) is provided, the creation is performed automatically. Otherwise, the process requires manual input to complete the customer setup. Product-related conditions are handled in a similar way. If products are successfully identified, relevant product data is prepared for further processing. If no matching products are found, the system prepares alternative suggestions and flags the items for review. These conditional steps ensure that incomplete or unmatched data is handled appropriately while allowing valid cases to proceed without interruption.

Conditional step in the loop with five paths — Conditional step with five paths

The available paths are defined through configurable conditions based on variables, operators, and values, allowing the process behavior to be adapted to specific business requirements.

{% hint style="info" %} For step filters, conditional steps, and looping in value streams, see [Conditions](https://developer.emporix.io/value-stream-modeller/value-stream-designer/process-components/conditions). {% endhint %} ### Order creation in Emporix Once all required validation conditions are met, the process enters the order creation sequence visible in the flow. The first step, `Match Prices`, confirms that the final order lines have valid and consistent prices for processing.

After prices are matched, the process executes the cart preparation, where the validated order data is converted into a cart payload that can be submitted for order placement. The flow then reaches order form submission, which acts as the approval checkpoint in this template. In this value stream, this approval is completed directly in the Order Intake Cockpit. In the cockpit, you can view the results of processing the uploaded document, for example missing customer details or product substitutions. There, you can manage the changes and submit the order.

Document management in Order Intake Cockpit

When the Cockpit approval action is submitted, the process continues and creates the order in Emporix, where the finalized cart is converted into an order. The order is also visible directly in the Order Intake Cockpit and in the Management Dashboard.

{% hint style="info" %} Order Intake implementations must be tailored to each project, with the goal of reducing manual effort, accelerating processing, and ensuring that incoming order data remains consistent and reliable. {% endhint %}