Start events are always catching. Conceptually, the event is always waiting for a certain trigger, like a form submission, a timer or a message.
Start Event
A basic start event technically means that the trigger for starting the process instance is unspecified. This means that the engine cannot anticipate when the process instance must be started. The basic start event is used when the process instance is started through a form calling the process, or for sub processes called by other processes using a call activity.
| Property | Description |
|---|---|
| ID | An optional unique ID for this element. The modeller will assign a random ID if left blank |
| Name | A name for this element |
| Description | An optional description for this element |
| Initiator | Sets the variable name in which the authenticated user id of the person who starts an instance of this process will be stored. By default this will be "initiator" and we don't recommend changing it |
| iCM Form | This property can be left blank |
Start Timer Event
A timer start event is used to start a process instance at a given time. Instances can start at a set date and time, a time period after the model is deployed, or repeat on a cycle.
The timer event is scheduled as soon as the process is deployed. When a new version of a process with a start timer event is deployed, the job for the previous instance's timer is removed. The reasoning is that normally you won't want to keep automatically starting new process instances of old versions of the process.
Process Variables
Instances started by timers bypass the Workflow worker's startProcess function. This means that all of the standard process variables normally present in a process instance are not generated. This also means that instances started by timers do not have business keys
| Property | Description |
|---|---|
| ID | An optional unique ID for this element. The modeller will assign a random ID if left blank |
| Name | A name for this element |
| Description | An optional description for this element |
| Start Date | The date and time on which an instance of this process should start |
| Time Duration | The duration between the process being deployed and an instance of it starting |
| Time Cycle | Start multiple instances of this process on a defined cycle. The cycle will begin when the process is deployed |
The Timers article in the knowledge base has more information about setting up durations and time cycles.
Start Message Event
A message start event can be used to start a process instance using a named message.
The message references of message start events (ie the messages each start event is listening for) must be unique. This applies to start events within a model and across all deployed processes. The workflow engine will throw an error if you try to deploy a model where references aren't unique.
When a new version of a process definition is deployed, the message subscriptions of the previous version are cancelled. This is also true for message events that are not present in the new version.
| Property | Description |
|---|---|
| ID | An optional unique ID for this element. The modeller will assign a random ID if left blank |
| Name | A name for this element |
| Description | An optional description for this element |
| Message Reference | The name of the message that should start an instance of this process |
Start Signal Event
A start signal event can be used to start a process instance using a named signal. The signal can be "fired" from within a process instance using the intermediate signal throwing event or through the workflow worker API. In both cases all process definitions that have a start signal event with a matching signal reference will be started.
| Property | Description |
|---|---|
| ID | An optional unique ID for this element. The modeller will assign a random ID if left blank |
| Name | A name for this element |
| Description | An optional description for this element |
| Signal Reference | The name of the signal that should start an instance of this process |
Start Error Event
A start error event can be used to trigger an Event Sub Process. An error start event cannot be used to start a process instance. A start error event is always interrupting.
See the Workflow Error Handling knowledge base article for an example.
| Property | Description |
|---|---|
| ID | An optional unique ID for this element. The modeller will assign a random ID if left blank |
| Name | A name for this element |
| Description | An optional description for this element |
| Error Reference | The name of the error that should start this sub process |
Share this page
