Approved Workflow to SOP: What the Diagram Still Doesn't Say

An approved workflow diagram establishes agreed sequence, responsibility, branching, and boundary. It does not necessarily establish the method, tool, acceptance criterion, evidence record, exception authority, or document control needed for an executable SOP. The safest conversion keeps the approved diagram fixed, expands each symbol through a gap matrix, and sends logic changes back through workflow approval.

Preserve the diagram as a controlled baseline

Export the approved workflow with title, owner, version, approval date, scope, and legend. Record whether its lanes represent people, teams, systems, locations, or some mixture. Do not silently “clean up” a gateway or reroute an arrow while writing the SOP.

Use three change labels during drafting:

• Expansion: adds execution detail without changing flow.
• Clarification: makes existing diagram meaning explicit.
• Logic change: adds, removes, or reorders a path, responsibility, trigger, or outcome.

Expansion belongs in the SOP. Clarification may belong in both artifacts. A logic change must return to workflow review.

Start events need prerequisites

A start circle labeled “Request received” hides several questions:

• Which channels create a valid request?
• What minimum fields or attachments are required?
• Which timestamp controls service targets?
• How are duplicates recognized?
• What happens to an incomplete or unsafe input?

The SOP should not broaden the trigger accidentally. If the approved scope begins only when a complete request reaches the case system, an email in someone’s personal inbox is not the same start event.

Task boxes need actor, action, object, and proof

Use this sentence frame:

[Actor] uses [tool/source] to [action] [object] until [acceptance criterion], then records [proof] in [destination].

“Analyst reviews file” becomes reviewable only after those fields are filled. If the box sits in a swimlane labeled “Operations,” identify the actual role. A lane assigns responsibility at diagram scale; an SOP must tell the user who may perform or approve the action.

Check safety and competency separately. The fact that a role owns a task does not prove that every person in the role is trained, authorized, or equipped to perform it.

Gateways need tests, not questions

Translate each decision diamond into a table before prose:

This exposes two common drawing defects: a branch with no terminal outcome and an exclusive gateway whose conditions overlap. The writer should not guess which branch wins.

Swimlanes need handoff contracts

An arrow crossing lanes should create a handoff statement:

• what object moves;
• source owner and receiving owner;
• readiness criteria;
• notification method;
• expected response boundary;
• what happens if the receiving owner rejects or does not respond;
• which system records the transfer.

“Send to Finance” is movement. “Finance receives a verified order ID, refund reason, approval code, and customer payment method in the case system” is a handoff contract.

End events need records and states

“Complete” may mean the operator finished a task, the downstream system accepted it, the customer was notified, or the record passed review. Name the state precisely.

For each end event, define:

• output and recipient;
• completion evidence;
• status written to the system of record;
• notification requirement;
• records retained;
• follow-up or monitoring, if any.

ISO’s public documented-information guidance distinguishes documents used to operate a process from records retained as evidence. A checkmark drawn inside a task box is not retained evidence unless the workflow identifies where the check is stored.

A compact worked example

Approved workflow:

Customer Service: receive claim → verify required fields
Gateway: complete?
  no  → request missing information → wait
  yes → Quality: assess evidence
Gateway: meets criteria?
  no  → issue reasoned denial
  yes → Operations: execute remedy → notify customer → close

The SOP expansion must still name the accepted claim channels, required fields, evidence sources, criteria version, assessment authority, approved denial wording, permitted remedies, tool steps, customer-notification record, and closure test.

Once those facts are settled, SOPMaker can carry the next artifact—from structured workflow facts to a reviewable SOP draft—without pretending that generated prose is the approval source. Preserve the diagram ID and version in the SOP so future reviewers can trace sequence and responsibilities back to the baseline.

Run a diagram-to-procedure reconciliation

After drafting, trace three cases through both artifacts:

1. one normal case;
2. one recoverable exception;
3. one stop-and-escalate case.

At each step, verify:

• the SOP never jumps to a box without following a diagram path;
• every diagram path has procedure content;
• role names match;
• gateway criteria match the approved meaning;
• no extra approval was invented in prose;
• records and terminal states are reachable.

Mark discrepancies as expansion, clarification, or logic change. Do not solve a logic change by burying it in a paragraph.

Release package

A durable package contains:

• controlled workflow diagram;
• SOP with purpose, scope, roles, prerequisites, steps, exceptions, records, and references;
• forms, checklists, screenshots, or work instructions used by the SOP;
• approval record and effective date;
• training or acknowledgment evidence where required;
• change log linking diagram and SOP versions;
• scheduled review owner.

The diagram remains the best artifact for seeing sequence and responsibility. The SOP is the best artifact for performing and proving the work. Good document control keeps them connected without forcing either one to impersonate the other.