Turing Automate: illustrative returns workflow Prepared 17 October 2026 Page: https://turingautomate.com/solutions/ecommerce#returns-example PURPOSE Two fictional cases demonstrate a proposed request-to-refund control model. These are synthetic teaching records, not customer results, API exports, a working integration or evidence that a live return/refund has been executed. All references beginning SYN- are fictional. Internal status names are our teaching labels, not Shopify enums. Times are invented UTC examples. FILES returns-cases.csv: one row per requested return case, not per item/event. returns-status-log.csv: append-only illustrative events, ordered by time per case. expected-results.json: independently checkable totals for this exact fixture. FIELDS AND AMOUNTS ordered_quantity and unit_item_value_gbp describe the fulfilled order items. requested_return_quantity is the number requested from that order. requested_item_value_gbp = requested quantity multiplied by unit item value. approved_refund_gbp is the authorised amount; recorded_refund_gbp is the store-recorded amount after reconciliation. A blank means not yet determined, not a measured zero. A recorded refund does not establish receipt at a bank. This simple item-value example excludes tax, shipping, discounts, fees, exchanges and multi-currency conversion. Scope these explicitly in a real build. CHECK IN A SPREADSHEET 1. Open each CSV as UTF-8 with comma separators. Keep SYN references as text. 2. Check unique case_id and event_id values, GBP currency, positive quantities and requested quantities no larger than ordered quantities. 3. Sum ordered_quantity * unit_item_value_gbp: 2*48 + 1*72 = GBP168. 4. Sum requested_item_value_gbp: 1*48 + 1*72 = GBP120. 5. Only SYN-RETURN-A has approved/recorded refund values: GBP48. 6. Filter events with refund_recorded_gbp present: exactly one GBP48 record. Do not add the case total and event total: they describe the same refund. 7. Check return approval, receipt check and refund authorisation precede that record. The unknown outcome is reconciled before the duplicate is suppressed. 8. Check operation_key SYN-RETURN-A:refund:v1 identifies that single approved action. A repeated operation has no new refund reference or monetary record. 9. SYN-RETURN-B remains in human_review with blank approved/recorded amounts. Never fill those blanks with zero to make a report appear complete. 10. Compare these results with expected-results.json: 2 cases, 12 events, 1 recorded refund, 1 held case and 1 suppressed duplicate operation. PRODUCTION BOUNDARIES Agree your actual policy, permitted quantities, receipt/condition checks, approval owners and exceptions. Verify platform scopes, staff permissions and webhook authenticity. Store operation/approval versions and provider references; reconcile uncertain outcomes before initiating another money-changing action. API-specific idempotency rules differ; this illustrative application ledger does not imply all API mutations accept the same idempotency directive. Carrier label purchase/creation is a separately confirmed integration. No label URLs, credentials, personal data, executable provider requests or email sends are included. Test acceptance criteria and alert ownership before launch. OFFICIAL SHOPIFY REFERENCES REVIEWED 17 OCTOBER 2026 https://shopify.dev/docs/api/admin-graphql/2026-10/mutations/returnRequest https://shopify.dev/docs/api/admin-graphql/2026-10/mutations/returnApproveRequest https://shopify.dev/docs/api/admin-graphql/2026-10/mutations/reverseDeliveryCreateWithShipping https://shopify.dev/docs/api/admin-graphql/2026-10/mutations/refundCreate https://shopify.dev/docs/apps/build/webhooks/verify-deliveries NEXT STEP Use the editable returns brief on the page. Share your platform, monthly volume, carrier, warehouse, helpdesk, approval owner and current bottleneck. We confirm the connections and propose a scope and fixed quote before implementation.