BPM step type reference

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:

  • remoteAction
  • role
  • dataReferenceFrom
  • dataPropertyFrom
  • message
  • status
  • createEvent
  • eventType
  • eventDescription
  • active
  • actionRequired
  • dataReference
  • fileData
  • data
  • permit
  • remote
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:

  • role
  • name
  • processDefinition
  • statusRules
  • ownerRole
  • initAction

(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:

  • message
  • status
  • createEvent
  • eventType
  • eventDescription
  • active
  • actionRequired
  • dataReference
  • fileData
  • data
  • permit
  • remote
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).

  • title
  • content
  • showMessage
  • messageMandatory
  • messageMandatoryMessage
  • showMessageHeading
  • messageHeading
  • messageEditor
  • message
  • status
  • createEvent
  • eventType
  • eventDescription
  • confirm
  • confirmContent
  • notConfirmedMessage
  • button
  • state
  • active
  • actionRequired
  • showUpload
  • uploadMandatory
  • uploadMandatoryMessage
  • showUploadHeading
  • uploadHeading
  • uploadMultiple
  • uploadFirst
  • dataReference
  • fileData
  • data
  • permit
  • remote

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 "*".