Workflows within an interaction are executed independently of one another. A workflow’s execution commences with the activation or firing of its trigger. A workflow with a manual trigger commences execution immediately upon activation (subject to trigger constraints); scheduled and recurring triggers are activated and, at an appointed time, fired automatically (you can override the schedule by firing a trigger manually if required). Activity within a workflow controlled by an activity state trigger only commences when the criteria defined within the trigger’s configuration are realized.
For more detail on activating manual and scheduled/recurring workflows, please see the separate sections on these subjects.
If interaction and/or offer approvals are enabled within the current RPI server installation, certain approval criteria may need to be met before an interaction workflow can be executed. Full details of such criteria can be found in the File Approval documentation.
When a trigger is activated, the system checks that all audiences within its workflow are valid. If not, you are presented with a list of validation errors and the workflow is not activated. The following validation constraints are applied:
•All required joins must exist.
•All required database tables must exist in the RPI catalog.
•All required database columns must exist in the RPI catalog.
•Metadata to be written into the offer history meta table must be accordant with that table’s data types.
Following the firing of a workflow’s trigger, workflow activities within a given workflow branch are executed in sequence. Separate workflow branches are executed in parallel.
The currently-executing activity (if one exists) is surrounded by green halo.
If an activity’s execution fails, it is surrounded by a red halo.
Similarly, an expired workflow’s activities are surrounded by red halos. Workflow expiry occurs after a defined period of inactivity within an executing workflow.
A Completed activity is not surrounded by a halo.
Note that the input to any activity is constrained by the output of its preceding activity; for example, an offer may only be addressed to the records defined by a preceding audience.
If you attempt to execute an interaction workflow that contains a batch audience or interactive activity using an audience that is configured with a restricted audience definition, or, through its blocks, a restricted resolution level, a Permission Denied message is displayed and you may not proceed with the execution.
The same applies when the workflow contains an export activity using an export template configured with a restricted resolution level, or an offer activity, broadcast, export activity or control configured with a restricted channel.
Note also that if you attempt to execute an interaction workflow containing an offer activity using a channel that requires authorization, but which has not been authorized, a runtime validation error is raised.