Checking orders against stock and pricing rules before they reach fulfillment
Orders arrive from several channels in several shapes, and the expensive errors are the quiet ones — a price that should not have applied, stock committed twice, a discount nobody approved. Modeled as an orchestrated process, every order is checked against availability and the pricing rules before it reaches fulfillment, and only the orders that genuinely breach a rule are escalated.
A reference architecture: how RoboAgentix would model this process on UiPath. It is not a description of a delivered project, and no client, result or metric is implied.
What starts it
An order is placed through a storefront, a marketplace, a sales team, or an EDI feed.
Why it is orchestrated rather than scripted
- Channels deliver orders in different formats and at different times, but the rules that govern them should be one set.
- Stock changes while the order is being checked, so the availability decision has to be made against live data and held.
- Pricing exceptions are commercial decisions, and who approved a discount is a question that gets asked later.
How it runs on UiPath Maestro
The process is defined in BPMN and Maestro runs it across agents, robots and people, holding its state for as long as the work takes — including while it waits on an approver.
Step by step
- 01
Order placedSystem
From a storefront, marketplace, sales team, or EDI feed, normalized into one order structure.
- 02
Validate the orderAgent
Customer, addresses, line items and quantities are checked for completeness and internal consistency.
- 03
Check stock and pricingAgent
Availability is confirmed against live inventory, and each line is checked against the price list, contract terms and discount rules.
- 04
Within the rules?Maestro
The orchestrator routes on availability, on margin, and on whether any discount exceeds what the channel allows.
- 05
Commercial reviewPerson
Anything short on stock or outside pricing rules reaches the right owner with the order and the breach attached.
- 06
Commit and releaseRobot
Stock is committed, the order is released to fulfillment, and the confirmation is written back to the channel.
- 07
Systems updatedSystem
Order, inventory and channel all reflect the same state, and the decisions are written to the audit record.
What each agent is allowed to decide
An agent is only useful in a governed process if its authority is written down. Each one below has a defined input, a decision it may make on its own, and the condition that obliges it to hand over.
Order Validation Agent
Decides whether the order is complete and coherent before anything is committed.
Reads
- The normalized order
- Customer and account records
- Product catalog and valid configurations
Decides on its own
Must escalate when
Pricing and Availability Agent
Checks what the order costs and whether it can actually be met.
Reads
- Live inventory and inbound stock
- Price list, contract pricing and discount rules
- Margin floors for the channel
Decides on its own
Must escalate when
What the robots do
Deterministic steps stay with robots — the same action every time, including in systems that never exposed a usable API.
Commitment robot
Commits stock, releases the order to fulfillment, and confirms back to the originating channel.
Runs in
Within the rules?
Stock covers every line, each line prices within its rules, and no discount exceeds the channel's limit.
- Passes
- Committed and released to fulfillment.
- Does not pass
- Held for commercial review, with stock reserved or released according to policy.
Modeled as a decision table, so the threshold can be changed by the people who own the policy without redeploying an automation.
The human step
Who
What they see
What they decide
People are in this process because judgment or authority belongs to them — not as a fallback for a step that failed.
What this design deliberately does not do
An automation is only trustworthy if its limits are written down as plainly as its capabilities.
- It does not reprice anything. The price list, contract pricing and discount rules are read as they stand; a line that falls outside them is escalated, never quietly moved to a price that would pass.
- It does not arbitrate between orders competing for the same units. Where the order management system holds an allocation rule, that rule decides; where it does not, the shortfall goes to a person rather than to whichever instance checked first.
- It does not make the credit decision. Account status is read as the finance system holds it, and a blocked or on-hold account stops the order — the agents are not permitted to release against their own view of the customer.
- It stops at release. Picking, packing, carrier choice and anything else the warehouse owns stay outside the process; what it commits is stock and a released order, not a shipment.
Failure has a defined path
Systems go down, confidence drops, approvers go on leave. Each of these is a modeled branch rather than a stuck instance.
- The inventory system does not answer, or returns a position older than the freshness the availability check requires.
- Nothing is committed. The instance holds at the availability step on an Orchestrator queue and retries; the order stays in received state and the channel is told it is being checked, not that it is confirmed. Only when a live position comes back does the gate evaluate.
- The Pricing and Availability Agent cannot settle which rule governs a line — two price agreements cover it, or the contract term is ambiguous.
- The line is marked unresolved rather than priced under the reading that would pass. The order routes to commercial review with both candidate rules and the clause each was retrieved from, and the approver picks one on the record.
- A commercial owner does not act, and the stock reservation the instance holds is due to lapse.
- The reservation is extended or released according to the rule set for that channel, the channel is notified of the change in state, and the task is reassigned to the next owner in the escalation chain. The instance stays open. Nothing auto-approves on a timer.
- Stock is committed but the confirmation write-back to the originating channel fails.
- The instance does not close. The commitment is recorded as done so no retry can double-commit, the write-back is retried on its own, and if it still fails the case goes to an operations owner showing the quantity already committed and the channel still unconfirmed.
Data, rollout, and what to watch
Data it touches
- Payment instrument data is out of scope. The channel collects it; what enters the process is a payment status and a reference, and no agent, robot or task in the flow is given more than that.
- Customer records, delivery addresses and order lines stay in the region the order management and inventory systems run in. The retrieval index over pricing terms is built in the same region, so a contract clause is never resolved outside it.
- The escalation task in Action Center shows what the decision needs. A commercial owner reviewing a discount sees the line, the rule and the margin position; delivery address and contact details are withheld unless the exception is about the address itself.
- Raw channel payloads are kept as received, in their original shape, for the period the organization's own records policy sets for order evidence. The normalized order, the availability position at the moment of the check and the decision record persist with the instance for as long as the audit record does.
How it goes live
- 01
Shadow
The process runs beside the live order flow. Orders are normalized, availability is read and every line is priced, but nothing is committed and nothing is released — the existing path still fulfills the order. Each instance leaves a decision the order desk's own outcome can be compared against. The gate out is disagreement worked down to cases the team accepts: where the process would have escalated and the desk did not, or the reverse, the tolerance or the discount rule in the decision table is changed until the remaining differences are ones the commercial owner is willing to defend.
- 02
Supervised
The process commits and releases, but every instance lands in Action Center first, including the ones that clear the gate cleanly. The approver sees what is about to be committed and either releases it or sends it back. Channels move out of this phase one at a time, and a channel moves when its own clean-pass instances are being released without amendment — not when the estate as a whole looks settled.
- 03
Unattended with exceptions
Orders that satisfy availability and the pricing rules commit and release without a person. Only shortfalls, lines under the margin floor and discounts above the channel limit reach a commercial owner. A channel can be returned to supervised by changing the routing in the decision table, with no redeployment of the process, which is what makes it safe to add a new marketplace or EDI partner.
Signals worth watching
- The share of orders that reach a commercial owner, split by channel and by which rule was breached — and whether one channel is drifting away from the others.
- How much stock is reserved against instances that are waiting on an approver, and how long those reservations have been held.
- The difference between the availability position recorded at the check and what was actually there when the order was picked, since that gap is what turns a clean release into a backorder.
- Repeat escalations on the same product, customer or contract — a rule that keeps producing exceptions is usually a price list that no longer matches what is being sold.
Named without target values. What good looks like depends on your volumes and your risk appetite, and is set with you rather than asserted here.
The UiPath components this design uses
UiPath Maestro
Runs the BPMN process and holds its state for as long as the work takes, including while it waits on a person or a system that is down.
UiPath Agent Builder
Where each agent is defined — its instructions, its tools, its inputs and outputs, and the escalation that sends work to a person.
Context Grounding
A retrieval index over your own policies and reference data, so an agent cites the rule it applied instead of recalling it.
UiPath Action Center
Where a human step actually lands. The approver gets a task with the agent's reasoning and sources attached, and the process resumes on their decision.
UiPath Orchestrator
Schedules the robots, holds queues and retries, and issues the least-privilege credentials each automation runs under.
UiPath Integration Service
Connectors to the systems of record, so the process talks to them through a maintained integration rather than a bespoke script.
Systems it touches
- Order management
- Inventory and warehouse systems
- Pricing and contract data
- Storefront, marketplace or EDI channel
What the run leaves behind
- The order as received from each channel, before normalization
- The availability position at the moment it was checked
- Every pricing rule applied, and any that was breached
- Who approved an exception, on what basis, and when
Other representative workflows
Talk to us about a process like this.
The most useful first conversation is about a real process — where it stalls, who approves what, and which systems it touches.