Nothing on this page is reachable from a fresh install yet. The BPMN and
DMN designers, the inbox, the cockpit and coolms:workflow:fork-to-vfs belong
to the Workflow, Decision, Inbox and Cockpit modules, and the designers are
screens in the admin front end. None of them is in the skeleton, which
registers 12 bundles and nothing beyond Core, Entity, DTMPL, API Platform,
Security and two themes — the list is config/bundles.php in the skeleton,
which says the same thing in its own comment.
This is the page furthest from describing an installation a stranger can make today. It is kept because what it describes — where the verbs live, and why deploying and starting are not console commands — does not change when the modules ship. What changes is that you will be able to follow it.
This is the half the CMS suffix stopped covering. A process is a BPMN definition: you draw it, deploy it, start instances of it, and people or services complete the tasks it produces.
This one is not a command-line walkthrough, and the reason is worth
knowing. The console's workflow commands are operational — broadcast a signal,
throw a correlation message, reclaim expired external tasks, fork a definition
to the VFS. There is no workflow:deploy or workflow:start, because
deploying and starting are things the designer and the API do. A page that
invented those commands would be a page you could not follow.
Draw it#
The BPMN designer is in the admin, under the designers. A definition is a file
in the VFS like everything else, which is why it has an owner, a group and a
mode, and why forking one to a locally editable copy is a real operation
(coolms:workflow:fork-to-vfs) rather than a copy-paste.
Start with something with one user task in it. A start event, a user task, an end event is enough to see the whole loop.
Deploy and start#
Deployment makes a drawn definition the active version. Starting creates an instance of it. Both are API operations, and the admin performs them for you — the start seam is the same one a service task or an inbound message uses, so nothing you learn here is specific to clicking.
Complete the task#
A running instance parked on a user task shows up in the inbox:
GET /api/v1/inbox/tasks
POST /api/v1/inbox/tasks/{id}/claim
POST /api/v1/inbox/tasks/{id}/complete
Claim is separate from complete on purpose. Claiming says who is working on it, so a second person opening the inbox does not start the same work; completing carries the data the task collected and lets the engine move the token on.
Watch it run#
The cockpit shows instances, their current position, and their external tasks:
GET /api/v1/cockpit/external-tasks
GET /api/v1/cockpit/task-metrics
POST /api/v1/cockpit/external-tasks/{id}/retry
Retry is there because an external worker failing is an ordinary event rather than an exception — the task returns to claimable and the next worker takes it.
Decisions, when a branch is a table#
A gateway that asks one question belongs in BPMN. A decision with fifteen rules and an overlap policy belongs in DMN, and the DMN designer produces a decision the process calls. The split is not about complexity — it is that a decision table is reviewable by the person who owns the policy, and a nest of gateways is reviewable by nobody.
Next#
Concepts in 10 minutes — the six ideas the rest of the documentation assumes you have met.