Business Processes and Tasks
What is a business process
A business process is a visual BPMN diagram for handling a record: a sequence of tasks, approvals and automatic steps executed by the engine.
| Menu section | What it holds |
|---|---|
| Business Processes → Templates | diagrams: authoring, editing, versions |
| Business Processes → Running Processes | instances: which record, where they currently are |
| Business Processes → Approval Types | approval forms (the fields an approver fills in) |
The section is available to an administrator and to anyone holding the admin.processes permission — the preset role Process Designer grants it (see roles).
INFO
The business processes module can be disabled by the platform operator — globally or per organization. Process sections are then hidden from the menu, the "Processes" panel on the record page is not rendered, and the process API answers 403/404.
Process vs. automation
A process is a diagram with steps that wait for people and with state that lives between those steps. If you only need "when this condition holds, change a field / send a notification" in one action and without waiting, use an automation on the entity itself.
Processes shipped with the presets:
| Preset | Processes |
|---|---|
| IT Support | Request lifecycle |
| ITSM | Incident, change and problem lifecycles |
| HR | Vacation approval |
| Projects | Task execution |
How a process starts
The launch path is defined by the diagram (which start node it carries) and by the template's Launch settings.
On a record event
A process starts automatically only from an On Event node. The node selects an entity event:
| Event | When it starts |
|---|---|
| Record created | when a record is created |
| Record updated | on a save that changed data |
| Field changed | the selected field got a new value; can be narrowed to a specific value |
| State changed | the state field got a new value |
"Field changed" and "State changed" require the value to actually change: a save that leaves the field as it was does not start anything.
The node can also carry a condition on the record's fields — the process starts only when it holds. A field that was never filled in counts as empty in that condition.
Manually from the record page
The + Launch Process button on the record page lists the templates available to you for that record. Availability is configured in the template (Launch → Launch settings):
- Manual launch from the record page — off by default;
- Who can launch — all users or specific roles;
- Launch conditions — a set of conditions on the record's fields (all / any); the button appears only when the record matches them.
From an automation and from another process
- The Start process automation action launches a template from an entity rule.
- A Call activity node launches another template from inside a process, with or without waiting for it to finish.
The plain Start node
A plain Start is the diagram's entry point. It does not launch anything on its own: a template that only has a Start is launched manually, by an automation, or as a subprocess.
Parallel duplicates
Parallel duplicates caps concurrent instances of a template and applies to every launch path:
| Mode | Effect |
|---|---|
| Allowed (default) | no cap |
| One active instance per record | a second launch on the same record is blocked |
| One active instance globally | a second launch is blocked while the first runs |
A template blocked by this rule appears disabled in the launch menu, with the reason.
Where processes are visible
On the record page — the "Processes" panel
The panel shows:
- the record's active processes and the step each one sits on;
- tasks and approvals assigned to you or your role, with action buttons;
- Process History — a collapsed list of finished ones.
In "My Work"
All your tasks and approvals across all records are collected in My Work at the top of the left menu, with search, filters, sorting and a Done tab. The list updates without reloading the page.
In the bell
When a process assigns a task to you or your role, you get a notification linking to the record.
In "Running Processes"
A process administrator sees the full list of instances: status, bound record, active nodes, and the error of the last step.
Steps that wait for a person
Task
A task suspends its branch until it is completed. It is completed from the record page or from My Work.
By default process tasks land in the built-in "Tasks" entity. If you have your own task entity (the Tasks tab in the entity settings), point the node at it via Task entity. The step then creates a record of your entity, with its own fields, form and permissions.
Buttons in My Work and on the instance page follow the task entity's state model: they show the transitions the model allows from the record's current status. If the path to completion goes through an intermediate status ("New" → "In Progress" → "Done"), that step appears first. When the current status has no transitions, the row shows the status instead of a button — the transition you need is not defined in the entity's state model.
When the target status requires fields (the status matrix in the status field settings), My Work asks for them in the same dialog and sends them along with the status. Files, images and map points are uploaded on the record page — for those the button takes you there.
Approval
An approval is a step with an outcome — Approved or Rejected. The outcome and the comment are available to the following steps and drive the diagram's branches (see Approvals).
An approval can require a form; the set of fields comes from the approval type (Business Processes → Approval Types) and opens under the "Details" button.
Several assignees on one step
A task or approval can be assigned to several people at once with a quorum rule:
| Quorum | The outcome is decided when |
|---|---|
| All | everyone has answered; a single rejection rejects immediately |
| Majority | more than half are in favour (or a majority became unreachable) |
| N votes | N votes in favour are collected (or N became unreachable) |
| First | the first person answers |
Once the quorum is reached, the remaining assignments are cancelled.
Who a step goes to
- A specific person — from a record field (for example, "Approver").
- A role, group or org unit — everyone in it sees the step; the first to complete it closes the step.
If no recipient resolves, the step is created unassigned and stays visible to the process administrator.
Branching
A task, an approval or a gateway can have several outgoing arrows. Which of them fire is decided by the conditions on the arrows:
- an arrow whose condition is true is taken;
- an arrow without a condition is always taken;
- an arrow marked as the default is taken only when no other one was.
A condition is built with the constructor (field — operator — value) or written as an expression. The full reference — available variables and operators — opens in the editor from the Help link next to the branch conditions.
Gateways differ by logic (the marker on the element):
| Gateway | Marker | Split | Join |
|---|---|---|---|
| Exclusive | XOR | one branch | continues on the first token that arrives |
| Parallel | AND | all branches, conditions ignored | waits for every incoming branch |
| Inclusive | OR | every branch whose condition is true | waits only for the branches that were actually taken |
Join with what you split with
A parallel join waits for a token from each incoming branch. If an exclusive gateway sits upstream, only one token arrives and the process stops silently. The editor flags such a diagram before saving.
Timers and SLA
- Timer wait — a standalone step that holds the process for a set duration.
- Timer on a task (SLA) — fires when the task was not completed in time and routes the flow down its own branch.
- Error handler on a task — routes the flow down the error branch when the step fails; the error text is available to the following steps.
Timers are fired by the process:tasks background command from the Laravel scheduler — without a running scheduler, waits and SLA never fire.
Several processes on one record
A record can carry several running processes — different templates, or the same one if parallel duplicates are allowed. Each instance keeps its own state and its own tasks.
Template versions
Templates are versioned: edits are saved as a new version, while already running instances keep following the diagram they started on. A new version applies to launches made after it was saved.
When a task is stuck
A task may be assigned to someone who is unavailable. A process administrator finds the instance under Business Processes → Running Processes and intervenes there; the same page shows the error text if the process failed on a step.