Data Mapping
Part of Stateful workflow orchestration
Separating orchestration state from business records
Define which system owns business facts and which progress an orchestrator stores, including references, versions and result IDs.
Keep business facts in the application that owns them; keep process progress in the system coordinating the workflow. For a purchase request, the workflow may need its ID, the stage awaiting approval and the version sent for review. The purchasing application remains the authority for amount, supplier and business status. A resumed workflow then has a clear place to check current facts.
Assign ownership field by field
For each field proposed for workflow state, ask who can change it and which system should answer a business user's question about it. Copying an editable business field into orchestration state creates another value that can become stale during a long wait.
| Data | Suggested authority | Workflow use |
|---|---|---|
| Request amount and supplier | Purchasing application | Read when the next decision needs current facts. |
| Approval request and expected event | Approval service or orchestrator, as designed | Route a response to the waiting instance. |
| Version or snapshot reviewed | Approval record | Check whether the decision still applies. |
| Purchase-order ID | Purchasing destination | Retain a reference to confirm the effect. |
This is an example, not a universal schema. If an approval service owns the authoritative decision, document that boundary explicitly.
Pass references and control copied data
A workflow commonly needs a stable business ID, an expected version, a decision and the IDs of confirmed downstream results. Pass only the values needed for coordination. Avoid copying an entire order or customer object into every step because it arrived in the trigger.
A copied snapshot may be stale when the workflow wakes. Some durable runtimes also persist inputs, outputs and event payloads.
Keep inputs and outputs small to manage payload size. Protect secrets and personally identifiable information, and secure the storage used for workflow state. Apply access and retention controls to the store actually used.
Choose current facts or an approved snapshot
A delayed step needs an explicit rule for the version it may use. If approval covered a fixed amount or supplier, retain what the approver reviewed and compare it with the current request before creating an order. A material change may require fresh approval or another defined exception path.
Other actions may intentionally use current facts, such as the latest contact address for an operational notice. State that rule in the workflow contract.
Reconcile process and business outcomes
A workflow's completed state should be supported by the destination's business record. Retain the destination ID and check that the expected object exists. If the business request was cancelled while the workflow waited, detect that before the next action. Route disagreements for investigation rather than treating either status alone as proof of the other system's outcome.
Document the authoritative system for each field, the instance reference, version rule, result ID and retention owner. That contract shows what can be reconstructed after an interruption and what requires an authoritative lookup.
Reconciliation of Process and Business Outcomes
- Confirm destination business record existsVerify that the expected object (e.g., purchase order) is present after workflow completion.
- Retain destination ID and instance referenceStore the ID of the final outcome and the workflow instance for audit and traceability.
- Detect cancellations during wait periodsCheck if the original business request was cancelled while the workflow was paused.
- Route discrepancies for investigationDo not assume one system's status reflects the other; escalate mismatches.
- Document authoritative systemsDefine ownership for each field, version rule, result ID, and retention owner.
