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

  1. In the Workflow editor, right-click the task, select Properties and open the Time & Dependencies tab.
  2. 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.

  3. 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.

  4. 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. Not all attributes are displayed, though. If necessary, click the arrow at the right end of the table caption to show additional columns. This screenshot illustrates it:

      (Click to expand)

      The value entered in the Status column determines the status that the predecessor task must have for the task to be executed. By default, the Status is empty.

      • 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.

      Tip: You can change the status here, or you can define a Client-wide default status for all tasks in Workflows. You do this in your user settings; 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.

      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

      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.

        If you have previously selected at least one condition matches and none of the conditions is satisfied, the successor task (not the predecessor!) will block the Workflow. The reason is that there is no specific task that is responsible for the mismatch.

        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.

See also: