Interaction Designer - Triggers
Overview
Triggers are used to start workflows within an interaction. RPI supports four types of trigger:
Manual
Scheduled
Recurring
Activity State
Manual Trigger
As its name implies, a manual trigger is used to manually initiate activity within a workflow.
The following options are available in the mini toolbar when you select a manual trigger:
Activate Trigger button: used to initiate execution of a manual trigger’s workflow.
Rollback current Workflow Instance: only available post-completion of production execution. Removes the workflow instance entirely.
Play/Pause workflow instance:
If the currently-executing activity’s status is Playing, the button is enabled. Its accompanying tooltip reads Pause workflow instance. Invocation pauses the workflow instance.
If the currently-executing activity’s status is Paused, the button is enabled. Its accompanying tooltip reads Play workflow instance. Invocation plays the workflow instance.
If the currently-executing activity’s status is not Playing or Paused, the button is not displayed.
Stop workflow instance: the button is only available if the currently-executing activity’s status is Playing or Paused.
Reactivate trigger: this button is only available when a workflow instance is Stopped in Production mode.
View results: displays the Results Window, within which the current workflow’s results are displayed.
Show configuration panel
A manual trigger’s configuration panel contains General, Prioritization, Auto Replay and Alerts tabs:
The General tab contains a label advising that no configurable settings exist for a manual trigger (Input Workflow is documented separately).
Constraints and Input Workflow sections are displayed. They are covered separately in this documentation.
The Prioritization and Alerts tabs are also documented separately.
Scheduled Trigger
A scheduled trigger is used to initiate activity within a workflow at a specified date and time.
The following options are available in the mini toolbar when you select a scheduled trigger:
Activate/Deactivate trigger:
If the interaction contains no unsaved changes, the workflow’s active status is Inactive and the interaction contains no validation errors, the button is enabled and its tooltip reads Activate trigger. Invocation causes the workflow to enter a Waiting for Trigger status.
If the workflow’s status is Inactive and the interaction has validation errors, the button is enabled and its tooltip reads Activate trigger. However, attempting to activate the trigger causes display of a warning message, and the workflow is not activated.
If the workflow’s status is Waiting for Trigger, the button is enabled and its tooltip reads Deactivate trigger. You can re-activate the trigger if required.
Rollback current Workflow Instance: only available post-completion of production execution. Removes the workflow instance entirely.
Fire trigger: fires the trigger immediately, creating a workflow instance.
Play/Pause workflow instance:
If the currently-executing activity’s status is Playing, the button is enabled and its tooltip reads Pause workflow instance. Invocation pauses the workflow instance.
If the currently-executing activity’s status is Paused, the button is enabled and its tooltip reads Play workflow instance. Invocation plays the workflow instance.
If the currently-executing activity’s status is not Playing or Paused, the button is disabled.
Stop workflow instance: only available if the currently-executing activity’s status is Playing or Paused.
Reactivate trigger: this button is only available when a workflow instance is Stopped in Production mode.
View results: displays the Results Window, within which the current workflow’s results are displayed.
Show configuration panel
A scheduled trigger’s configuration panel contains General, Prioritization, Auto Replay and Alerts tabs:
The General tab contains the following properties:
Scheduled date: the date and time at which the trigger will fire. Scheduled date defaults to the time the trigger was added to the workspace. You can specify it manually, or by using a calendar control. The property is accompanied by an information tooltip:
Time Zone: you can specify the time zone to be used when the trigger fires. The property defaults to the current time zone. Note that changing the Time Zone will have an effect on the displayed time, which may need to be adjusted to reflect the selection.
Input workflow: optionally, you can elect to define an input workflow for the scheduled trigger. This property is documented separately elsewhere as it shared across all trigger types
Constraints and Input Workflow sections are displayed. They are covered separately in this documentation.
The Prioritization and Alerts tabs are also documented separately.
Recurring Trigger
Essentially an extension of the scheduled trigger, not only does a recurring trigger allow you to specify the date and time at which a workflow will start, but also the number of instances of the workflow that will execute, in addition to a wealth of recurrence options. As a simple example, you could use a recurring trigger to initiate regular, monthly campaigning activity across a whole year.
The following options are available in the mini toolbar when you select a recurring trigger:
Activate/Deactivate trigger:
If the interaction contains no unsaved changes, the workflow’s active status is Inactive and the interaction contains no validation errors, the button is enabled and its tooltip reads Activate trigger. Invocation causes the workflow to enter a Waiting for Trigger state.
If the workflow’s status is Inactive and the interaction has validation errors, the button is enabled and its tooltip reads Activate trigger. However, attempting to activate the trigger causes display of a warning message, and the workflow is not activated.
If the workflow’s status is Waiting for Trigger and a workflow instance has not yet been created, the button is enabled and its tooltip reads Deactivate trigger. You can re-activate the trigger if required.
If the workflow’s status is Waiting for Next Trigger, the button is enabled and its tooltip reads Deactivate trigger. Invocation causes the workflow to assume a Completed status. You can re-activate the trigger if required.
If you have created a workflow instance in a production recurring workflow, you can make changes to its configuration post-deactivation.
If you deactivate a production recurring workflow that has yet to create a workflow instance, you can make changes to its configuration.
You cannot execute in Test mode a deactivated Production recurring workflow.
Rollback current Workflow Instance: only available post-completion of production execution. Removes the most recent workflow instance entirely.
Fire trigger: fires trigger immediately, creating the next workflow instance.
Play/Pause workflow instance:
If the currently-executing activity’s status is Playing, the button is enabled and its tooltip reads Pause workflow instance. Invocation pauses the workflow instance.
If the currently-executing activity’s status is Paused, the button is enabled and its tooltip reads Play workflow instance. Invocation plays the workflow instance.
If the currently-executing activity’s status is not Playing or Paused, the button is disabled.
Stop workflow instance: only available if the currently-executing activity’s status is Playing or Paused.
View results: displays the Results Window, within which the current workflow’s results are displayed.
Show configuration panel
A recurring trigger’s configuration panel contains General, Prioritization, Auto Replay and Alerts tabs:
The General tab contains the following properties:
Trigger section:
Create: this dropdown field allows you to define whether the recurring workflow will create a single or multiple workflow instances. It exposes the following values:
Single workflow instance: the default value. If this is selected, when the trigger is activated, a single workflow instance will be created. Any contacts targeted within the workflow will only ever be contacted once.
New workflow instance each time trigger fires: selecting this option allows the recurring trigger to be responsible for the creation of multiple workflow instances. If a contact is targeted within a workflow instance, he or she may also be contacted within the others, meaning that the recurring trigger can be responsible for the same person receiving communications multiple times.
Start at: the date and time at which to commence creating workflow instances. Start at defaults to the date and time at which the trigger was added to the interaction.
It refers to the date and time at which the system will begin checking as to whether to create a new workflow instance; for example, if set to 06:00 and scheduled to fire Daily, Once every 1 day at 18:00, the trigger would fire at 18:00, not 06:00. Between 06:00 and 18:00 the trigger's status would be Waiting for Trigger.
An information icon is displayed to the right of the property. Hovering over it displays a tooltip:
You can specify Start at manually, or by using a calendar control. Provision of a Start at date/time is mandatory.
’and’: a dropdown is provided, exposing the following values, each of which necessitates additional configuration:
never end: this value is selected by default and specifies that the recurring trigger will continue creating workflow instances, in accordance with its configuration settings, in perpetuity. No other configuration accompanies selection of this value
end after: this value indicates that the trigger will create a specific number of workflow instances. When selected, an accompanying text field is displayed (‘event(s)’) that defines the number of workflow instances to be created. Provision of this integer value, which defaults to 2 and which must be greater than 0, is mandatory.
end by: if this value is selected you must define a date and time at which the recurring trigger will cease creating workflow instances. The date defaults to today’s date + 1 week; the time defaults to the trigger’s original Start at time (the time at which the trigger was added to the interaction). You can set the date/time manually, or by using a calendar control.
Recurrence section:
Daily/Weekly/Monthly/Manual: four tabs are presented within the section. Selection of one of Daily, Weekly, Monthly or Manual defines the basis upon which workflow instances will be created by the recurring trigger.
Daily is selected by default. If selected, the following fields are shown :
Once every…: this field is accompanied by a radio button that is selected by default (its counterpart is Every…, which is also accompanied by a radio button). If the radio button is selected, the following fields are enabled:
Day(s): a mandatory integer that defaults to 1, and which must be greater than 0.
At: separate, mandatory hour and minute fields that default to the time the trigger was added to the interaction. An information icon is displayed to the right of the properties. Hovering over it displays a tooltip:
Every…: this field is accompanied by a radio button and is a counterpart to Once every…. If selected, the following fields are enabled:
Duration: a mandatory integer that defaults to 1, and which must be greater than 0.
[units]: a dropdown field exposing the values minute(s) and hour(s) (the default).
From: a mandatory hour and minute field that defaults to 00:00. An information icon is displayed to the right of the property. Hovering over it displays a tooltip:
To: a mandatory hour and minute field that defaults to 23:59. An information icon is also shown to the right of the property.
Only fire trigger on specific days of the week: this switch allows you to specify that the trigger should only fire on the selected day(s) of the week. It is switched off by default. When on, separate checkboxes are displayed for each day of the week. All are checked by default.
If firing missed, trigger will fire as soon as able to. Thereafter: this property is displayed when a recurring trigger's Recurrence is set to Daily, Every... is selected and units is set to hour(s). It allows you to define the action to be taken when an hourly trigger is unable to fire. A dropdown field, it exposes the following values:
'Commence hourly schedule based on new most recent firing time' (the default)
'Continue original hourly schedule based on Start at time'
When set to Commence..., if the trigger fails to fire due to the Node Manager service's unavailability:
The trigger fires as soon as the service becomes available.
The next firing time occurs in one hour's time.
An hourly cadence is maintained thereafter.
When set to Continue...:
The trigger fires as soon as the service becomes available.
The next firing time occurs when the trigger's Start at time is reached.
An hourly cadence is maintained thereafter.
If Weekly is selected, the following are shown to the right of the General tab:
‘Every’
Week(s): a mandatory integer that defaults to 1, and which must be greater than 0.
At: a mandatory hour and minute field that defaults to the current time. An information icon is displayed to the right of the properties. Hovering over it displays a tooltip:
on: one separate checkbox is provided for each day of the week. The current day is checked automatically.
If Monthly is selected, the following fields are shown to the right of the General tab:
Specific day of month: accompanied by a radio button that is selected by default (its counterpart is Relative day of month, which is also accompanied by a radio button). If the radio button is selected, the following are enabled:
Day: a mandatory integer, which must be greater than 0. Day [x] defaults to today’s date. If set to e.g. ‘31’, the trigger will fire on the last day of the month if the same falls on another date.
Of Every: a mandatory integer that defaults to 1, and which must be greater than 0.
‘month(s)’
At: a mandatory hour and minute field that defaults to the current time. An information icon is displayed to the right of the properties. Hovering over it displays a tooltip:
Relative day of month: accompanied by a radio button and is a counterpart to Specific day of month. If selected, the following fields are enabled:
On The: a dropdown field that exposes the following values: first (default), second, third, fourth and last.
[Day of week]: a dropdown that lists the days of the week, which defaults to the current day. In addition, two other values – weekday and weekend day – are also available
Of Every: an integer that defaults to 1.
‘month(s)’
At: a mandatory hour and minute field that defaults to the current time. An information icon is displayed to the right of the property. Clicking it displays a tooltip:
Offset By: two fields accompany this setting, which allows you to adjust the trigger’s scheduled firing time by pulling it forward or pushing it back by a given number of days:
[n]: this integer value defaults to 0 and can be maximum of 999.
[offset type]: this dropdown field exposes values ‘None’ (the default), ‘day(s) after’ and ‘day(s) before’.
Manual tab: allows you to fire the trigger on an ad hoc, manual basis.
Time Zone: this dropdown property allows you to specify the time zone within which the trigger's recurrence pattern will operate. It defaults to the local time zone. Note that the specified time zone only affects the trigger's recurrence once active; its Start time will be acted upon on a local basis. Note also that changing the Time Zone will have an effect on the displayed time, which may need to be adjusted to reflect the selection.
Input Workflow: optionally, you can elect to define an input workflow for the recurring trigger. This property is documented separately elsewhere as it shared across all trigger types.
Note that all time values specified reference your local time setting.
Constraints and Input Workflow sections are displayed. They are covered separately in this documentation.
The Prioritization and Alerts tabs are also documented separately.
Activity State Trigger
An activity state trigger is used to initiate workflow activity when one or more activities within a preceding workflow start or complete. The activities contained in the activity state’s workflow can optionally act upon the data set output by the preceding workflow.
The following options are available in the mini toolbar when you select an activity state trigger:
Activate/Deactivate trigger: if the interaction contains no unsaved changes, the workflow’s active status is Inactive and the interaction contains no validation errors, this button is enabled and its tooltip reads Activate trigger. Invocation causes the workflow to activate. If the conditions in respect of the trigger’s input workflow have not been met, the trigger enters a Waiting for trigger state. If the conditions have been met, the workflow commences Playing. This also occurs at the point at which the conditions are met.
If the workflow’s status is Inactive and the interaction has validation errors, the button is enabled and its tooltip reads Activate trigger. However, attempting to activate the trigger causes display of a warning message, and the workflow is not activated.
If the workflow’s status is Waiting for Trigger, the button is enabled and its tooltip reads Deactivate trigger. You can re-activate the trigger if required.
Rollback current Workflow Instance: only available post-completion of production execution. Removes the workflow instance entirely.
Play/Pause workflow instance: if the currently-executing activity’s status is Playing, the button is enabled and its tooltip reads Pause workflow instance. Invocation pauses the workflow instance.
If the currently-executing activity’s status is Paused, the button is enabled and its tooltip reads Play workflow instance. Invocation plays the workflow instance.
If the currently-executing activity’s status is not Playing or Paused, the button is disabled.
Stop workflow instance: only available if the currently-executing activity’s status is Playing or Paused.
Reactivate trigger: this button is only available when a workflow instance is Stopped in Production mode.
Fire trigger: this option is available when the trigger is in a Waiting for Trigger state, and when its Use data from input workflow property is unchecked. It allows you to manually override the rules governing the point at which the trigger is scheduled to commence execution.
This means that, should something untoward occur within the trigger’s preceding workflow, you always have the option to commence execution at the activity state trigger. Key to availability of this option is the fact that the trigger does not source its input data from the preceding workflow – in such a case this option would not be viable, due to non-availability of input data at the point of the trigger’s being fired manually.
View results: displays the Results Window, within which the current workflow’s results are displayed.
Show configuration panel
An activity state trigger’s configuration panel contains General, Activities, Prioritization, Auto Replay and Alerts tabs.
The General tab displays a message:
You can select an Input Workflow using the dropdown, which lists all other workflows’ triggers within the interaction. Having selected an Input Workflow, you can clear it. Selection of an Input Workflow is mandatory for an activity state trigger.
Note that an activity state trigger does not support selection of a queue listener Input Workflow.
A checkbox (Use data from input workflow) is displayed at the bottom of the General tab. It is checked by default. If checked, the input data for the activity state trigger's workflow will be sourced from its input workflow – you must define within any activities downstream from the activity state trigger the fulfillment states that are to apply. For example…
…in this case, all records output by ‘Basic Email Offer’ (i.e. those in a ‘Targeted’ state) will serve as the input to ‘Basic Email Offer 2’.
If Use data from input workflow is unchecked, the trigger's workflow's data will be sourced independently from its input workflow. This means that the activity state workflow remains entirely independent from the input workflow (other than in activity within the latter initiating activity within the former). In this case it is mandatory for the activity state workflow to contain an audience.
Constraints and Input Workflow sections are displayed. They are covered separately in this documentation.
The Activities tab contains the following:
Start when: defines the type of conditions within the input workflow that must be met before activity state execution can begin. The dropdown exposes the following values:
Any one of the selected items starts playing
Any one of the selected items completes
All of the selected items complete (default)
When no input workflow has been selected, a message is shown:
When an input workflow has been selected, the panel below Start when… lists all of the input workflow’s activities following its trigger:
Each is accompanied by a checkbox. It is mandatory to select at least one checkbox. By selecting checkboxes, you define the activities within the input workflow to which the conditions defined by Start when will apply.
The Prioritization and Alerts tabs are documented separately.
Note that a validation error is raised in the event of an activity state trigger's Input Workflow being configured with a recurring, multi-instance workflow.
Prioritization Tab
The Prioritization tab is displayed at all trigger types. It allows you to configure properties that relate to the prioritization of the trigger's workflows.
The tab contains the following:
Priority: if workflow prioritization is enabled at the current RPI tenant, this property allows you to set the priority of any activity in workflow instances created by the trigger. A dropdown property, it exposes values Urgent, Normal (the default) and Low.
Override Maximum Queue Time: this property allows you to override the system default for how long an activity within the workflow can wait on the queue. A checkbox, it is unchecked by default. When checked, the Maximum Queue Time Override property is enabled.
Maximum Queue Time Override: this property accompanies Override Maximum Queue Time, and set to 1 day by default.
Urgent Deadline: this field allows you to specify the date and time at which any activity within the workflow will become Urgent priority. It is blank by default.
Override Maintenance Mode Buffer: this property allows you to override the system default for the amount of time prior to scheduled maintenance during which activities will be placed on the wait queue. A checkbox, it is unchecked by default. When checked, the Maintenance Mode Buffer Override property is enabled.
Maintenance Mode Buffer Override. This property accompanies Override Maintenance Mode Buffer, and is set to 5 minutes by default.
Details on the impact of prioritization settings on workflow execution are provided elsewhere in the documentation.
Auto Replay Tab
The Auto Replay tab is displayed at all trigger types. It allows you to specify how RPI will behave in the event of the occurrence of certain types of error.
The tab contains the following:
Number of retries: this integer property defaults to 0, and accepts a maximum of 99. It allows you to specify the number of times RPI will attempt to perform retries upon the occurrence of one of the specified errors.
Error Messages: this property consists of a toolbar and a list of error messages.
Toolbar: exposing the following:
Add new Error Message: clicking this button adds a new error message to the list. The new message's default text is '[replace with error message for retry]'.
Remove selected Error Messages: clicking this button removes the selected error message(s).
List of error messages: you can optionally specify a series of error messages. An error message is a string of characters, which, when an error occurs, RPI will attempt to match to the resultant error's message text. If a partial match occurs, RPI will retry the action that caused the error to occur. Retries will be performed a number of times in accordance with the Number of retries setting, and retry details written to the activity’s execution log. The delay between retries increases each time to a maximum of one hour.
Each entry in the list must contain a text string.
Alerts Tab
The Alerts tab is displayed at all trigger types.
It allows you to configure the following types of alerts (for more details on alerts, please see the Framework documentation):
Interaction Audience Complete - Production
Interaction Audience Complete - Test
Interaction Fulfillment Complete - Production
Interaction Fulfillment Complete - Test
Two properties facilitate customization of these alerts:
Custom email subject text: this optional text property allows you to customize alerts' subject lines. It is set using the Design Alert Description Format dialog.
On configuration of Custom email subject text, a summary thereof is displayed at the property.
Custom email content heading: this optional text property allows you to customize the first line of text to be shown in the aforementioned alerts. It is also set using the Design Alert Description Format dialog (see above for further details).
Input Workflow
The Input Workflow property is available within the General tab for all trigger types.
Input Workflow is used to indicate that the input data set for the current trigger’s workflow will be constrained to some of the records targeted by the Input Workflow.
If no other workflows are available to serve as input workflow, a message is shown at the property:
Use of Input Workflow at the activity state trigger is discussed within that trigger type’s documentation.
For all triggers other than the activity state trigger, Input Workflow is optional. The property is set using a drop-down that lists the names of all other workflows’ triggers within the interaction, in alphabetical order. Having selected an Input Workflow, you can clear it.
You can only select a queue listener workflow as an input workflow in the event that contains at least one queue activity that generates offer history.
On selection of an Input Workflow, the Inputs tabs of all activities downstream from the trigger list all of the input workflow’s fulfillment channels, along with fulfillment states for each.
At the first tree level, you can select fulfillment channels. Having selected a channel, at the second tree level, you can select specific fulfillment states within it. Any records in the selected state(s) at the point of the activity’s execution will serve as its input data set. A validation error is raised if no inputs are selected.
Having specified an Input Workflow you can, if desired, attach a fulfillment activity directly to the trigger in question without a validation error being raised:
If a trigger’s Input Workflow has been set, on attachment of downstream activities to the trigger, their inputs are set automatically to the Targeted state within the first of the Input Workflow’s channels.
If an Input workflow is specified, all fulfillment activities within the current workflow must be named differently to fulfillment activities within the input workflow.
At execution of a trigger with an Input Workflow, the dataset upon which the workflow’s activities act is determined by the fulfillment state selections described above.
If attempt is made to execute an activity in a workflow when an Input Workflow has not provided data (e.g. has yet to run), the activity enters a Paused state. You can view details as to why the activity was Paused in its log.
If an input workflow executed in production mode, following execution of the Fulfillment state flow counts update system task, a second workflow can utilize for input purposes any fulfillment state counts generated by the first workflow. This applies even if the second workflow is to execute in Test mode.
Constraints
Trigger constraints are available at all four trigger types, and also within the wait for event activity. They are shown within the General tab within a trigger’s configuration panel
When you elect to display trigger constraints within a configuration panel, the button toggling display of trigger details and constraints reads Show trigger.
The trigger constraints panel contains the following:
Constraints list: a list of database rule and external trigger constraints.
If a database count constraint, the following properties are shown:
Information icon: hovering over the small info icon to the right of the constraint’s title displays this tooltip:
Selection rule: mandatory. You can browse those folders within the RPI file system to which you have access to choose a selection rule; you can also drag a selection rule from the toolbox.
Once you have chosen a selection rule, you may clear it. You can also open the latest version of the selection rule. If the Rule Designer is already open, the rule is shown there. If it is not, a new instance of the Rule Designer is opened to display the rule.
Use of selection rules with auxiliary database resolutions is supported in this context.
Operator: you can choose an operator for the constraint using a drop-down list, which defaults to >= (more than or equal to).
Value: a mandatory integer, which defaults to 0.
Options: exposing a single Remove option.
If an external trigger constraint, the following properties are shown:
Information icon: hovering over the small info icon to the right of the constraint’s title displays this tooltip:
GUID: a system-generated value that is unique to the workflow. The GUID is used by a caller to identify the specific trigger constraint that is to be satisfied. Note that if you save an interaction as another name, a new GUID is generated.
Information icon. Clicking the icon displays a dialog, which describes how the trigger constraint can be satisfied (using either an HTTP post or a SQL Server stored procedure):
An external application can call RPI, using either of the methods described, to satisfy the trigger constraint.
You can copy the contents of the dialog to the clipboard.
Stop checking at: only relevant if a manual, scheduled or activity state trigger. This date/time value is optional, and no default is set. The field can be populated manually or by using a calendar control.
The property is accompanied by an information tooltip:
Options: exposing a single Remove option.
Add Trigger Constraint: invoking this button allows you to select the type of trigger constraint you wish to add from a menu (database count or external trigger constraint). Note that, when configuring a wait for event, you may only add database count constraints. Invocation creates a new, unconfigured constraint of the appropriate type within the constraints list.