Defining a process using the process model format

The process model format is very simple and does not describe exactly how to define a process.


Each step with a stepClass of "step" (which is the default) represents an executable step:

  • The name of the executable step is taken from the stepName property of the step, which is set the the reference of the step if it is not otherwise set.
  • The script is taken from the script property of the step, and defaults to null. It can be a binding reference or a node reference.
  • The config for the step is taken from the config property, which should be an object.

Next clause

The next clause is generated from all the step flows that have a state property, using the calculated step name of the step identified by their toReference as the target.

A next property of "*": false is generated if there is no "*" state.

Status rules

A status rule is generated for each flow, on any step, that has a status property.

  • The status of the status rule is take from the status property of the flow. If the status property is of the form "statusReference/Status Name", only the reference is used.
  • The role of the status rule is taken from the role property of the flow, or 'user' if there is no role.
  • The action of the status rule action object is taken from the action property of the flow if present, but typically from the executable name calculated for the step identified by the toReference on the flow. (An action property can be useful if a different URL is being generated, for example to call a group-level step from a worker-level process.)
  • The caption of the status rule action object is taken from the caption property of the flow, or the name of the step identified by the toReference on the flow.
  • Other properties of the flow that match properties of status rule actions are also copied across to the status rule action object. This includes:
    • popup
    • disabled
    • html
    • url
    • group
    • sequence
    • target
    • linkClass
    • params
    • exclude
    • hidden


Choice steps represent a series of options that the process could take after a step. They are required by some process modelling conventions, but are not required by the process model format.

The flows from choice steps are merged into the flows of all steps that flow to the choice step, and then the choice steps are ignored.

Start, Intermediate, End

Start, intermediate and end steps represent different types of event. They are optional in the process model, but can be useful to help the designer and viewer understand what is going on.

Start steps must have no incoming flows with states, end steps must have no outgoing flows with states. Start and intermediate events may (and usually would) have a single outgoing flows with a state. Flows without states are allowed.

Leave the script property empty so that these step types generate steps with a null script that does nothing.


Entities allow other items, such as data resources, to be represented on the model and then properties defined against them. No steps are generated for the entities, but their properties can be referenced.

Sub processes

A sub process is invoked on a step by setting three properties:

subProcess Identifies the sub process to invoke. It can be a binding reference or a node reference.
subProcessRole Identifies the role within the sub process. Defaults to no role.
subProcessStepName Identifies the step name to pass control to. Defaults to the one with the same step name as that in the main model.

The sub process is included by generating the sub process, extracting suitable process steps and status rules for the role, and merging those into the main process. The generation is passed the properties of the main process invocation step (including the generated stepName), which are mered over the process-level properties of the sub process, thus parameterising it.

If the sub process action is specified, a null process step is generated from the main model step which has a next clause to go to the sub process action. Otherwise, no invoking step is generated (because the sub process step is assumed to haved the same step name as the invoking main process step and would overwrite it).

Within the sub process, the steps that have a flow with a state property that leads to an end step are modified to instead lead to the steps that the invoking step would lead to with the same states.

Sub processes that are intended to be integrated into the main process flow should conform to these conventions:

  • There is a step per role with a "stepName" property set to "${process.stepName}". This does not have to have startClass of "start", but it is clearer if it does.
  • There are one or more end steps per role.

Sub processes that may be invoked more than once in a main process should base all their step names on the stepName property set at the process level. For example, a run step might set the "stepName" property to "${process.stepName}_run",