Time & Dependencies

Usually, tasks in Workflows start as soon as their predecessors have finished. However, you can define multiple parameters in their properties that affect the task sequence in the Workflow. In the Time & Dependencies properties tab you define the following time and status parameters that determine when a task actually starts:

Earliest and the latest start time at which the task should start
Checkpoints that help you monitor the behavior of the Workflow
Predecessor status dependencies

Using Live Estimated Runtime (ERT) with Time and Dependencies

ERT only considers the Earliest Start Time for evaluation and not the Latest End Time.

Example:

Consider the following linear Workflow with three tasks:

Task 1 with an ERT of 30 minutes
Task 2 with an ERT of 30 minutes and the Earliest Start Time: 12:00
Task 3 with an ERT of 30 minutes and Latest End Time: 13:00

If the Workflow starts at 11:00 am, the ERT should be 120 minutes and not 90 minutes. This is because Task 2 can only start at 12:00. If Task 2 is delayed, the estimates will not be adjusted, therefore Task 3 will not meet its Latest End Time. However, the estimate will not be adjusted if Task 2 has a delay and Task 3 cannot meet its latest end time of 13:00.

To Define Time and Dependency Settings

In the Workflow editor, right-click the task, select Properties and open the Time & Dependencies tab.
Earliest Start Time section:

To prevent that a task is executed before a specific time, regardless of the status of previous tasks in the Workflow, assign it an earliest start time.
1. Select the Define Earliest Start Time checkbox to activate this function.
2. The real date of a Workflow is its activation date. You can define that the selected task should start either on the real date (Real Date + 0 day(s)) or a number of days after it.
3. Enter the Time. If the task is ready to start before this time, its status changes to Waiting for start time.
  
  Note: You can always start tasks manually from the Workflow Monitor, regardless of your definitions here.
4. If necessary, select a Time Zone object. You can use variables here.
Example: A Workflow is activated on May 20. It contains a task in which Real Date + 1 day(s) at 15:00 has been specified as the earliest start time. This task does not start before May 21 at 15:00.
Time Checkpoint section:

The chronological execution of a Workflow can be monitored with time checkpoints. You define them here. They are the points in time in which you want to check whether the task has started at the designated time. You specify the date and time for checking and, optionally, a different task to be executed if the original one could not start.

Note: Checkpoints become active when the Workflow is activated.
Dependencies section:

Here you define the time and status conditions that must be met so that this task can start. You can also define a different task to be executed if these conditions are not met.
- Define Latest Start/End Time
  - Latest Start time
    
    If the task is not started by this time, it is not executed at all.
  - Latest End time
    
    As soon as a task starts, its estimated duration is calculated. If the calculated end time is after the time specified in this field, it is not executed anymore.
  - Real Date + [n] day(s)
    
    Specify the date on which the task must start or end. The real date is determined when the Workflow is generated.
    
    Possible values: 0 (default) to 99
  - Time
    
    Specify the time at which the task must start or end. If the task could not be started or ended by this time, it is not executed at all.
    
    Possible values: 00:00:00 to 23:59:59
  - Time Zone
    
    Assign a Time Zone object to the task to convert the date and time accordingly.
  If the task cannot be executed, its end status is set to ENDED_TIMEOUT. If ELSE conditions are defined, they are applied.
- Execute this task if
  
  The table in the Dependencies section provides the list of predecessors of the selected task and gives an overview of their most important attributes. Use this table to define the end statuses that the predecessor tasks must have for this task to be executed:
  - all statuses match
    
    The task is executed if all predecessors end with the statuses you specify on the table.
  - at least one condition matches
    
    The task is executed if at least one predecessor ends with the status you specify on the table.
  If the predecessor is an external dependency, the Status column refers to the status of the external dependency and not to the external task. For this reason, only the following status are available:
  - ENDED_OK
  - ENDED_CANCEL
  - ENDED_ESCALATED
  Tip: You may want your tasks to have always a specific status before the next task starts. To save time when creating Workflows, you can define a default task status on the Settings dialog. This status is then set by default in this table. If you leave the default task status empty on the Settings dialog, it is also empty here.
  
  Note: You cannot add or remove tasks from the table.
- ELSE (on status mismatch or latest time failure)
  
  Specify what happens if the time and status conditions are not met.
  - Skip
    
    The task is skipped but its Postconditions are executed.
    
    The final status of the task in this case is 1930 - "ENDED_SKIPPED - Skipped because of WHEN clause."
  - Block
    
    The Workflow blocks at the predecessor task.
    
    Important! Tasks that run in parallel within the Workflow continue processing. The Workflow as a whole is not blocked until all tasks have been executed.
  - Block and send abort signal to parent
    
    The task is blocked. If there is a superordinate Workflow (parent), a signal is sent that indicates the abnormal end. If this option is set in a Workflow dependency, the parent Workflow remains blocked even after the child task has been unblocked.
  - Abort
    
    The task and the Workflow itself are canceled.
  Action: Optionally, activate this option and select a follow-up object. If the conditions are not met, this object is executed instead.