What the documents look like
TikTok Shop US operating data sits in Seller Center, the order center, carrier tracking, and advertising reports, with daily and per-order update cycles running side by side. Compared with Douyin Shop shelf operations, the US marketplace is shaped more strongly by local return windows, return grading, and overseas logistics constraints. Return and refund records, return grading evidence, settlement statements, and product listings form the main materials for exception review. These materials carry independent fields, statuses, and validity scopes, so workflow routing has to follow the status actually written on each document. A retrieval result or a value collected in a form does not become an authorization conclusion.
A return and refund record may state an order number, a submission date, a current status, and a return window deadline. A settlement statement may state a billing period and a deduction line. A product listing may state a listing identifier and a listing state. Each of these is a separate document with its own evidence boundary. When the workflow reaches an exception review, the routing decision depends on which document is being read and what that document actually records.
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 fills in the required information and submits. The collected information is then passed to subsequent nodes. The user selection node is also a user interaction node. It triggers the same interaction state, and once the user makes a choice, the node evaluates that choice and executes the corresponding yes branch. Both nodes can be added repeatedly and can trigger execution.
The documents describe the interaction state, the hidden dialog box, and the state record as existing node behavior. They do not describe a global state-recording switch, a submission count limit, or an automatic judgment mechanism. Collected values need an explicit connection to later retrieval, judgment, or interface nodes. Order writes, document backfill, and external status synchronization require a separate business interface or a later process. Retrieval and form-collected values do not constitute authorized execution, and a similarity score does not carry permission or entity filtering duties.
Hypothetical paper exercise sample: a return and refund record reads "Order number A-1001, buyer submitted a return request on 2025-03-10, status is pending review, return window closes 2025-03-20." A drafted sentence reads "This order has completed its refund, refund amount 39.99 USD." A pending request reads "Please mark this order as refunded and synchronize it to the settlement statement." The source text records only a pending review status. It does not record refund completion, a refund amount, or authorization to synchronize with the settlement statement.
Configuration and implementation checks
| Configuration item | Value or verification method on this page | Basis and boundary |
|---|---|---|
| Form input node | Collect return order number, status, and date range | Documented behavior: collects required information and passes it to later nodes |
| User selection node | Confirm the review branch direction | Documented behavior: executes the yes branch according to the choice |
| Interaction state handling | Check the downstream node connection after entering the interaction state | Documented behavior: records state and continues execution |
| Retrieval input scope | Limited to the target retrieval scope with access rights | Retrieval does not perform permission filtering |
| Empty-result handling | Use a paper input of [] to check downstream design | The documents do not state that a fictional rule must return empty |
| External write separation | Marking refunded and settlement synchronization connect to a separate business interface | The documents state a separate interface or later process is required |
Hypothetical trial starting point for this page: set the form required fields to return order number and status, because the sample source text contains these two fields. The comparison object is the field set actually recorded in the source text. This is not described as an official default value.
Three common errors
- Treating a pending review status as a completed refund. The sample source text says "status is pending review," while the drafted sentence says "has completed its refund." These are mutually exclusive values for the same subject and the same field, so the drafted sentence is unsupported.
- Treating a form-collected value as authorized execution. The sample request asks to mark the order refunded and synchronize the settlement statement. The source text does not record that authorization, and the form only collects values.
- Treating a similarity score as an entity or permission filter. A retrieval result returning a related document does not mean the order has refund authorization. The identifier and the authorization boundary need separate verification.
Corresponding checks:
- Input the sample source text and the drafted sentence, compare the status field values. If the source says pending review and the draft says completed refund, judge the draft unsupported.
- Input the sample request and the source authorization scope, compare whether the requested action falls inside the recorded scope. If the source does not record marking and synchronization authorization, judge the request pending verification.
- Input the retrieval result and the order identifier, compare whether the returned document subject matches the target order. If it does not match, exclude it. Do not run a cross-model retrieval comparison for missed recall.
How to verify the setup
- Verification one: input the sample source text "Order number A-1001, status is pending review, return window closes 2025-03-20" and the drafted sentence "This order has completed its refund, refund amount 39.99 USD." Compare the status and amount fields. The source text does not record refund completion or an amount, so the expected judgment is unsupported, and the evidence gap is preserved.
- Verification two: input the sample request "Please mark this order as refunded and synchronize it to the settlement statement" and the source authorization scope. Compare whether the requested action falls inside the recorded scope. The source text does not record marking or synchronization authorization, so the expected judgment is pending verification, and no write is executed.
- Verification three: input the paper empty result [] and the downstream node design. Check whether the downstream design accepts an empty input. The documents do not state that a fictional-rule retrieval must return empty, so the expected action is only to check the design's handling, without claiming an actual returned result.
All three verifications use hypothetical samples as input. They were not actually executed, and no claim is made that testing occurred or approval was granted.