Step

A step is the "envelope" in which a task gets assigned to participants.

A process contains steps. Steps are created for each process and they are the "container" for tasks (a task can be reused in the same process or across different processes). A step provides information about the assignee and sequence of tasks. Business logic ensures that the work to be done is routed correctly between steps.

Type of Step

When creating a step, the Onboarding (Transitions) administrator needs to select a type of step.

Step Type Description
Task The step will consist of a task selected from a defined list of tasks which are available in the Tasks library in the Onboarding (Transitions) Administration.
Sub-process The step will consist of a sub-process. A sub-process is a small process used inside a larger process. For example, if you always reuse the same sequence for internal requests such as computer, office space, phone and business card requests, but have some variability for the welcome messages and paperwork for the new hire, you could create a sub-process and reuse it in various processes to simplify management. Like regular processes, a sub-process cannot be substantively changed after being enabled. However, when a sub-process gets incorporated into a larger "parent" process, then any later adjustments to the definition of the "child" sub-process do not have an effect on this larger "parent" process.
Routing The step brings together multiple parallel tasks. Routing steps are like placeholder steps that do not contain any tasks to assign to any users. They are used to facilitate the workflow design for steps that split into parallel branches and then need to be brought together. Standard tasks can also be used to handle branching and reconnecting, if their transitions are built to do so.

Step Execution

For each step defined in a process, the Onboarding (Transitions) administrator must specify the Execute Step and the After Step Execution properties.

The Execute Step is used to indicate if:

  • The step will wait for all previous steps before becoming active.

  • The step will wait for one of the step before becoming active.

The After Step Execution is used to indicate if the step will execute:

  • All subsequent steps.

  • One subsequent step.

Duration

When configuring a step, the Duration field is used for calculating the due date of each task for its assignee(s). At the moment the task gets assigned, its due date is determined to be a certain number of days in the future, depending on the task's expected duration. This due date only takes into account the working days and not the weekends that are configured in the zone. Also, the duration of a task contributes to calculating percentage complete of the overall process. The duration acts as a weighting factor because tasks which take longer are considered to be worth a larger percentage of the total work needed to complete the process. For example, a person's Onboarding (Transitions) process might have 9 out of 10 tasks complete. If every task including that one remaining task was configured to have a duration of 1 day, the process would be at 90% completion, with only one small task left to go. However, if that one remaining task had a duration of 10 days, the process would be more like at 50% completion, because 9 days’ worth of work have been completed but another 10 days’ worth of work still remains to go.

Specific versus Fallback Assignees

In Onboarding (Transitions), the work in a step's task can be assigned to one or more person.

  • If one person is assigned, then this person must complete the task. If the person fails to do so (even after configurable reminders are emailed to him/her) then the process owner and/or supervisor may be able to execute the task themselves and/or reassign the task to another user(s).

  • If more than one person is assigned, then just one of these person must complete the task. It appears on each person's open task list. As soon as any one person completes it, then it disappears from all open task lists and becomes visible only in the Completed lists.

There are several ways that more than one person can become assigned to a step:

  • The Onboarding (Transitions) administrator explicitly selects two or more individual users of the system.

  • The Onboarding (Transitions) administrator explicitly selects one or more individual users and/or one or more roles defined in the system, either Oracle Taleo Enterprise Edition-defined system roles or user-defined functional roles. Please note that a system role can be a Hiring Manager, a Hiring Manager Assistant, a Recruiter, a Recruiter Assistant. If no user is found in the context for that role, the system falls back on the Recruiter role. If there is no Recruiter, the system then falls back to the Process Owner. In some rare cases, the Process Owner can also be empty for instance if the Process Owner is also defined to be a System Role which happens to be empty for a candidate/new hire. This situation should be avoided, because the Onboarding (Transitions) process will be unable to start for this person. The action in the Recruiting Center will appear to proceed smoothly, but the candidate/new hire will not appear on the Onboarding (Transitions) Center's list of In Progress processes.

Form Snapshots in Steps that Contain a Fill User-Defined Form Task

Form snapshots secure the contents from important forms filled out by New Hires as they go through an Onboarding process. Enabling this feature allows Administrators the ability to create a “snapshot” in time of a form that can be viewed, printed, or exported and that will remain unaffected by future changes in the data.

Onboarding steps consisting of a “fill user-defined form” task can be configured such that submitting the corresponding form will also collect a snapshot of that form. All the snapshots will be tracked within the Onboarding process itself and will be available in the New Hire’s Onboarding process details. Snapshots are generated when New Hires click Submit. Snapshots will be saved in the language in which the form data was originally entered. All snapshots can be exported using TCC.

When the Save a Point-in-time snapshot of the form and contents at time of completion setting is enabled, snapshots are created in HTML and contain all the instructions, field labels and data. However, branding, images and other styling is not captured. While images are not captured, information relating to images such as their approximate location in the file, size and name can be included in the Snapshot. The Onboarding Administrator must manually set the width and height in order for the image size to be depicted correctly on the snapshot, otherwise, when you add an image to the user-defined form, the normalized square depicted on the snapshot will take up the default size. The Snapshot is supplemented with all the relevant information regarding the form and corresponding process, including:
  • Candidate Name and ID

  • Requisition Name and ID

  • Process Name and Code

  • Step, Task, Form Name and Code

  • Submitted by, Date and Language

When we add an image to the user-defined form and if the width & space is not set manually, the “normalized” square depicted on the snapshot will take up the default size. Hence, the OB Admin must manually set the width and height in order for the image size to be depicted correctly on the snapshot