Process map vs. workflow specification: what automation needs
Add data, states, roles, rules, integrations, recovery, evidence, and tests to turn a process map into a build-ready workflow.
.png)
A process map explains how work flows; a workflow specification defines enough detail for people and systems to execute, test, govern, and recover it consistently. A map may show “finance reviews request.” The specification must say which requests, which finance role, which evidence, which deadline, which decisions, which next states, and what happens when the review cannot be completed.
Use a map for orientation and discussion. Add an executable specification before asking a delivery team or automation platform to build the operation.
Source review: August 28, 2026. Choose a notation and level of formality appropriate to the workflow’s consequence, complexity, regulation, and technical environment.
What a process map does well
A process map gives stakeholders a shared view of sequence, handoffs, decisions, roles, and major exceptions. It helps teams see duplication, delay, unnecessary approval, missing ownership, and confusing boundaries.
Maps are especially useful during discovery because people can challenge them. A clear visual can expose that the official process differs from real work or that two teams use the same word for different states.
That strength is also the limitation: many maps deliberately simplify. They may omit exact data definitions, rule precedence, permissions, integration contracts, timing, evidence, versioning, and recovery.
What makes a workflow specification executable
“Executable” does not have to mean a file that a particular engine imports. It means the specification is precise enough that qualified people can build the same intended behavior, test it against the same expectations, and operate it without inventing material rules.
The OMG BPMN 2.0.2 specification distinguishes descriptive and analytic modeling subsets from a common executable subset. The practical lesson applies even when an organization does not use BPMN: visible flow alone is not the whole execution contract.
Add these 12 parts to the map
1. Outcome, trigger, and boundaries
Define the business outcome, initiating event, entry criteria, completion and cancellation conditions, included populations, and explicit exclusions.
2. Case and object model
Name the unit of work and its stable identifier. Define related objects such as customer, supplier, contract, asset, order, employee, or location and how they connect.
3. Data dictionary
For every input and derived field, record its definition, format, allowed values, required condition, validation, source of truth, sensitivity, owner, and retention rule.
4. State model
List every operational state, including waiting, returned, escalated, failed, cancelled, and completed. Define the allowed transitions and the event that produces each one.
5. Role and permission model
Specify who may create, view, edit, assign, decide, override, configure, export, and administer. Separate job titles from functional roles so staffing changes do not rewrite the logic.
6. Decision tables
Translate diamonds on the map into explicit conditions, precedence, actions, and default behavior. Reference the policy or authority behind each material rule, plus its owner and effective version.
7. Timing and escalation
Define business calendars, due-date calculation, reminders, escalation thresholds, pause conditions, time zones, and the action taken when a deadline passes.
8. Actions and communications
Describe each notification, document, assignment, update, calculation, or system call. Include the trigger, recipient, content source, expected result, and evidence retained.
9. Integration contracts
For every dependency, specify the endpoint or interface, payload, authentication owner, response, timeout, retry, duplicate control, error handling, monitoring, and reconciliation.
10. Exception and recovery behavior
Define missing or conflicting data, unavailable roles, policy conflicts, integration failure, system outage, correction, cancellation, and rollback or compensating action where applicable.
11. Event and evidence model
State what must be recorded for intake, state change, assignment, review, decision, override, integration, failure, and outcome. Include case, actor, timestamps, reason, source, and configuration version.
12. Tests and acceptance criteria
Provide normal, boundary, permission, exception, integration, recovery, and historical-reconstruction tests. Define expected results and who may approve the release.
Use a traceability matrix
Connect every material requirement to its authority, configuration, test, event evidence, and operating owner. A compact matrix can use these columns:
| Requirement | Authority | Configuration | Test | Evidence | Owner |
|---|---|---|---|---|---|
| Requests above threshold require finance review | Policy clause and version | Rule and state transition | Below, at, and above boundary | Route and decision events | Finance operations |
| Failed system update goes to recovery | Integration standard | Error state and queue | Timeout and duplicate response | Error and reconciliation events | Integration owner |
The matrix makes change impact visible. When a policy clause changes, the team can identify the affected fields, rules, permissions, tests, events, documentation, and open cases.
Run the independent handoff test
Give the map and specification to a qualified person who did not design the workflow. Ask them to:
- Build or configure one normal path and one exception path.
- Explain every material decision and its authority.
- Create boundary, permission, and failure tests.
- Describe how operators detect and recover from a failed dependency.
- Identify the evidence needed to reconstruct a completed case.
Record every question whose answer required the original designer. Those questions reveal missing specification, ambiguous policy, or undocumented operating knowledge.
Keep the map and specification synchronized
The map, specification, configuration, tests, and runbook are different views of one operation. Give them a shared version and owner. Update them in the same change packet. A diagram that shows the old path is not harmless documentation debt; it can cause incorrect support, testing, and approval decisions.
The workflow documentation checklist extends the build specification into a full production runbook.
How Formaloo contributes implementation evidence
Formaloo’s Logic map visualizes configured fields, conditions, actions, and paths. Advanced logic can define cross-field and multi-condition rules and trigger supported actions.
Use those views as implementation evidence and troubleshooting aids. Keep the authoritative outcome, policy references, data dictionary, role model, integration contract, recovery plan, tests, and ownership in the wider workflow specification.
Turn the map into a build-ready operation
If you need to translate process knowledge into a governed workflow your teams can build, test, run, and improve, book a Formaloo demo.
