Process Modeling
What to know
A process model is a design object; a process instance is one running copy of it. Models are built from a start node, end nodes, activities, and gateways. Common activities: user input task (a person completes a form), service or script task (automated expression or integration), send email, and subprocess (calls another process model). An XOR gateway splits the flow so exactly one outgoing path runs, based on conditions.
Process variables carry data across the flow and are typed. A user input task's form can only see data an interface exposes as rule inputs, so variables are passed in and results written back through the task outputs. User input tasks have an Assignment tab: assign to a user, a group, or an expression, with deadlines and escalations layered on top.
Traps
- Every outgoing flow from an XOR gateway needs a condition, and one flow should be marked the default so the instance never deadlocks when nothing matches.
- Assigning a task to a group lets any member pick it up; assigning to a specific user serialises the work.
- A form cannot reference
pv!variables directly; pass them as rule inputs. - Multiple node instances (MNI) repeat a node across a list - good for parallel approvals, but results need an aggregation step.
Worked example
After a Manager Review task, route on pv!approved. Outgoing flow 1 condition: pv!approved = true; flow 2 is the default and goes to the rejection path. Because the default catches every other case, statuses added later cannot strand the instance.
Rule of thumb: if a decision is binary, give the positive case the explicit condition and let everything else fall to the default.