Order Intake - Forms
Automate order intake from structured forms and uploaded documents.
The Order Intake value stream with forms automates purchase orders submitted through PDF documents. The process extracts order intent and order details from submitted inputs, validates the extracted data against predefined business rules, and creates only validated orders. It routes orders with missing or inconsistent data to users, providing full context for correction. When items are invalid or unavailable, the system uses AI capabilities to suggest alternatives.
This template uses approval forms as part of the decision flow and includes Make scenarios in the steps.
Process template flow
The process starts when order data is received by email and transformed into a normalized structure. The system validates customer, product, and pricing data in sequence, then branches based on the validation results. If all required conditions are met, an approval form is generated and sent to designated users. After approval, the order is created in Emporix.
Each step in the flow has explicit events, conditions, and outcomes so that the process can run automatically for standard cases and route only exceptions for manual action.
Process trigger
The process starts when a New Order Data event is received, this comes from an incoming email with a Purchase Order attachment. The attachment should contain sufficient company and customer data, and the payload should be transformable to the target order model. As a result, the process produces a normalized order payload and passes it to the validation loop.
The order placed in PDF format can look like in this demo example:
The process tigger is build of a Make scenario that includes received email processing. To make the trigger work, make sure you have the relevant Gmail and Google Gemini Make modules configured properly.
Remember to always Save your Make modules configurations.
Gmail and incoming orders
Configure the Gmail module with the mailbox address that should be used for receiving purchase orders. When a sender emails an order request to that address, the scenario starts and the flow can process the message and attachments.
Google Gemini order extraction
The trigger scenario also includes the Google Gemini module. You must have a configured connection and token using API credentials from your Google AI account (Google AI Studio or the Gemini API keys area for your project). Create or import an API key there, then wire it into the integration’s Gemini Make module's connection so requests are authorized. The AI module is used to parse the order information into a valid JSON format, out of the attached PDF in the emailed order request.
In this case, we use Gemini 2.5 Flash as the model in the Make module URL settings, for example: /v1beta/models/gemini-2.5-flash:generateContent.
You need your own Google account with access to the Gemini API (for example through Google AI Studio) so you can create API keys and authorize the Gemini connection for your environment.
Retrieving approvers
In this example, the process retrieves users from the CE Manager group to identify order approval recipients, required later during the process. Only the users listed in this group can process and submit forms during order creation.
This step requires that the CE Manager group exists and that at least one user is available to receive notifications. When these conditions are met, the process prepares the approval recipient list for the later form-based approval step.
Validation loop
The steps configured in the validation loop check customer, product, and pricing data, and raise completion events after each stage. Then, they evaluate predefined conditions to determine the next actions required to complete the order. During the first process run, the steps in the loop execute as in a standard process. The loop then runs in repeated validation cycles, triggered when alternative customer data is selected. After each cycle, the process evaluates whether all required data is complete and valid. If anything is still missing or inconsistent (such as customer details, product matches, or pricing prerequisites), the process routes the order to correction paths, including the form being resent for approval. The loop stops only when all required checks pass and the approved order form is submitted allowing the process to continue to order creation.
The order-check condition value that is set up for the loop comes from validation outputs produced inside this flow during the Check form input step, not from an external trigger. It is computed from the latest customer, product, pricing, and form-submission data used by the configured condition rules. In this template, the context.order.data.checked.runLoop condition variable must evaluate to true for that loop iteration to run. When it is false, that iteration does not start and the scenario follows the configured branch instead.
Customer, product and price validations
When the order is placed, it should include customer, shipping and billing addresses, product and price data for all the ordered items. 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 the ID first, and if the ID check fails, 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's available for ordering. Based on this evaluation, the items are grouped into products that are available, not found, or out of stock. If products are identified but are out of stock, the process searches for alternative products and generates suggestions.
The next step is the validation 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. Where the design requires it, price matching depends on having a resolved customer.
Conditional routing within the loop
Within the processing loop, conditional logic is applied to evaluate extracted data and determine the appropriate execution path: continue automatically, enrich data from the document, ask for manual input, suggest products with AI, or route to the email form for another pass.
Customer: The process loads master data when the incoming data matches an existing customer. If there is no existing customer but the PDF contains enough customer details, those details are used to add the customer in the system automatically. If the required customer information is not present in the PDF, the customer has to be added manually in the Management Dashboard.
Products: Product paths depend on whether each line matches the catalog. When a confident match is not possible, routing adds AI product substitution suggestions so the order approver can select alternatives before the flow continues.
Price, currency, country, and addresses: Once customer and product context is in place, the process checks the pricing, currency, country, and addresses (shipping and billing). Country and address details are validated against the legal entity data. Currency checked with customer data, and prices with the products.
When customer or other mandatory data is still missing or invalid, routing sends the order form to approvers by email. Updating and submitting the form by the approvers supplies new values for the checks. The process runs the validation loop again on that input. A customer email address must be present or added where required so notifications and the form-driven loop work correctly.
When these branches and the form approval steps complete successfully, processing continues to order placement in Emporix.
These conditional steps ensure that incomplete or unmatched data is handled appropriately while allowing valid cases to proceed without interruption.
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.
For step filters, conditional steps, and looping in value streams, see Conditions.
Order confirmation form submission
Once all required validation conditions are met, the process proceeds with the generation of an order form for review and approval. The form is resent when after each loop run.
The form includes a consolidated summary of the extracted and validated data, such as customer details, identified products, and quantities. Together with the customer data, it contains dedicated shipping and billing address sections, and both are mandatory for completion. If those details are missing in the original order email, they can be selected manually in the form.
Using the form the approver can provide alternative customer details (e-mail address), then, the process restarts the full validation loop and checks customer, product, and pricing data again before continuing.
If none of the addresses is selected as Use this address, the system automatically takes the address that is market as MATCHED by AI.
If the products were not matched, the form includes suggested products that users can add directly in the form, similar to the Order Intake Cockpit behavior. The order approvers can either add suggested products to the order, or skip them. The suggested products are not ordered until added to the products list.
At this stage, a mid trigger event - Order Form Submitted - is used to pause execution until a response to the form approval is received. The process resumes once the submitted form is returned. When all the details in the form are correct the approver chooses to Submit the form.
The final step is the validation of the submitted form. Whenever the approval form is submitted or edited, the process validates the submitted content again. If all items are confirmed and validation succeeds, the order is approved and processing continues. If validation still finds missing, inconsistent, or incorrect data, the process re-enters the loop to resolve outstanding issues and repeat the validation and approval steps.
Order creation in Emporix
Once all validation and approval steps within the loop are completed, the process proceeds with order creation in Emporix.
This step requires a from submitted by the approver with the complete customer, product, and pricing data. When these conditions are met, a cart is created in the background and converted into an order using the finalized payload. You can already check your order in the Management Dashboard.
Last updated
Was this helpful?