Send process


Send a process definition to a partner, so that it can participate in a process with a worker. The partner will create is own worker so that it can interact with the sender.

It is parameterised by config or a data parameter.


The role of the partner to which the process should be sent. This would typically be something like "respondent" or "supplier". Required.


Name for the newly-created worker. Defaults to the name of the sending worker.


If set to true (the default), send the process identifier from this worker. If set to false, do not send a process identifier. Otherwise, send the given value as the process identifier.

If set to true or omitted, this means that the partner's new worker will be paired with the originating worker. In this case, the role will be passed to the new worker to keep track of its role in the process. The role is not passed if a different process identifier is sent.


Process definition. Required.

This can contain a placeholder of the form ${processDefinition:binding}, where binding is a binding reference in the process definition. The process definition of the bound node will be resolved and copied by the worker instantiator.

statusRules Status rules. Optional. This can contain a placeholder of the form ${statusRules:binding}, which works the same as the process.

Where within the recipient to create the new process relative to the originating connection's group. Defaults is to create it directly within the originating connection's group.

This is resolved to an array of objects with reference and name which can be used to navigate and if necessary create groups inside the recipient's connection group, such as the following which would create the new process in the projects/beta sub group, with names of Projects and Beta (names are only used if the groups need to be created in the recipient.)

{"reference":"beta","name":"Beta","config":{"icon":"fa fa-aeroplane"}}

If not given, name defaults to reference, and reference defaults to a normalized version of name.

A config property is also permitted. See New worker for details.

A path can be built to match the path of the primary group that contains the worker, i.e. the originator's path can be used as the basis for the recipient's path. In this case, the path may use and must start with a special element, which is "/" (for root group), "." (for current group) or ".." (for parent group) - though stating with "/" has no effect (it is the same as the default, making the path absolute). The originator's path is resolved and then the full path (relative to the root) is passed on. The relative root is not passed on - all paths that arrive at the recipient end are relative to the connection group of the originator.

If the recipient's connection group is within the path, then the path is resolved to be relative within the recipient's connection group. For example, if you are "Universal Imports", and the worker's primary group is "/Suppliers/ACME Limited/Orders", and you specified a path of ".", this would first be resolved to "/Suppliers/ACME Limited/Orders". Assuming "ACME Limited" is the connection group for the recipient, then this would be further resolved to "Orders". Within the recipient, assuming the connection group was "/Customers/Universal Imports", the incoming path would then resolve to "/Customers/Universal Imports/Orders", which is exactly what you would expect.

Be cautious of using a relative path when the worker has not been explicitly created in a project.

When building a path, you can, in place of the full form, use an array of strings or a slash-delimited string of path references. When a single string is used, it is considered to be the name, and a normalized version of it considered to be a reference. If the references have special characters (other than A-Z, 0-9 and underscore), then you must pass the path using an array of objects to prevent normalization of the references.

basePath Set the base path from which the new worker's group will be resolved. Defaults to the path of the originating connection's connection group. Can only be set if the originating connection is trusted.
connectionRole What role to give the originating channel in the partner, i.e. what the other partner considers this party to be. Defaults to "owner". May be set to false if connections is passed.
connections An object which specifies what connections to set on the newly created worker. This may only be passed if the receiving connection is trusted. The names of the properties of the object are the roles of the connections, and the values are their paths or roles, each of which must evaluate to exactly one connection.
private If set to true or false (not just a truthy or falsy value), will set or not set the private indicator. If not set, will use the value from the template or from the connection group (if any).
config Configuration options to set on the new worker. See New worker step type for details.
initAction Action to be invoked on the newly-created worker. If not passed, no action is run. If the action fails, the worker will be deleted.
initData Data to send to the newly-created process.
initDataReference Reference for the data in the newly-created process. Defaults to 'init'.

Reference from which data should be read. This can be used to pass data from a data node, rather than from a request parameter. Use this to send data from one party to another. dataReferenceFrom is ignored if the initData property is set. (Deprecated - better to use an initData value of %{data:dataReferenceFrom}.


Whether to replace runtime placeholders in the config. This additional control is required because the process definition may have runtime placeholders in it that should be preserved.

If omitted or set to a false-like value, no placeholders are replaced.

If set to true, runtime placeholders in %{..} sequences are replaced.

If set to a different character, that is used for runtime placeholders

By convention, if the process definition has runtime placeholders that should be preserved, the placeholders property is set to "@", and then runtime placeholders for all config items that need to replaced (not just the process definition) should be preceded by "@". This means that %{..} runtime placeholders in the processDefinition are not accidentally replaced.

processIdentifier, name and processType are read from the worker.

Member Type List

Tab/SequenceWeightMember Type
Flow rules/flowRules

Set Tags

Tag List