An order that lives in a table between runs

Every message is a separate run, and runs know nothing about each other. An order’s history exists precisely because somebody records it: with no collection, “what’s happening with my order” can only be answered with “tell me what happened so far”.

What is inside

1. A message about an order — the entry.
2. What happened — the model pulls the number, the new status and the gist.
3. A new record and Store the event append a row.
4. What came before reads everything already recorded for that order.
5. Answer about the order confirms the change and recaps the order’s path by date.

Append, do not overwrite. Storing a single “current status” is cheaper, but then “when was it shipped” has no answer.

What to set up for yourself

• The list of statuses in the field description: it maps any phrasing onto your vocabulary.
• Filtering by order. It currently reads the last fifty events across all orders and lets the model sort it out. Once there are many orders, add a condition on the number — otherwise it is both expensive and imprecise.
• Who sends the events. In practice not a person but a webhook from your own system; the graph does not change.

What to connect

A collection under Tables. Nothing external: the whole history lives inside the product.