Instant Process

Appearance

Tutorial ​

This tutorial builds one complete process graph from an empty editor. It uses a small order-handling process, but every step applies to whatever process you want to model. Work through it in the editor with the graph pane open on the right, so you see each line take shape as you type it.

The Documentation describes every node in full. This page only introduces what each step needs.

1. Start with an entry point ​

Every process begins somewhere. START marks that point, and the trailing NEXT says "connect me to whatever comes next in the text".

pml
START 'Order received' NEXT

You now have a single node. Nothing else is connected yet, because nothing else exists.

2. Add the work ​

Work steps are activities. Add two, each ending in NEXT so they chain together in the order you wrote them.

pml
START 'Order received' NEXT
ACTIVITY 'Check stock' NEXT
ACTIVITY 'Ship order' NEXT

The graph is now a straight line of three nodes. Because each line ends in a bare NEXT, you never had to name a target.

3. Close the flow ​

An END node marks an exit point. It never takes a NEXT, so it is always the last thing on its path.

pml
START 'Order received' NEXT
ACTIVITY 'Check stock' NEXT
ACTIVITY 'Ship order' NEXT
END 'Order complete'

That is a valid, complete process graph. Everything from here refines it.

4. Branch on a decision ​

Real processes rarely run in a straight line. A gateway splits the flow. Give each branch an explicit target and a label, so the diagram says why the flow went that way.

pml
START 'Order received' NEXT
ACTIVITY 'Check stock' NEXT
GATEWAY 'In stock?' NEXT 'Ship order' 'yes' AND 'Notify customer' 'no'
ACTIVITY 'Ship order' NEXT
END 'Order complete'
ACTIVITY 'Notify customer' NEXT
END 'Order cancelled'

Two things changed. The gateway names its targets explicitly rather than relying on text order, and the labels 'yes' and 'no' appear on the arrows. Note the shape of an explicit connection: the node description comes first, the arrow label second.

5. Mark something that happens ​

Use an event when the emphasis is on an occurrence rather than work being performed. A payment arriving is a message event.

pml
START 'Order received' NEXT
ACTIVITY 'Check stock' NEXT
GATEWAY 'In stock?' NEXT 'Ship order' 'yes' AND 'Notify customer' 'no'
ACTIVITY 'Ship order' NEXT
EVENT-MESSAGE 'Payment received' NEXT
END 'Order complete'
ACTIVITY 'Notify customer' NEXT
END 'Order cancelled'

If you are unsure whether something is an activity or an event, ask whether the process does it or observes it. Activities are done; events happen.

6. Define who does what ​

Lanes group nodes by actor or role. Everything after a LANE belongs to it until the next LANE appears, and the flow crosses lane boundaries freely. A lane name is a description, so write it in single quotes.

pml
LANE 'Sales'
START 'Order received' NEXT
ACTIVITY 'Check stock' NEXT
GATEWAY 'In stock?' NEXT 'Ship order' 'yes' AND 'Notify customer' 'no'

LANE 'Warehouse'
ACTIVITY 'Ship order' NEXT
EVENT-MESSAGE 'Payment received' NEXT
END 'Order complete'

LANE 'Sales'
ACTIVITY 'Notify customer' NEXT
END 'Order cancelled'

The graph is unchanged, but the diagram now shows responsibility as well as sequence. Naming 'Sales' a second time returns to the same lane, so the fallback path sits with the rest of the sales work.

7. Attach the systems you rely on ​

An attachment shows a document or system that the process reads from or writes to, without becoming a step of its own. The stock check consults a register, so hang a DATABASE off it.

pml
LANE 'Sales'
START 'Order received' NEXT
ACTIVITY 'Check stock' NEXT
GATEWAY 'In stock?' NEXT 'Ship order' 'yes' AND 'Notify customer' 'no'

LANE 'Warehouse'
ACTIVITY 'Ship order' NEXT
EVENT-MESSAGE 'Payment received' NEXT
END 'Order complete'

LANE 'Sales'
ACTIVITY 'Notify customer' NEXT
END 'Order cancelled'

DATABASE 'Stock register' NEXT 'Check stock'

8. Annotate and tidy up ​

Two finishing touches. A # starts a comment, ignored when the process is compiled, so use it for section headings and reminders. And when a description is long or likely to change, give the node an explicit identifier and reference that instead, so the connections stay short and stable.

pml
# Sales department
LANE 'Sales'
START 'Order received' NEXT
ACTIVITY 'Check stock' NEXT
GATEWAY 'In stock?' NEXT 'Ship order' 'yes' AND Notify 'no'

# Warehouse
LANE 'Warehouse'
ACTIVITY 'Ship order' NEXT
EVENT-MESSAGE 'Payment received' NEXT
END 'Order complete'

# Notify customer
LANE 'Sales'
ACTIVITY Notify 'Notify customer' NEXT
END 'Order cancelled'

# Register check
DATABASE 'Stock register' NEXT 'Check stock'

ACTIVITY Notify 'Notify customer' keeps its readable label but is now reachable as Notify, which is what the gateway branches to. That is the complete process: two lanes, a decision, an event, an attachment, and two ways out.

Where to go next ​