A plan is a sequence of tasks that are executed manually or based on a schedule. Plans can be used to automate the execution of multiple related tasks, such as all of the outputs generated from a set of multiple related flows.
A snapshot of the objects in the plan is capture. This snapshot defines the set of tasks that are executed as part of a plan run.
NOTE: A snapshot does not capture the objects underlying the tasks. After a snapshot is taken, subsequent changes to the underlying flows could impact the outcome of the flow tasks when they are later executed during the plan run. |
Before you begin, please verify the following:
table-based output
NOTE: In a flow, all recipes that you wish to have executed by the corresponding task must have a defined output object. For each output object, you must create at least one write file or table settings definition. During plan runs, these objects are not validated, and missing outputs are ignored. |
NOTE: Parameter values are applied to a plan, but you cannot apply parameter overrides to the plan. You can apply flow parameter overrides on individual flows, which are applied at the time of plan execution. For more information, see Manage Parameters Dialog. |
Workflow steps:
Identify the tasks that you wish to execute.
NOTE: You must have access to any flows that you wish to execute. See Flows Page. |
Repeat the previous step to add additional tasks as needed.
Tip: You can insert tasks between other tasks. Use the Plus icon between two plan objects. |
Edit the plan and repeat the above steps until the plan is ready for production runs.
Tip: While a plan is in development, you may wish to disable its schedule, which prevents execution according to the schedule. You can still run test executions using the Run Now button. |
To begin, you must create a plan object.
Steps:
In Plan View, you create the objects that are part of your plan. These include:
You can add a schedule object to specify the triggers when the plan is to be executed.
NOTE: A plan's schedule cannot be executed until its schedule has been enabled. If a plan has a disabled schedule, you can still execute it via the Run Now button. |
Steps:
When you first open Plan View, you should see an empty plan:
Plan View - empty plan |
In the Add Trigger panel, you can specify the triggers when the plan is executed. You can specify one or more triggers:
Add trigger(s) |
For each trigger:
Timezone: Specify the timezone that applies to the scheduled time. For more information on timezones, see Supported Time Zone Values.
Frequency: You can specify the frequency of when the schedule is triggered.
In each trigger, you can specify multiple On values (e.g. Same time on Sunday and Monday).
As needed, you can specify the On value using a modified form of cron job syntax. For more information, see cron Schedule Syntax Reference.
To add more triggers, click Add another trigger and specify it.
To delete a trigger, click the X next to it.
Parameter overrides:
Overrides provided in this panel are applied only when the trigger is executed.
NOTE: Multiple values are ok for plan parameters, as long as the parameter values do not conflict. If you see a warning icon next to a set of multiple parameter values, then you must fix this conflict, or the plan fails to execution. For more information, see Manage Parameters Dialog. |
To save your schedule, click Save.
After saving, the schedule is automatically enabled. To disable the schedule, use the slider bar.
NOTE: A plan cannot be executed if the schedule for it has been disabled. |
Based on the schedule's triggers, you can define a sequence of one or more tasks that are executed.
A flow task executes the recipes that produce the output objects of the flow.
Steps:
For more information, see Plan View for Flow Tasks.
An HTTP task is a request sent using HTTP protocol to a target URL, which could be a REST API endpoint.
NOTE: Specifying an HTTP request requires knowledge of the target endpoint and the parameters required for the request. HTTP tasks are considered developer-level objects. |
Steps:
Specify the fields of the request.
Tip: If possible, you should test the HTTP task before you create it. To test for basic connection, you should use the GET method, which just returns relevant information. Some other methods are potentially destructive. |
For more information, see Plan View for HTTP Tasks.
If your plan tasks include flows in which parameters have been defined, you can review and override these parameter values. Overrides are applied when the task is triggered as part of a plan run.
Steps:
Subsequent runs of the plan use this new value as the override for the parameter.
In some scenarios, you may need to branch plan execution steps based on the results of a task in the plan. For example, you may need to send separate messages using an HTTP task depending on whether a flow task succeeds or fails in execution. You can create branches in the plan graph by adding task execution rules and parallel nodes, which run based on the success and failure states of your plan runs.
To begin this simple example:
Next, you create the first HTTP task that results from the above task and the execution rule that determines when it runs.
On success
rule.Steps:
On success
. The HTTP task is executed only when the flow task has run successfully.
Next, you can create the HTTP task that runs when the flow task fails.
Steps:
On failure
. The second HTTP task is executed only when the flow task has failed to execute.
Tip: You can use parallel tasks to create separate paths through a plan when there are no dependencies between the paths. |
Success and Failure tasks |
When the flow tasks complete successfully, the On success
HTTP task sends a message.
When the task fails, the On failure
HTTP task delivers a different message.
After you have created the triggers and tasks of your plan, you can perform a test run of the plan.
Steps:
You can monitor the progress of your plan runs and review all previous plan runs. See Plan Runs Page.