This article looks at the variables present as standard in process instances. Some are added by the workflow worker, and some by the form fields that interact with process instances.
Process variables have a name and value. Some are created automatically when a process instance starts. Some hold values from iCM form submissions (that either started the process, or completed tasks during the process). Other variables are created as various tasks and activities are completed.
Inspecting Instances and Variables
In the process modeller you can inspect a process instance and see all of the process variables associated with it.
Instance Properties
In the top section of the instance details view you can see basic information about the instance, including the name of the definition, the user who started it and when, and the instance business key. These values can be used as filters when you're searching in the modeller, trying to find a particular instance.
Standard Process Variables
The following process variables are available as standard in a process instance.
| Variable | Description |
|---|---|
| _businessKey | A unique identifier for this instance, generated automatically in the workflow worker's |
| _fileReferences | If the "Workflow - Start Action" field type is set to "Keep file references" this variable contains the IDs and file names of uploaded files. For example:{ |
| _historyLabels | The default settings of the "Workflow - Start Action" form field will write information to the API Server's History worker. labela is set as the name of the process, labelb as the unique business key that identifies this instance. Values can be accessed using |
| _initiatorProxy | The initiator of the process instance if it was started by a proxy user, for example using the Assisted Service product |
| _logFinalSummary | If false a final summary event will not be logged to the history that accompanies this instance (this variable is set by the "summaries" property in the workflow form action fields) |
| _processDefinitionID | The full ID of a deployed process (not the instance!). This is unique within the database and is made up of the _processDefinitionKey plus a unique suffix |
| _processDefinitionKey | The process identifier, set in the workflow model (generally the name of the model). It is not unique |
| _startDate | The date/time the instance started |
| _startDateString | The _startDate formatted as a date string |
| _startForm | The name of the form that was used to start this instance |
| _startFormDescription | The description of the form that was used to start this instance |
| _startPageURL | The URL of the form that was used to start this instance |
| _summaryForm | When you interact with a process instance using the GOSS Self Service template, it's possible to view summaries of that instance. The form used to view that summary is, by default, the same form that started the process. You can select a different form in the "Workflow - Start Action" field type |
| _taskForm | The name of the form used to complete the last task |
| _taskFormDescription | The description of the form used to complete the last task |
| _traceEnabled | If the form that started the process instance has tracing enabled, this variable will be present with the value true. This enables tracing in the workflow engine. See Debug and Tracing for more information |
| form_FIELDNAME | Values from form submissions that interact with a instance (ie start an instance or complete a task) are stored as process variables, prefixed with The values of these variables will always be strings. If the forms used by subsequent workflow tasks include fields with the same names as these variables (ie the same fields names as previous forms) the values of existing variables will be mapped to them and displayed in those fields. They will also be updated if they are changed in those user tasks |
| formPage_PAGENAME | The values of fields from repeating pages are stored as an array of objects, with one object per page instance, and the key-value pairs in each object the field names and submitted values. See Repeating Page Data for more information |
| initiator | The initiator of the process. The name of this variable can be set in the Start Event of your model |
| js_VARIABLENAME | If you need to pass JavaScript objects to a process instance (either from a form, or using the Workflow worker's API) prefix them with |
Process Variables Generated by Activities
Process variables are automatically added to an instance as tasks are claimed, released or completed, and when the process receives a message or signal.
_claimed, _released, _completed
When a task is claimed a process variable is created called _TASKID_claimed. Note that this task ID is the value you can enter when designing your process. If left blank iCM will assign a random value to it. When these variables are created, messages with the same name (message reference) are also sent to the instance.
These variables are JavaScript objects with the following form:
"_TheTaskID_claimed": {
"user": "<user who claimed task>",
"proxyUser": "<user who claimed on behalf of new assignee>",
"taskId": "<task id in process instance>",
"time": "<time task was claimed in ISO format>"
}
For example, if a process contains a user task with the ID "usertask1", when that task is claimed a process variable called
Similar process variables are created when tasks are released or completed.
History
Private history events called CLAIMTASK and RELEASETASK are logged in the workflow's corresponding history. History events for completing tasks are recorded by the complete task form action field.
_received
When a message or signal is received, process variables called _MESSAGE_received or _SIGNAL_received are created.
These variables are JavaScript objects with the following form:
{
"user": "<user who sent message/signal>",
"proxyUser": "<user who sent message/signal on behalf of user>",
"time": "<time message/signal was sent in ISO format>"
}
The prefix is set by the message reference/message name.
_finalHistoryDescription
When a process instance starts it also generates a history using the platform's History service. As tasks and activities are performed they are recorded as events in the history. When the process instance ends a final event is added to the history, marking it as complete (sealing the history).
This final event is a standard event generated by the workflow engine. Its default description is "Process Ended". The description of this final event can be set by creating a process variable named
If you set
function(helper, processVars) {
processVars._finalHistoryDescription = "I was started with #_startForm#";
return processVars;
}
Setting Additional Universal Process Variables
Additional variables can be added to every process instance by defining them in the configuration sent to the Workflow worker. This is done using the
For example, including:
{
"name": "workflow",
"instances": 1,
"threadsPerInstance": 5,
"processConfig" : {
"SITEURL" : "http://demodev1.gossinteractive.com/toptasks/",
"SELFSERVEURL" : "http://demodev1.gossinteractive.com/toptasks/selfserve"
}
}
Would result in the following being available in every process instance:
Share this page
