BPM step types are wrappers around the underlying (executable) process step types. The BPM step types have similar names to the underlying process step types and the properties of the BPM step types generally follow the names of the config properties of the process step types. However, for processing reasons, there are some differences. The table below summarises the Core BPM step types, the equivalent process step types, and properties.
Reference | Description | User task? | Process step types | Properties |
call | Makes a call through a channel. send provides a more specialised call method specifically for sending worker state and data. Similarly, sendProcess is a more specialised call for sending a process. | Call | See config for Call. | |
delete | Immediate delete of worker. This would usually preceded by a step to ask for confirmation. | Delete | See config for Delete. | |
download | Present one or more files for the user to download. Allow them to indicate that they have downloaded the files, and optionally choose a different outcome. | true | Download | See config for Download |
form | Show a form. | true | Form |
See config for Form. |
receive |
This is a synonym for set, and is used for the set step that is called when status or data is passed from another channel. The receive would typically be called with permit: false, or a limited set of property names, to ensure that the other channel can only set what was intended. receive is inserted automatically when needed by the Process compiler. |
Set |
See set. |
|
send | Send status or data to another channel. send is inserted automatically when needed by the Process compiler. | Send |
See config for Send. This includes some config for Set. The full list is:
|
|
sendProcess | Send a process through a channel. This is typically picked up by a control worker that creates a new worker and instantiates it with the process. sendProcess is inserted automatically when needed by the Process compiler. | Send process |
A subset of Send process config is supported:
(Other options are not required by the generated processes.) |
|
set | Set status and/or data. This is the non-user version (i.e. with show of false). | Send |
The following from Set:
|
|
setStatus | A synonym for set, used for the set step used to set a status as part of flow. setStatus is inserted automatically when needed by the Process compiler | Set |
See set. |
|
userSet | Get status and/or data from the user. This is the user version of set (with a show of true). | true | Set |
All the config from Set, except show (which defaults to true) and remote (which is set to false).
|
State and status processing
Any flows that start or end with a user task will involve the creation of a status. Settings these up in Camunda needs some care.
- For tasks starting at a non-user task, the default status of "*" will suffice.
- For tasks starting at a user task, you must set the status property of the flow to the appropriate button value (such as "submit").
- For choices following a task, you must set the status of each branch to the appropriate button value (such as "accept" and "cancel").
If you want to add a name, you can set either set the status using the "reference/name" convention, e.g. set status to "accept/NDA accepted". Or you can use the flow name to set the name. If you use the flow name for a flow from a non-user task, you must set the status property of the flow to "*".