Triggers are start events that allow an external event to initiate the process start. For details on the concept of start event refer to section Start Events of chapter Control Flow in the Key Concepts.
Depending on the type of a trigger, different parameters have to be defined for each trigger.
To add a trigger you can either:
In both cases the new trigger appears under the process tree in the Outline view and in the diagram.
Figure: Adding a Manual Trigger
To delete a trigger, select it in the diagram or in the process tree from the Outline view and choose Delete from the pop-up menu. If you want to delete only the symbol from the diagram, choose Delete Symbol from its pop-up menu.
A trigger has general properties and trigger type specific properties.
In the General Properties section you can property view Element OID and edit properties Name, ID, Description. For details on these properties, please refer to section General Properties of chapter Viewing and Editing Properties of Models and Model Elements.
In the trigger type specific panel of the dialog you can edit the type specific properties. Please refer to section Available Trigger Types for details on available properties of specific trigger types.
Depending on the trigger type the trigger message may be parameterized with additional data. Such trigger parameters are provided at runtime in form of access points allowing for parameter mappings. Parameter mappings may be used to initialize workflow data of the triggered process instance and are configured in the Parameter Mapping panel of the triggers properties dialog. Please refer to the specific trigger type section in this chapter to obtain a detailed description on how to set up the parameter mappings accordingly.
A Camel Trigger allows to start a process by receiving messages from an arbitrary Camel endpoint and passing these into the process the Trigger is defined for.

Figure: Camel Trigger Properties
In the Endpoint Settings section, you can specify the Camel Context ID and choose the Endpoint Type.
The CamelContextID defines the ID of the CamelContext object, which represents the Camel runtime system.
The following Endpoint types are available:
In the Route section you can define additional Camel Route specifications.
An incoming message starts a process passing all the information contained in the body of the message as input data.
To change the specific properties of a JMS trigger, open its properties dialog, where you can - among other options - choose the type of message and add parameters of the JMS message.
Figure: JMS Trigger Properties
In this example we receive a map message. Please refer to Integrating JMS for details on the different message types.
After this configuration we can map the defined parameters to data in our process definition. Select Parameter Mapping and push the Add button to set up a new parameter mapping. A new dialog appears, where you fill in the following parameters:
Figure: Parameter Mappings of a JMS Trigger
An incoming email starts a process passing all the information contained in the email as input data. To change the properties of the mail trigger, open its properties dialog.
Figure: Mail Trigger Configuration
The following server settings are provided:
POP3 (or IMAP) server nameThe following entry fields are provided to specify mail settings to filter for:
javax.mail.search.FromStringTerm). Note, that the
string comparison is case-sensitive.javax.mail.search.SubjectTerm). Note, that the
string comparison is case-insensitive.javax.mail.search.BodyTerm).Select Parameter Mapping on the left side of the Properties dialog to configure the Parameter Mapping. In this case you can map parameters of a mail object to a data modeled in the process. In the figure below you find an example on how to access the string content of a received mail.
Figure: Mail Parameter Mapping
Open the Properties dialog of a created Manual Trigger to change its properties. There you can choose a participant from the list of the Manual Trigger pane.

Figure: Properties of a Manual Trigger
Another possibility to assign a participant to a manual trigger is to connect the participant via transition to the trigger in the diagram:

Figure: Assign a Participant to a Manual Trigger.
Now the participant is entered in the Manual Trigger Participants section in the triggers model property page.
In case you assign a participant pertaining to a department, the manual trigger in the Stardust Portal opens open a dialog, where the user who started the manual trigger can select a department from a list of departments he belongs to.
The Scan Trigger can be used to manage the triggering and starting of Process Instances via a Scan tool. Scan Triggers are non-exclusive, which means that it is possible to have both in one process definition, a Manual Trigger and a Scan Trigger, to allow process instances to be started manually and via a Scan tool.
Via Scan triggers you can create a parameter and define a mapping
of this parameter to an existing process variable of data type
Document or Document List.
For details on using DMS data types, refer to chapter
DMS Data Types
of the
Document Service Integration Guide.
In the properties page of the Scan trigger, you have two specific sections:
Document or Document List and process attachments. Select the data the parameter should be mapped to.
The name of the parameter of the scan trigger is derived from the name of the data.
The Meta Type of the selected document type is displayed in a non editable text field.

If you do not specify data for the scan trigger, then the following validation message is displayed in
the Problems view of the Modeler.

You need to specify either process attachment or document data for the scan trigger.
A process can be started at some point in time (Start Timestamp), whereby multiple instances of the process can be created, depending on the defined periodicity. Additionally, a Stop Timestamp can be configured if the periodicity should end at a certain point in time.
In the Properties dialog of the timer based trigger you can change its specific properties.