How to Create a BPMN Diagram

Before drawing anything, answer three questions:

1. What triggers this process? (Start event)
2. What's the outcome? (End event)
3. Who owns this process? (Accountability)

Write these down. Keep the scope to one clear outcome—if you're modeling multiple outcomes, you might be modeling multiple processes.

Example:

• Trigger: "Customer submits support ticket"
• Outcome: "Ticket resolved and closed"
• Owner: "Support Team Lead"

The happy path is what happens when everything goes right. No exceptions, no edge cases—just the normal flow.

How to do it:

1. Draw a start event (circle)
2. List 5–12 activities that happen in order
3. Connect them with sequence flows (arrows)
4. End with an end event (bold circle)

Naming tips:

• Use verb-object format: "Review application", "Send notification"
• Be specific: "Check inventory" not "Process request"
• Keep it short: 2-4 words per activity

Don't add gateways yet. Get the main flow right first.

Gateways show where the process branches. Only add them where the path actually changes.

Types of gateways:

• Exclusive (XOR): One path is chosen (most common)
• Parallel (AND): All paths execute simultaneously
• Inclusive (OR): One or more paths may execute

How to add a gateway:

1. Identify where the path branches
2. Insert the gateway (diamond shape)
3. Label each outgoing path with a condition
4. Make sure all paths eventually reconnect or end

Labeling tips:

• Be explicit: "Amount > $10,000" not "Large amount"
• Cover all cases: What happens if neither condition is met?
• Keep it simple: If you need more than 3 branches, reconsider

Approvals are first-class citizens in BPMN. Don't hide them inside other activities.

Modeling approvals:

1. Create an explicit activity: "Approve [thing]"
2. Add a gateway after the approval
3. Model both "Approved" and "Rejected" paths
4. Assign the activity to the right role (swimlane)

Handling exceptions:

• Only model exceptions that affect execution
• Use intermediate events for errors/timeouts
• Add escalation paths for stuck work

The 80/20 rule: Model the happy path and the top 2-3 exceptions that cause real delays or risk. Don't try to model everything.

A diagram that nobody validates is probably wrong.

Review checklist:

• Walk through with people who do the work
• Verify each activity is named correctly
• Confirm gateway conditions match reality
• Check that swimlanes reflect actual responsibility
• Identify missing steps or incorrect sequences

Common fixes during review:

• "That's not what we call it" → Rename activity
• "We don't do that anymore" → Remove activity
• "What about when X happens?" → Add exception path
• "That's not my job" → Move to correct swimlane

After the review:

• Update the diagram with feedback
• Get explicit sign-off from the process owner
• Schedule a follow-up review in 3-6 months

Use this checklist before sharing your diagram:

Structure:

• One clear start event
• One clear end event (or explicit multiple outcomes)
• Activities named with verbs
• Gateways labeled with conditions
• All paths lead to an end event

Readability:

• Can explain in 2 minutes
• No crossing lines if possible
• Swimlanes show responsibility
• Consistent level of detail

Governance:

• Approvals are explicit activities
• Process owner identified
• Review date scheduled
• Connected to SOP documentation

Ready to create your diagram?

Start with Process Designer's BPMN tool →