What the documents look like
Brand outlet discount operations centre on clearing out-of-season stock. The working materials are discount approvals, slow-moving stock lists, price tags and gross margin calculation sheets. ERP stock-age records show how many weeks an item has sat in inventory, POS sales show what actually sold, and outlet mall promotions together with historical discount levels form the pricing reference. These materials update weekly or monthly, so an operating review has to line up approval status, list scope, price tag version and margin basis that may not share the same cut-off date.
For the routing task, the practical consequence is that a review request often arrives with several fields at different stages. A discount approval may be submitted but not yet reviewed. A slow-moving list may cover a period that ends before the latest POS data. A price tag version may still reflect an earlier discount level. Workflow routing has to collect these fields at defined points and pass them downstream without treating any collected value as a completed business action.
Constraints at the workflow routing step
The form input node is a user interaction node. When it triggers, the conversation enters an interaction state, the workflow state is recorded, and execution waits until the user completes the interaction. After the user fills the required information and submits, the node collects the submitted form values and passes them to later nodes. The user selection node is also a user interaction node. It triggers the same interaction state and state recording. When the user makes a choice, the node evaluates that choice and executes the corresponding branch. Both nodes are repeatable and trigger execution.
At the routing step, branch connections must be checked one by one, and the collected values must be passed explicitly to the later retrieval, decision or interface nodes that need them. Order writing, document backfill and external status synchronisation require a separate business interface or a later process. Retrieval and form submission do not by themselves constitute authorised execution.
Hypothetical paper exercise sample. The source text of a discount approval material reads: "Subject: outlet clearance team; Object: spring 2024 slow-moving footwear SKU-A; Status: discount application submitted, pending finance BP review; Valid scope: 1 June 2024 to 30 June 2024." The draft handover request under review reads: "Please update the price tag at the approved discount level." The approval status in the source text is pending review, which does not constitute approval.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | Reason and comparison method |
|---|---|---|
| Form input node | Enabled, collecting SKU, discount rate and approval status | Compare each field against what the later decision node requires |
| User selection node | Enabled, branches "continue" and "return" | Check that the selected result matches the connected branch |
| Interaction state recording | Recorded according to the node's existing behaviour | No separate global state switch is set |
| Information passing | Form values passed to the decision node | Compare node output against node input fields |
| External write | Connected through a separate business interface | Compare interface return against the submitted form values |
The hypothetical starting points apply only to this paper check and are unrelated to any published default.
Three common errors
- Treating "pending review" as approved. In the sample, the approval status is "pending finance BP review". A draft sentence reading "at the approved discount level" contradicts that status field. The check compares the status value in the draft against the status field in the source text; observing "pending review" means the execution condition is not met.
- Treating a retrieval hit as authorisation. A retrieval that returns the approval material does not mean the approval passed. The check compares the retrieval output against the approval status field; observing a retrieval hit while the status has not become approved means the execution condition is not met.
- Treating form collection as a completed external write. Form submission only records state and passes information; a price tag update requires a separate interface. The check compares the form submission record against the interface return record; a form submission without an interface return means the external write is not complete.
How to verify the setup
- Input the source text and the draft sentence, then compare the approval status in the draft against the status field in the source text. The source text reads "pending finance BP review" and the draft reads "approved". These are mutually exclusive values in the same field, so the pair is contradictory and the execution condition is not met.
- Input the retrieval hit record and the approval status field, then compare whether the retrieval output changed the approval status. A retrieval hit does not change the status; observing that the status remains pending review means authorisation has not been obtained.
- Input the form submission record and the interface return record, then compare whether both exist. A form submission alone, with no interface return, means the external write is not complete and the evidence gap remains open.
These checks state expected observations rather than completed tests. Where a record is absent, the gap is recorded as missing evidence.