Workflow automation

For the purchase example, separate the request from the decision and the purchase order created afterwards. Give each its own identity and retain the version that was reviewed. Record the acting person, their authority at that moment, the decision time and an explanation when the policy requires one. A chronological activity list should let a colleague reconstruct events without reading somebody else's inbox or guessing which attachment was current.

Assign each document a stable reference and track received, extracted, awaiting review, approved and posted states. Retrying extraction should not create a second payable record. Choose the duplicate rule with the business owner: an invoice number may need the supplier identity as part of its key, and a corrected invoice may require an explicit replacement relationship. File names alone are poor evidence of a new business event.

Test a worker stopping after it receives an event, after durable acceptance and while processing the business change. In each case, inspect both the inbox state and the business record after restart. If an external side effect is involved, acknowledge that the remote system may have accepted it before the local result was saved. Use supported idempotency or a reconciliation lookup where available; do not claim that a local status flag alone guarantees exactly-once delivery.

Give every published report a run identifier, a reporting interval and a data cutoff. These answer different questions: the interval says which work is being described, while the cutoff says how late-arriving information was handled. Keep the calculation definition with that run. If the definition of overdue changes next month, an earlier report should remain explainable rather than silently changing when someone opens its link again.