The integration dashboard should tell the record’s story
The customer asks, "Where's my order?" The dashboard says, "Sent." Those are very different answers. Here's how to follow one order, find out what actually happened, and give the customer a useful update.
GCG order story
One order, one reference
The ERP accepted GCG-1042. Its reply never reached the storefront. Follow the buyer, support, and an engineer as they find the order and connect the records.
Fictional records. No ERP connection.
Scene 1 of 6
Buyer submits the order
A buyer places an order in the example storefront. The storefront records it as order GCG-1042.
Read the complete story without animation
Scene 1. Buyer submits the order
A buyer places an order in the example storefront. The storefront records it as order GCG-1042.
On screen: an order packet labelled GCG-1042 moves from the buyer to the storefront, which now shows GCG-1042.
Scene 2. Storefront sends it, ERP accepts it
The storefront sends GCG-1042 to the ERP, the business system that receives the order. The ERP accepts it and creates order ERP-7001.
On screen: the packet travels to the ERP, an Accepted stamp appears, and the ERP shows ERP-7001.
Scene 3. The reply is lost
The ERP sends back a reply carrying ERP-7001, but the reply is lost on the way. The storefront waits, then times out. GCG-1042 has no ERP reference, even though ERP-7001 exists.
On screen: the reply packet falters halfway and fades, leaving a Reply lost marker. A countdown ring on the storefront runs out and shows Timed out.
Scene 4. Support verifies in the ERP
Support checks the authoritative ERP record and verifies the account and order details. ERP-7001 belongs to GCG-1042.
On screen: a magnifier moves from support to the ERP. A panel lists Correct account and Correct order: ERP-7001 for GCG-1042, each checked.
Scene 5. Engineer reconciles
An engineer uses the approved reconciliation process to save ERP-7001 against GCG-1042 in the storefront. No new order is created; ERP-7001 remains the one ERP order.
On screen: a link packet travels from the engineer to the storefront, which now shows both references. A panel reads No new order created.
Scene 6. Support gives the reference
Support tells the buyer: “Your order has been accepted. Its ERP reference is ERP-7001. We’re checking the shipment status separately.” Acceptance and shipment need their own evidence.
On screen: a reference packet travels from support to the buyer, who now shows ERP-7001. A separate panel notes the shipment check. No shipment result is shown.
What if I resend it?
This demo destination has a specific rule: the same request key and unchanged order details return the existing receipt. This is a separate code example using the accepted order from the story.
Use this only when the receiving system explicitly supports that behavior. A new key or changed order details can represent a different request.
Take this into your next integration review.
Support can use the printable field guide. Engineering can use the typed source and tests. Use the checklist below to assign the gaps you find.
Open the downloaded guide in a browser. Use Print to print it or save a PDF.
For developers: the typed request and result
The animation source is included. The typed integration model distinguishes an accepted order, a validation error, and a conflicting request. The complete model and behavior tests are in the download.
export interface OrderRequest {
readonly tenantId: string;
readonly orderReference: string;
readonly idempotencyKey: string;
readonly accountCode: string;
readonly sku: string;
readonly quantity: number;
}
export interface OrderReceipt {
readonly orderReference: string;
readonly status: "queued" | "confirmed";
readonly destinationOrderId: string | null;
}
export type SubmissionResult =
| { readonly kind: "receipt"; readonly receipt: OrderReceipt; readonly replayed: boolean }
| { readonly kind: "validation-error"; readonly message: string }
| { readonly kind: "key-conflict"; readonly message: string };Read AWS guidance on safe retries and request identity for implementation context.
Order integration review checklist
Review these with customer service and engineering. Check the completed items, then download the Excel tracker to assign owners, dates, and notes.
- Give support one view of the customer's order, the right account, and the connected ERP reference.
- Use separate labels for sent, rejected, waiting, accepted, shipped, and an unknown outcome.
- Provide an authoritative ERP lookup and document what a missing result can and cannot prove.
- Define who can match records, correct order details, repeat a request, or escalate, with permissions and an audit history.
- Document the receiving system's behavior for the same request key, changed order details, and corrected validation errors.
- Use durable atomic request reservations and business writes, with clear rules for concurrent requests, restarts, and key retention.
- Check lost replies, late replies, queue delays, repeated requests, validation errors, and conflicting order details.
- Give customer service a short order investigation guide and an owner for the next customer update.
A timeout tells you that an answer is missing
Picture this: a buyer places order GCG-1042. The storefront sends it to the ERP, the system that handles the business's orders. Then the connection times out. Customer service can see that the request was sent, but cannot tell whether the ERP accepted it.
The tempting response is to send it again. First, answer a simpler question: is the order already there?
The animated story above follows the buyer, customer support, and an integration engineer through that missing answer. Watch it play or move through the scenes at your own pace. The ERP accepted the order as ERP-7001. The reply did not reach the storefront.
That's the useful distinction. A timeout means the caller did not get an answer. It does not, by itself, mean the business transaction failed.
Finding the order is only half the job
Support finds the existing order and verifies the account and order details. In this story, the integration engineer handles the approved reconciliation workflow: save ERP reference ERP-7001 against storefront order GCG-1042. That gives support a reference to use and gives the storefront a confirmed answer to display. It does not submit a second order.
In a real support workflow, check that you have the right account and the same order before connecting those records. An ERP reference is useful evidence when it belongs to the customer's order. A similar amount or a nearby timestamp is not enough.
Then tell the customer what you know:
Your order has been accepted. Its ERP reference is ERP-7001. We're checking the shipment status separately.
Notice what that reply leaves out: a shipping promise. An accepted order may still be waiting for stock, release, picking, or a carrier. Order acceptance and shipment need their own evidence.
What if you send the same request again?
There is an optional repeated-request example below the story. Its demo destination has an explicit rule: repeat the same request with the same request key and the same order details, and it returns the existing receipt. It does not create a second order.
A request key is a label for one intended business action, such as submitting this order. It stays the same when you repeat that same request. It lets the destination recognize, "I've already handled this order request." Developers call this idempotency.
That rule belongs to the receiving system. Adding a key to your request does not make an ERP honor it. Before offering a retry button, define what the destination does with repeated requests, changed order details, and requests that arrive while an earlier attempt is still processing.
If the ERP already has the right order, matching its reference back to the storefront may be the action you need. Sending another order is a different action.
Make one screen answer the customer's question
My bar for a useful support view is simple: start with the customer's order and end with the next action. Put these facts together:
- The customer's order: a recognizable reference and the right account.
- What happened: sent, rejected, waiting, or accepted, with the evidence behind that label.
- The connected record: the ERP reference, when one exists.
- What happens next: check, match, correct, wait, or escalate, with a clear owner.
Technical logs still matter. Support should be able to answer an order question before working through a wall of them.
Use the printable field guide to walk through this with customer service and engineering. Open the downloaded guide in a browser, then use Print to print it or save a PDF. Use the interactive checklist to identify gaps, then download the Excel tracker to assign owners and dates. Developers can take the animation source, typed TypeScript model, its behavior tests, and the offline walkthrough.
If your team is piecing this together across logs and support tickets, explore GCG's ERP and ecommerce integration services. We can help define the handoffs, reconciliation rules and operational view around your own order workflow.
The next time a dashboard says "Sent," ask the question the customer actually cares about: what happened to my order?
Conceptual illustrations and fictional demo records.