Flow control activities
The following activities are database activities: Their main task is to coordinate the other activities.
Start and End: allow you to show the start and end points of a workflow. Refer to Start and end.
Fork: allow you to activate all outbound transitions. Refer to the Fork section.
Appointment: lets you wait for several tasks started at the same time to be completed before proceeding. Refer to the Fork section.
Scheduler: lets you define a workflow execution schedule. Refer to Scheduler.
Test: enables a transition based on a test result. Refer to Test.
Wait: enables the outbound transition after a given time limit. Refer to Wait.
Time constraint: lets you pause a task for a set period. Refer to Time constraint.
Sub-workflow: lets you execute another workflow. Refer to Sub-workflow.
Jumps: lets you implement transitions without links. Refer to Jump (start point and end point).
External signal: lets you enable the outbound transition after receiving an external signal. Refer to the External signal section.
Approval: lets you send an email to an operator or a group of operators and wait for approval to continue with the execution. Refer to the Approval section.
Alert: lets you send a warning to an operator or group of operators. Refer to the Alert section.
Task: lets you configure task execution. Refer to the Task section.
Start and end
The Start and End activities allow you to graphically mark the start and end of a workflow. These activities have no functional impact and are therefore optional.
Executing a workflow starts with activities without an inbound transition and Start-type activities.
You can configure the End activity to interrupt all tasks that are in progress. To do this, double-click the activity to display its properties, and check the appropriate option.
The data in the worktable is deleted automatically when the end activity is enabled. If this isn't necessary, and to avoid unnecessary loads, you can choose to disable the transition at the last activity output. For example, at a delivery output, if no process is scheduled, uncheck the relevant option as shown below:
A fork lets you launch several activities in parallel.
Double-click the graphic object to define the number of outbound transitions, create a new transition or change the label of the selected transition.
A join triggers its outbound transition only when all inbound transitions are activated, i.e. when all prior activities are finished. This allows you to make sure that certain activities have finished before continuing to execute the workflow.
The outbound sent population of the activity is determined by choosing a main set among the inbound transitions in the activity.
The outbound transition can only contain one of the inbound transition populations. If the activity is not configured, the outbound transition will randomly select one of the inbound populations.
The Scheduler is a persistent task that activates its transition at the times specified by its schedule.
The Scheduler activity should be considered as a scheduled start. The activity positioning rules within the chart are the same as for the Start activity. This activity must not have an inbound transition.
It is a best practice not to schedule a workflow to run more than every 15 minutes because it may impede overall system performance and create blocks in the database.
When building your workflow, never use more than one Scheduler activity per branch. For more on this, refer to: Using activities.
The scheduler defines the activation schedule of the transition. To configure it, double-click the graphical object, then click Change...
A wizard lets you define the frequency and validity period of the activity. The configuration steps are as follows:
Select the activation frequency and click Next.
Give the activation times and days. The parameters for this step depend on the frequency selected in the previous step. If you choose to launch the activity several times a day, the configuration options will be as follows:
Define the validity period of the schedule, or specify how many times it will be executed.
Check the configuration and click Finish to save.
It is important to configure the frequency of the scheduler and certain parameters of the following activities, because the scheduler can generate cascading tasks. For example, the scheduler followed by an external command can re-execute the command even if it has not finished. To avoid this, modify the Behavior field of the activities that have to be finished before a new execution by selecting the The current task has priority option.
Note also that the transition can be activated several hours later if the workflow was executing a long-term task, such as an import, or if the wfserver module was stopped for a time. In this case, it may be necessary to restrict the execution of the task activated by the scheduler to a certain time range.
A Test type activity activates the first transition that satisfies the condition associated with it. If no condition is satisfied and if the Use the default fork option is activated, the default transition will be activated.
You can also insert variables directly from this editor.
Conditions can be added, deleted, or ordered from the activity property edit window, but can also be modified from the transition.
If the result of a calculation is to be reused by different conditions, it is possible to calculate it in the initialization script of the activity. The result must be stored in a variable of the task to be accessed by the condition scripts (task.vars.xxx).
A Wait activity activates its transition after a time delay of anywhere between a few seconds and several months. A wait task does not block the execution of other tasks; the workflow can execute tasks in parallel while this task is pending.
You can enter the label and wait time using the editor, as in the example below:
In the Duration field, the value can be expressed in the unit of your choice: (according to the operator's regional settings):
If regional settings are not specified: s for seconds, m for minutes, h for hours, d for days, y for years. At the time of approval, the value is automatically converted to the most readable unit.
The default unit is the day (d).
Whereas if, for example, the regional settings are set to 'Français': s for seconds, mn for minutes, h for hours, j for days, m for months, a for years. At the time of approval, the value is automatically converted to the most readable unit, as in the example above 90s was converted to 1mn 30s.
The default unit is the day (d).
A Time constraint activity lets you postpone the execution of a task or abandon it.
Enter the label for the activity and specify the time frame during which the workflow task must be paused.
When the Try again later if outside of execution period option is selected, it lets you re-start the task outside of the execution time frame. if you want the workflow action to be abandoned for good after its suspension, deselect this option.
The Sub-workflow activity lets you trigger the execution of another workflow and recover the result. This activity lets you use complex workflows while using a simplified interface.
You can call multiple sub-workflows in a single workflow. Sub-workflows are executed synchronously.
For the sub-workflow to be run correctly, you must have only one "arrival" type jump with the lowest number, and only one "start" type jump with the highest number. For example, if you have "start" type jumps with a priority of 1, 2, and 3, you should have only one "start" type jump with a priority of 3.
Create a workflow that you will use as a sub-workflow in another workflow.
Insert a Jump (end point) activity with a priority of 1 at the beginning of the workflow. If you have multiple "arrival" type jumps, Adobe Campaign will use the "arrival" jump with the lowest number.
Insert a Jump (start point) activity with a priority of 2 at the end of the workflow. If you have multiple "start" type jumps, Adobe Campaign will use the "starting" jump with the highest number.
If the sub-workflow activity references a workflow with several Jump activities, the sub-workflow is executed between the "arrival" type jump with the lowest number and the "start" type jump with the highest number.
Complete and save this "sub-workflow".
Create a "master" workflow.
Insert a Sub-workflow activity and open it.
Select the workflow that you want to use from the Workflow template drop-down list.
You can also add a configuration script to alter the referenced workflow.
Click Ok. It will automatically create an outbound transition with the label of the Jump (start point) activity from the selected workflow.
Run the workflow.
Once run, the workflow that was called as a sub-workflow is still in Being edited status, which means the following:
You cannot right-click the transitions to display the target.
The count of intermediate populations cannot be displayed.
The logs are aggregated in the "master" workflow and they are only labelled as "subworkflow".
Indeed, this workflow is only a template. A new sub-workflow based on this template is created when called from the "master" workflow.
Input parameters (optional)
Each inbound event must specify a target defined by these parameters.
This set of three values identifies the population targeted by the query. tableName is the name of the table that records the target identifiers, schema is the schema of the population (usually nms:recipient) and recCount is the number of elements in the table.
This value is the schema of the work table. This parameter is valid for all transitions with tableName and schema.
Jump (start point and end point)
Jump-type graphical objects are used to improve the readability of a complex diagram, particularly one with crossing transitions.
Jumps are transitions without arrows: They go from one activity to another, as in the following example.
For each "start point"-type transition, an "end point"-type transition must be positioned.
You can insert several start point and end point jumps in the same workflow. They are identified by a number that must be entered in the parameters:
To improve the readability of the diagram, you can change the image associated with jumps to display the related number. See Managing activity images.
The External signal activity lets you trigger execution of a set of tasks in a workflow to a schedule.
When an 'External signal' task is activated, it is paused indefinitely or until the end of the specified time period. Its transition is activated by the SOAP call PostEvent(sessionToken, workflowId, activity, transition, parameters, complete). The complete parameter allows the task to be finished, so it will not react to subsequent calls.
Refer to the online documentation concerning SOAP calls for further information on the PostEvent function.
You can configure this activity in order to define events if no signal is received. To do this, edit the activity and click the Expiration tab. Click the Insert button to create and configure an event.
The configuration of expirations is detailed in Expirations.
The Delay field lets you specify an expiration delay in the units of your choice. See Wait.
Each line represents a type of expiration and coincides with a transition.
An Approval task requires the participation of an operator. The operator is assigned a task and can respond by email, using the Web page linked in the email message, or via the console.
By default, approval is assigned to a group of operators. This group represents a role, e.g. 'Newsletter content group' or 'Newsletter targeting group'. Each operator in the group can answer, but only the first reply is taken into account (except in the event of multiple approvals).
If necessary, you can assign the approval task to a single operator or a set of operators defined by a filter.
To select a single operator, select the Operator value in the Assignment type field and select the relevant operator in the drop-down list of the Assignee field.
Only the chosen operator will be authorized to approve the task.
You can define a query for filtering approving operators. To do this, select the Filter value in the Assignment type field and click the Advanced parameters... link to define filtering conditions, as shown in the following example:
In the event of single approval, the transition corresponding to the choice of operator is activated and the task is finished: the other operators cannot reply.
In the event of multiple approvals, transitions corresponding to the choice of each operator are enabled. The task is finished when all operators of the group have replied, or when the task has expired.
This activity does not block processing, and the workflow can perform other tasks while waiting for a reply.
An operator can approve the tasks assigned to that operator from the console. An operator with administrator rights can view and delete the tasks assigned to any operator, but cannot reply to them.
Modifying the title or message body of the activity does not affect the current tasks, but, on the other hand, modifying the possible choices directly affects the current tasks, which automatically inherit the new list of choices.
Approval type tasks are accessible from the Administration > Production > Objects created automatically > Approvals pending node: operators can access the approval form directly via this view.
Customization variables can be used in the message sent to reviewers. They can be inserted into the message title or body.
The lower section of the editor lets you define the list of possible answers. There is a transition corresponding to each answer. The name is the internal identifier, and the label is the text that will be displayed in the list of choices.
Click the Advanced parameters... link to select the delivery template to be used to notify operators. The default template (internal name 'notifyAssignee') takes the title and message, and adds a link to the web page used to answer.
This template can be modified to personalize message layout, but it is preferable to make a copy. The targeting mechanism (external file, target mapping) must not be modified because it is required for notifications to operate correctly.
An approval example is shown in Defining approvals.
Comment related to the response
Identifier of the operator who responded. This field is a numerical value, but a String field.
An Alert activity sends a message to a group of operators. It operates the same way as an approval activity, but no response is expected in this case.
An alert is not persistent, and is therefore not visible from the console. The operators of the assigned group must have a complete email address in order to receive the notification. The configuration of this activity is similar to that of an Approval. The default delivery template used to alert operators is 'alertAssignee'.
In a campaign workflow, the Task activity lets you specify two scenarios: the first if the task is completed and a second if the task is not completed (if it is manually marked as incomplete or if it expires).
How to configure and operate a task is detailed in this section.
The Resources option lets you define several operators as well as an approval schedule for the task. If the person approving rejects, this does not lead to the task itself being rejected.