The Workflow Worker powers the GOSS BPMN workflow implementation. It provides an interface to the Workflow Engine via the API Server.
The GOSS workflow implementation makes it possible for business processes to be designed and executed. These processes can involve any number of site users. By using making use of site user aliases, iCM users can also start these processes and complete assigned tasks from within iCM itself. This worker is the runtime engine for iCM workflows.
For information about using the Workflow Process Modeller, see Workflow Processes.
All references to users or user IDs within workflow definitions are to account usernames. These will likely be GUID style names returned from third party providers or generated by the platform during the site registration process. These are not login usernames. Similarly any references to site groups or group IDs are user group names set up in iCM.
Where date parameters are specified these should be supplied as ISO8601 date strings given in UTC, eg 2018-09-30T08:43:56Z
Process Definition Names, Keys and IDs
When you create a model you give it a name. This user-friendly name is displayed in the modeller and saved as the processDefinitionName.
"processDefinitionName": "Our First Process"
The name, with spaces removed, becomes the processDefinitionKey.
When you deploy your model, or redeploy your model so you get a new version, the key is combined with the version number and a unique ID, giving you the processDefinitionId.
|Not set by default. If true, any queries made using getQueryTasks will exclude tasks from suspended processes if the "suspended" key is not set in your filter
|Default: true. Must be set as true if you want to index process instance and task data in SOLR
|Default: true. Error emails are disabled by default