Diagramming Business Workflows

Given a process description, produce a Mermaid flowchart (or swimlane diagram if roles are specified) immediately — don't ask clarifying questions unless the description is genuinely ambiguous about branching logic.

Input: "Customer submits a request. Support team reviews it. If approved, finance processes payment. If rejected, customer is notified."

Output:

MERMAID
flowchart TD
    A[Customer submits request] --> B[Support team reviews request]
    B --> C{Approved?}
    C -->|Yes| D[Finance processes payment]
    C -->|No| E[Customer notified of rejection]
    D --> F[End]
    E --> F[End]

Progress:

• Step 1: Parse the process description into discrete actors, actions, decisions, and sequence
• Step 2: Identify decision points (if/then, approval gates, exceptions) and loops
• Step 3: Identify distinct roles/departments (determines if swimlanes are needed)
• Step 4: Choose diagram type (see decision guide below)
• Step 5: Generate diagram code
• Step 6: Add a short plain-English legend/summary beneath the diagram
• Step 7: Flag gaps or ambiguities in the original description (e.g., "What happens if finance rejects payment?")

Diagram type decision guide:

• Single actor, linear/branching steps → flowchart TD (Mermaid)
• Multiple roles/departments interacting → flowchart with subgraphs per role (swimlane simulation), or sequenceDiagram if the focus is on handoffs/communication over time
• Parallel/concurrent steps (e.g., "simultaneously, X and Y happen") → use & fork syntax in flowchart or explicit parallel branches
• Formal BPMN required for enterprise documentation → describe in BPMN XML-like pseudocode or recommend a BPMN tool, but still provide Mermaid as the readable draft

Standard shape conventions (use consistently):

• [Rectangle] = process/action step
• {Diamond} = decision point
• ([Rounded]) = start/end terminal
• [[Subroutine]] = reference to another sub-process
• [(Database)] = data store/record

Example 1 — Multi-role process (swimlane via subgraphs):

Input: "Employee submits expense report. Manager reviews it — if over $1000, it also needs director approval. Finance reimburses once approved."

Output:

MERMAID
flowchart TD
    subgraph Employee
        A([Submit expense report])
    end
    subgraph Manager
        B[Review report]
        C{Over $1000?}
    end
    subgraph Director
        D[Approve/Reject]
    end
    subgraph Finance
        E[Reimburse employee]
    end
    A --> B --> C
    C -->|No| E
    C -->|Yes| D --> E
    E --> F([End])

Summary: Standard reports need only manager approval; reports over $1000 require an additional director sign-off before finance reimburses.

Example 2 — Loop/rework cycle:

Input: "QA tests the build. If it fails, dev fixes it and QA retests. If it passes, it's released."

Output:

MERMAID
flowchart TD
    A([Build ready]) --> B[QA tests build]
    B --> C{Passes?}
    C -->|No| D[Dev fixes issue] --> B
    C -->|Yes| E[Release build]
    E --> F([End])