KNOWLEDGE WIKI  (LOCAL-MD-001)MODE: READ_ONLYSYS_TIME: --:--:--
SECTION:fdePAGES:40CURRENT:field-patterns/workflow-mapping.md
FDE-015field-patterns/workflow-mapping.mdUPDATED: 06/18/2026

Workflow Mapping

Pattern

Name: Workflow mapping

When to use it: When a customer describes a messy manual process and wants automation, AI assistance, or system integration.

Why it matters for FDE roles: It turns vague operational pain into states, owners, transitions, exceptions, and automation candidates.

Plain-English Description

Workflow mapping is the practice of drawing how work moves from trigger to outcome, including who owns each step and what happens when something goes wrong.

Situation Signals

  • Job listing signal: workflow automation, operations, implementation, process improvement.
  • Customer signal: work is tracked in spreadsheets, messages, tickets, or memory.
  • Project signal: automation is requested but the process has no explicit states.

What To Ask

  • What event starts this workflow?
  • What are the possible statuses?
  • Who can move an item from one status to another?
  • What exceptions happen often?
  • Which steps are safe to automate now?

What To Do

  • Identify trigger, states, owners, actions, and exit criteria.
  • Mark manual, assisted, and automated steps separately.
  • Add exception states instead of hiding failures.
  • Define the audit trail before implementation.

Artifacts To Produce

  • Diagram: state machine or swimlane workflow.
  • Checklist: states, owners, transitions, exceptions.
  • Demo/prototype: one workflow item moving through the core states.
  • Customer-facing note: automation candidates and human review points.

Failure Modes

  • Automating a process no one can explain.
  • Leaving failed or low-confidence items without an owner.
  • Treating exceptions as edge cases when they are common.
  • Removing manual judgment before trust exists.

Interview Language

One sentence I could say in an interview:

I map workflow automation as states, owners, transitions, exceptions, and review points before deciding what software should do automatically.

Relevant work experience for this pattern: