1. Implementing Onboarding (Transitions)
  2. Evaluation of Conditions on Partner Update

Evaluation of Conditions on Partner Update

When an update is received from an OVI partner, Onboarding (Transitions) reevaluates conditions automatically thereby enabling the process to proceed to the next step as quickly as possible.

In prior releases, Onboarding (Transitions) customers sometimes created processes designed to advance to a certain step and then "wait" until an OVI partner sent an update (either a status change or a value stored in a field) before continuing. Customers accomplished this by creating a "loop" using a date-based condition that reevaluated if the appropriate condition had been reached. Reevaluations were performed only once per day (unless other actions triggered reevaluations of the condition). See Date Based Condition Consequently, many hours might elapse between the moment when a partner update was received and when the reevaluation occurred.

Three situations could "wake up" such a process causing the latter to reevaluate all conditions on transitions and thereby determine if any of the transitions could be executed:

  • Completing any task in the process.

  • Stopping and resuming the process.

  • A date-based condition (on a transition) whose value changed to True (i.e. can be executed).

A fourth situation can trigger a process to reevaluate all conditions on transitions: receiving an update from an OVI partner. (The one exception where conditions will not be reevaluated is described in the following paragraph.) This enhancement renders date-based conditions on transitions unnecessary in many cases. When a process is designed to "wait" for a specific value to be provided by a partner, the process will automatically "wake up" when a partner update is received, reevaluate the condition and if the value is the one waited for, the process will proceed to the next step.

When designing such processes, administrators can use very effectively the case where a step has multiple outgoing transitions with a condition and none of those transitions has been executed. In such cases, the process will reevaluate the condition of the outgoing transitions. Likewise, if a step has multiple outgoing transitions with a condition and at least one of the transitions was executed, the process will not reevaluate any of those transitions.

Consider the following greatly simplified process including an OVI partner system task and two manual tasks.


Image showing a simplified process including an OVI partner system task and two manual tasks.

Suppose that the manual tasks can only be executed when a specific value is received from the partner. The router at the beginning of the process has three outgoing transitions:

  • To Manual Task - 2 if condition "Provider Status=Pending Employer" (condition currently "false"; transition not executed).

  • To Partner System Task (no condition; executed right away).

  • To WAIT_FOR_PROVIDER (no condition; executed right away), which in turn has a "Provider Status=Pending Employer" condition to Manual Task - 1 (condition currently "false"; transition not executed).

The process cannot advance (it "waits") because the conditions were "false" when evaluated and there are no date-based conditions that might become "true" at some point.

Whenever an update is received from the partner, the "Provider Status" is set to "Pending Employer", the process "wakes up" and reevaluates the relevant conditions as depicted in the following illustration.


Image showing a process where an update is received from the partner, the "Provider Status" is set to "Pending Employer", the process "wakes up" and reevaluates the relevant conditions as depicted in the following illustration.

The transition to Manual Task - 2 is not reevaluated. This is because Start has multiple outgoing transitions and the WAIT_FOR_PROVIDER and Partner System Task transitions were executed immediately, before Manual Task - 2. The "Provider Status=Pending Employer" condition associated with the transition to Manual Task - 1 is reevaluated because no outgoing transition associated with WAIT_FOR_PROVIDER was executed. And because the value is now true, Manual Task - 1 can be executed and the process can continue.

OVI Partner System Tasks

Customers should ensure that listening to partner statuses does not trigger parallel workflows (branches) or otherwise modify user interactions included in the OVI partner system tasks. All user interactions should be confined to the system task.

LastPreviousStepEndDate Field

(The information provided in this section is not new.)

When date-based conditions are still required in processes, administrators might use the LastPreviousStepEndDate field sometimes to force a process to wait until a certain field contains a value (that would typically be provided by an OVI partner).

Take the case of a "loop" in a process where a transition with a "LastPreviousStepEndDate is less than or equal to 1" condition, combined with a routing step that verifies if a particular value is found in a specific field. If the transition with the date-based condition is executed and the value is not yet present, the process will wait until LastPreviousStepEndDate is less than or equal to 1.

Use of the LastPreviousStepEndDate field can sometimes produce waiting periods longer than expected for a number of reasons.

  • LastPreviousStepEndDate does not represent the number of days that have elapsed since the immediately preceding task was completed; it represents the number of days that have elapsed since any other task in the process was completed.

  • If a process includes multiple branches, a task in one branch of the process, once completed, will change the LastPreviousStepEndDate value, affecting the condition in another branch that uses the field.

    • In such cases, conditions such as "LastPreviousStepEndDate is less than or equal to 1" will not necessarily become "true" when the immediately preceding task was completed one day ago if another task in the process was completed more recently (the process would have to wait an additional day before reevaluating this condition).

    • The LastPreviousStepEndDate field considers only steps of the main (root) process. A step completed in a subprocess does not affect the LastPreviousStepEndDate field. Even if used in a condition of a subprocess, the value considered is the one from the main process.

  • If the system considers a time zone when executing a date-based condition, and the candidate is the person who completed the task that triggered the condition, the time zone of the candidate's computer is the one that is used. If a Transitions backend user (typically a Recruiting Center user) completed the task, the time zone specified in the person's user preferences is used, and if no time zone is specified there, the time zone of the customer is used.

For all of the reasons mentioned previously, date-based conditions that use the LastPreviousStepEndDate field should always be combined with another condition such that whenever one of the two conditions is met, the process will advance. For example, a transition could be configured to have two conditions: "LastPreviousStepEndDate is less than or equal to 1" and the value of ProviderStatus is equal to "Pending Employer". The transition could then be configured to be complete whenever at least one of the conditions was "true". This approach is recommended to ensure that processes created prior to 15A do not "wait" unnecessarily. In 15A and later releases, these conditions will be reevaluated as soon as an update is received from the OVI partner and the process will advance to the next step.