Data Mapping
Part of Workflow documentation and ownership
Recording source-system dependencies
Build a source dependency register for a workflow, covering events, lookups, accounts, field contracts, owners and missed-work recovery.
Record the source conditions a workflow needs to start and decide correctly: event or scan, account, API lookup, required data, access path and system owner. Note what breaks if each condition changes. This lets an operator investigate a workflow that still runs but no longer receives or recognises expected work.
Trace the source boundary
Start from one intended business action and work backwards. For a hypothetical fulfilment request, ask which order state makes it eligible, how the workflow learns of that state, and whether the signal is sufficient or needs a further lookup. Identify the system authoritative for each business fact; a copied value in the workflow may become stale.
A scheduled scan may depend on its query and saved position. An event route may depend on its subscription and delivery endpoint. Either can also rely on an account, network route and API lookup. Record the route actually used rather than treating “order system” as one dependency.
| Register field | What to record |
|---|---|
| Source and owner | Application, environment, support contact and change contact |
| Signal | Event subscription or schedule, filter and identifier |
| Data contract | Required fields, meanings, version and permitted lookup for missing detail |
| Access | Connection identity, required permissions and renewal owner; never the secret itself |
| Recovery | How missed source work can be found and any limit of that method |
| Impact | Business outcome delayed or made uncertain if the dependency fails |
These are suggested register fields, not a product schema. Use the selected source’s event and API documentation to establish its actual contract. Mark an unconfirmed detail as unconfirmed rather than inferring it from one sample payload.
Distinguish direct and supporting dependencies
Draw the route from source to workflow with directional arrows. Label the event producer, any queue or webhook receiver, each source lookup and the connection used. Ask the source owner which supporting services can interrupt that route — identity, DNS or network connectivity. Record those relevant to this workflow, not a generic infrastructure list.
Note whether the workflow needs current state or a history of changes. A scan that returns an order’s present state may not show every transition between scans. If a particular transition matters, confirm with the source owner how it can be detected or recovered. A diagram alone cannot establish that contract.
Make change impact visible
For each dependency, record how changes are announced and who assesses their effect on the workflow. Ask whether a renamed field changes eligibility, an account replacement changes permissions, a new endpoint leaves deliveries in flight, or a changed lookup returns different records.
Keep a route to inspect current configuration beside the documented expectation. An authorised engineer should be able to find subscription settings, connection status and a recent source item. Dependency telemetry may reveal timeouts or failed calls; it cannot prove that an event the source never sent was handled.
When a source changes, update the affected register entries, diagram and runbook. Define expected outcomes for an eligible item, an irrelevant change and a missed-work recovery case. Record observed results only if those checks are performed.
