What the documents look like
Amazon FBM fulfillment is operated by the seller, who arranges delivery and sets the return address without relying on platform warehouse inspection. The daily materials are order picking lists, shipment confirmation sheets, return address settings and logistics tracking sheets. Data sources include Amazon Seller Central, carrier systems, ERP orders and customer service email. The supplied brief gives an update frequency of per order and daily.
For product information and selection questions, these materials carry order-level granularity. A picking list records the product and quantity. A shipment confirmation sheet records the carrier and dispatch status. A return address setting records the place to which goods may be returned. A logistics tracking sheet records the tracking number and delivery progress. These materials determine where a workflow must collect information, where a user choice creates a branch, and which external actions require a separate business interface.
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 continues only after the user completes the interaction. Required fields are collected and passed to later nodes. The user selection node also triggers the interaction state; after the user makes a choice, the corresponding yes branch runs. The basic use is to pose a question requiring a decision and to design different workflow paths from the user's feedback.
In this category, product information and selection questions first need a form input to collect fields such as order number, product identifier, quantity, carrier preference or return address confirmation. A user selection then handles branches that require a decision, for example choosing between two carrier options. Order writes, document backfill and external status synchronization require a separate business interface or a later process. Interaction nodes do not perform those actions. Retrieval supplies candidate content and does not constitute authorization. A form collects values and does not complete business verification.
Hypothetical drill sample: the source material consists of three sentences. First sentence: picking list number PK-2025-0317, product wireless earphones, quantity 2, order number 112-3456789-0000001. Second sentence: the shipment confirmation sheet shows an overseas local carrier, tracking number TRK-0001, dispatch date 17 March 2025. Third sentence: the return address setting is a warehouse in a US state, effective scope this order. The draft sentence to be judged is: "This order has been delivered by the carrier and signed for." The subject of that draft is the carrier, the object is this order, and the state is delivery and signature. The material records only a dispatch date and a tracking number, with no delivery or signature fact.
Configuration and implementation checks
The table below covers only documented settings or implementation checks relevant to this feature and the primary task. The values are hypothetical starting points for this drill, used to explain the comparison method, and are not official defaults.
| Configuration item | Hypothetical starting point for this drill | Value selection and comparison method |
|---|---|---|
| Required form input fields | Order number, product identifier, quantity | Compare against the picking list source; if a field is missing, the interaction state does not submit |
| User selection branch | Two carrier options | Compare against the carrier name on the shipment confirmation sheet; the choice enters the matching branch |
| Interaction state record | Recorded when the node triggers | Check the conversation state before and after the node triggers; no separate global switch is set |
| Information passing target | Later retrieval node and decision node | Compare each form output field against the input fields of later nodes |
| External action division | Order write and status synchronization | Check whether a separate business interface is connected; interaction nodes do not perform writes |
| Retrieval library vector model identifier | Same library, same model | Check the library identifier and model identifier; libraries on different models are not associated together |
Three common errors
- Treating an order number collected by form input as a verified order fact. The input is a submitted form value, the comparison object is the picking list source, and if the two order numbers differ, the observable result is a field mismatch that must be recorded as pending verification.
- Treating the result of a user selection branch as a completed carrier order. The input is the user's selected option, the comparison object is whether a matching carrier record exists on the shipment confirmation sheet, and if the confirmation sheet does not record it, the observable result is that the external action is not complete.
- Treating a retrieval relevance score as a permission or entity filter. The input is the retrieval result list, the comparison object is the current order number and product identifier, and if the results contain material from other orders, the observable result is that items must be excluded by identifier; retrieval does not perform authorization.
How to verify the setup
- Verification one: use the hypothetical picking list source as input and compare the delivery and signature state in the draft sentence "This order has been delivered by the carrier and signed for." The material records only a dispatch date and a tracking number, with no delivery or signature. The expected result is that the draft sentence is unsupported, and the evidence gap is recorded.
- Verification two: use the required form input fields order number, product identifier and quantity as input, and compare them against the corresponding values on picking list PK-2025-0317. If the fields are complete and consistent, the expected result is that the interaction state can submit and pass to later nodes. If the order number is missing, the expected result is that the interaction state does not submit.
- Verification three: use a selected carrier option as input and compare it against the carrier name on the shipment confirmation sheet. If the selected option matches the confirmation sheet, the expected result is that the yes branch is connected correctly. If the confirmation sheet does not record a carrier, the expected result is that the external action is pending verification and is not judged complete. For empty-result handling, a paper input of [] can be used to check the downstream design; when retrieval returns an empty list, downstream nodes handle it as an empty value.