On This Page
“Orders move automatically” sounds like a complete workflow description. In an illustrative trace, every order appears in both systems. Then a spreadsheet column turns up between them. An operator changes that column before the upload because the store’s status does not mean what the email team expects.
The diagram was accurate at the level of boxes. It missed the job.
A discussion of learning workflows from systems of record describes building a working procedure by observing what enters a system and what gets corrected. That is a useful starting point. It does not mean a log can explain a person’s intent, or that a team should gain broad access to customer records merely to watch them.
Start with a trace, not a process name
“Order sync” sounds like one operation. Follow a single order and it becomes a sequence. When was it created? Which status was written first? Did a payment or cancellation change it? Which field reached the destination? What did the destination do with that field? What did a person correct afterward?
Write those events in time order. Keep the source record identifier beside each step. If a value changes twice, record both changes. If the destination only holds the latest value, find out what happened in between. The goal is not a polished process map. It is a trace another person could challenge.
The first trace should be ordinary. The second should be an exception: a cancellation, a merged customer, a return, a late payment or another case the operators say matters. Two traces do not establish frequency. They expose the questions a specification must answer.
- Store recordstatus arrivesobserved
- Operator correctionmeaning checkedconfirmed
- Email destinationaccepted state
| What the team says | What a trace could reveal | Question to ask |
|---|---|---|
| “Orders sync automatically” | A manual file is uploaded later | Which transformation does the file perform? |
| “Customer status is current” | An older value is overwritten by a later event | Which system owns the final state? |
| “Errors go to support” | A correction is made in the source without a ticket | How does the destination learn about it? |
These are illustrative possibilities, not observed customer incidents. The integration guide helps choose a connection pattern once the actual path is understood.
Records show behavior; operators explain meaning
A record can show that a value changed from pending to complete. It cannot tell you whether that change meant payment cleared, fulfillment finished, or somebody fixed a typo. The field name is not the business rule.
This is where observation and interview belong together. Ask an operator to walk through a case that the trace makes puzzling. Let them explain the exception and show the authorized screen they use. Then replay the rule against another sample. A specification built from one compelling example may encode one person’s workaround as company policy.
Access matters. Use the least data needed for the question. Work with approved access and redact personal fields when possible. A sync design exercise is no excuse to export a customer database into a research notebook. If the system exposes audit events or a sandbox, start there. If it does not, get an owner to demonstrate the path with suitable records.
The distinction also prevents a common automation mistake: replacing an inconvenient manual step before understanding what judgment it carries. The spreadsheet column may be needless duplication. It may also be the only place a human marks that a disputed order must not trigger a campaign. Delete it without finding out and the new sync can become faster at the wrong action.
Turn the trace into a contract
Once the path is visible, specify the connection in terms of states and owners. Define which system is authoritative for each field, what event moves it, how late or repeated events are handled, and what happens when the outcome is uncertain. Name the person or team allowed to correct each mismatch.
The contract should distinguish recorded fact from business interpretation. “The store sent fulfilled at 14:03” is a recorded event. “This customer should receive a review request” is a decision that may also depend on returns, consent and local policy. Keeping those apart makes later changes safer.
A field map makes one part of the contract visible. In this Tajo illustration, each row names a source field, a destination field and a translation rule. It also reveals what has not been specified. A purchase event still needs a separate policy before it becomes a review request or a campaign decision.
Review a sync before it runs
Sync customer updates to my email platform.
Customer sync
| Source field | Destination field | Rule |
|---|---|---|
email | EMAIL | Direct |
first_name | FIRSTNAME | Direct |
last_name | LASTNAME | Direct |
Synthetic preview passed
3 fields mapped · No destination writes
Illustrative layout based on Tajo's mapping tools. A synthetic preview and a saved draft do not activate a sync.
A practical acceptance test uses the trace itself. Replay an ordinary order and an exception in a test environment. Confirm the destination’s final state, not only that an API call succeeded. Then try the correction path. If the source record changes after the destination has acted, can the system reconcile it?
The objection is fair: “We cannot study every edge case before we build.” Correct. The aim is not an exhaustive census. It is to find the few hidden steps that decide whether the first version works. Start with the highest-consequence paths, record what remains unknown, and instrument the connection so new exceptions can be seen.
A workflow diagram becomes useful when the people who run the work can point to the missing box.
Frequently Asked Questions
Why is an interview not enough for a workflow specification?
People can accurately describe the intended process while omitting rare exceptions or routine workarounds. Compare their account with authorized records, then ask them to explain any difference.
Can system logs reveal the whole workflow?
No. Logs show recorded actions, often without motives, offline work or decisions made outside the system. Use them to form questions for an operator, not to infer intent on their own.
What should a first sync trace include?
Follow one normal item and one exception through source records, edits, handoffs and destination states. Note who can correct a mismatch and what evidence confirms the final outcome.