Guide
How to Map a Workflow Before AI Automation
Map one real workflow using cases, decision points and source evidence. Find missing rules and decide who takes over when the agent stops.
Map a workflow for AI automation by starting with a specific outcome, tracing actual cases across systems and identifying the decisions between steps. Record who can authorize each action, what information is required and when a person must take over. Review the map against both policy and practitioner explanations.
Choose one workflow the team is already trying to build. Collect the cases needed to identify unanswered questions. Check the map against those cases and mark any missing information.
The method below uses an example replacement request. Use the worksheet for support, order changes or another workflow with a clear start and end.
1. Choose the boundary before opening a diagramming tool
Write a sentence naming the trigger and the end state.
For example: “From a customer’s replacement request to a confirmed permitted replacement or an assigned review.”
That boundary excludes manufacturing, procurement strategy and the whole support organization. It includes the decision about whether this replacement can proceed.
Name the process owner and the person who handles difficult cases. They may be different people. The owner can approve the intended rule; the practitioner can explain where real cases differ from the written process.
Ask who will use the findings and what they need. Give developers the required data and permissions. Show operations managers who handles the next step. Agree these needs before drawing the map.
2. Reconstruct cases with different outcomes
Start with an ordinary completed case and deliberately add contrasting cases: an exception, a blocked case or a failed action. This is a practical starting sample, not proof of representative coverage.
For the replacement workflow, collect a case where the original part was available, one where an alternative was offered and one where review was needed. Use the ticket, order or inventory records that are actually available.
Write down each event, its source and its time. Join records only when the link is supported. If a message might concern a different order, leave the uncertainty visible rather than silently attaching it.
The purpose is to recover the sequence and expose the gaps. You do not need to model the whole company before identifying a missing compatibility rule.
3. Write decisions between the steps
A sequence such as “receive request → check stock → send replacement” leaves the hard part implicit. Add the conditions that determine whether each step may happen.
| Point in the workflow | Required information | Decision to resolve |
|---|---|---|
| Confirm the request | Customer and original order | Does this request qualify for a replacement? |
| Check availability | Current stock for the requested part | Can the original part be supplied? |
| Consider an alternative | Compatibility evidence | Is the alternative suitable? |
| Check authority | Applicable price and approval rule | Who must approve the proposed replacement? |
| Place the order | Confirmed prerequisites | May the agent act now? |
| Confirm the result | Authoritative order response | Did the action complete, or is follow-up required? |
Use this table to guide the investigation. It does not assert that FieldSignal has a ready-made connector or automation for each system.
When a required fact is missing, name the person to ask and list the records to send them. State the decision you need from that person.
4. Ask about the specific exception
Show the practitioner the case, then ask what changed their choice. Ask which fact they checked, which alternative they rejected and when the same action would have been wrong.
In the replacement example, urgency explains why an alternative was considered. It does not explain whether the alternative was compatible. Follow that gap directly: where was compatibility checked, who could verify it and what should happen if the answer is unavailable?
Compare the explanation with the documented process. Ask the owner to resolve any disagreement about intended behavior. List the rules that still need a decision and assign someone to resolve each one.
For a fuller interview method, use the guide to capturing tacit knowledge. Use it to ask how the person made the decision. Check the explanation against the records and keep missing facts marked as unknown.
5. Give developers the rules, records and open questions
For each decision, record the required input, permitted action, approval authority, exception and expected outcome. Attach the supporting case and note any unresolved question.
Record these details in the workflow-mapping worksheet. The supplied rows are fictional; replace them with authorized evidence from the workflow being reviewed.
Ask a developer to work through a case using only the map and rules. List anything they have to guess. Find missing records and ask the process owner to resolve missing rules.
FieldSignal supports this path from workflow evidence into development. The data is accessible through MCP and CLI, and its Claude/Codex skills help turn that evidence into draft AI tests. The team can then review and adapt those cases for its testing setup.
This method is most useful when a named automation project is blocked by uncertain rules or exceptions. Broader organizational mapping may need more sources, participants and time. No fixed session length can guarantee a complete picture.
Scope a managed discovery project to get one workflow investigated and prepared for your implementation team.
Related reading: process discovery for AI, build evals from workflow data, and the complete replacement example.