Business process
Process documentation has a habit of living in three places: a diagram in someone's slide deck, a policy document, and the actual behaviour. Drawing the process on the Confluence page that describes it removes one of those three.
For most processes a flowchart is enough. Reach for BPMN when the process will be automated or when the notation is part of the requirement.
#When to draw one
Documenting how work actually moves through a team.
Designing a process before building any of it.
Compliance documentation where the process must be evidenced.
#What is on the diagram
Element | Meaning |
|---|---|
A flowchart | Most processes, most of the time |
A swimlane diagram | When the handoffs between teams are the problem |
BPMN | When it will be automated, or the notation is required |
A DMN table | When the hard part is a decision with several inputs |
#A worked example
A purchase request, with the approval threshold visible:
The source, which you can paste into a new diagram and edit:
#A few things that catch people out
Draw the rejection and timeout paths. They are the parts people ask about.
One diagram per process. A diagram covering three processes documents none of them.
Approvals can be run for real rather than only documented. See Integrations.
#Related
Diagrams next to the words they explain.
