Configuring workflows during implementation

Workflows are typically configured as part of the self-service process. When an employee or manager submits a change, a workflow is activated. Workflows are generally built in the implementation process. The role of the administrator is to ensure the completion of workflows and to manage the workflow participants.

In the figure, Workflow Approval Steps, you can see a sample workflow with two approvers after the manager initiates the change, the second-level manager and an HR Dynamic Group. The HR Dynamic Group is a pool of people where only one person needs to approve the workflow.

Workflow Configuration

Workflow is an XML-based Foundation Object. It is a Foundation Object generally categorized as Others, and just like any other XML-based Foundation Object, workflow records are managed in Manage Organization, Pay and Job Structures tool.

In the figure, Workflow Configuration, you can see the workflow record for an Address Change. There is one approver, the Dynamic Group Talent Approval, and two external e-mail addresses that will be cc’d when the process is finalized.

Types of Workflow Participants

By default, there are three types of workflow participants:

• Approvers: An approver actively participates in the workflow. An approver is required to move the request along by either approving or denying (which sends the request back) the request. Approvers can also post comments to the workflow.
• Contributors: A contributor is a type of participant that can only add comments to the workflow. They do not actively approve nor deny the request. Contributors also get notified of any progress.
• CC Role: This is a passive participant. CC Roles get notified upon the completion of the request.

A dynamic role is a flexible way to assign users and groups as workflow approvers based on the job information of the subject user.

For example, you can create a dynamic role identifying Janet James as the approver for transactions using promotion as the event reason for employees in Corporate Industries. If Carla Grant promotes Marcus within the Corporate Industries group and the promotion event reason is used, the system routes the approval to Janet James.

Use Manage Organization, Pay and Job Structures in Admin Center to create Dynamic Role records.

When a dynamic group is used on a workflow, the request is sent to all group members. However, only one of the members is expected to take action.

The groups are created using the same interface as RBP. Dynamic groups are managed using the Manage Workflow Groups tool.

Note

You can enable the Enforce Four-Eyes Principle On Workflow Step Approval in Platform Feature Settings that enforces a security mechanism so that the initiator cannot be an approver for the workflows. This applies to Dynamic Groups and Dynamic Roles.

Workflow Notification

Standard workflow e-mail templates can be found in E-Mail Notification Template Settings. Though the standard templates can be modified, you cannot customize the notification for each workflow participant. You'll have to use Document Generation to create a fully customized template where each participant receives a custom notification.

Workflow e-mail templates use tags, as shown in the figure, Workflow Notification. See the Workflow Implementation guide for a full list of the supported tags.

Standard workflow e-mail templates are selected by default and cannot be disabled. They are available for the following workflow actions:

• Approval

• Rejected

• Pending

• Canceled

• Skipped

• Posted

• Lock Down

• Unlock

• Contributor

• CC Role

• Approved

• Sent back

The system provides a sophisticated logic to skip the same single approvers in consecutive steps of the workflow to ensure improved processing efficiency without compromising data quality and legal compliance.

All the successive workflow steps with the same single approver, except the last one, will be skipped automatically. The skipped steps are displayed on the Workflow Details page. All skipped steps are indicated in the Activity area of the page.

By taking steps out of long approval chains, the skip option improves the efficiency of processing workflows without affecting data quality. An example is demonstrated in the following table.

The option to skip approvers is enabled in Company System and Logo Settings.

When employees participate in a workflow, they can view the progress using the Manage Pending Requests tool. You can access this page by Action Search → Manage Pending Requests.

Use the interaction below to become familiar with the tool.

Note

You can have additional filtering options in the My Workflow Request tool when you enable the permission, Manage Workflows → Professional Edition Manage Workflow Requests, in Role-Based Permissions.

The Assign to me workflow feature allows a user that belongs to a dynamic group to take ownership of the request and assign the workflow to themselves. It allows a user to find out who assigned the workflow as well as remove the assignment from themselves or other members of the dynamic group.

How to Use the Assign to Me Function?

Before you use the assign to me function, a user must have the Manage Workflow Assignments permission assigned to them. When the permission is set up, a user can review the pending requests. As a user in a dynamic group (workflow group), a user can look at any workflow assigned to that dynamic group and assign it to themselves.

A user can also filter the workflow requests in My Workflow Requests based upon the assignment.

With delegation, you can enable an option allowing an approver to forward the workflow to another user in the company. The recipient can then take over the workflow to approve or decline on behalf of the initial approver. The recipient also has the option to refuse the delegation. The initial approver can also recall the workflow.

There are two options on how to delegate workflows:

• Manual delegation: done individually by the employee per workflow
• Auto delegation: if switched on, all workflows are delegated

Delegation is configured in the Corporate Data Model. The Workflow Configuration foundation object has a field called is-delegate-supported. When Corporate Data is configured with the is-delegate-supported hris-field under the wfConfig hris-element, the system allows the admin user to configure a workflow record with Yes and No options. By default, the field value is No.

Corporate Data Model: hris-field under <hris-element id="wfConfig">

 
<hris-field id="is-delegate-supported" visibility="both" required="false">
   <label>Is Delegate Supported</label>
</hris-field>

For both manual and auto delegation, it is necessary that delegation is supported at the workflow record, meaning Is Delegate Supported is set to Yes.

A user can set up an auto delegate through quick actions on the latest homepage. To enable auto delegation, the user needs to have the RBP permission, Allow Auto-Delegation. When auto delegation is enabled, all workflows with auto delegation enabled are routed to the nominated user. When a user assigns a delegate, they can specify the start and end times for the auto-delegation. If they leave those fields blank, the auto-delegation is indefinite until manually turned off. This includes workflows received through job relationships, dynamic roles, dynamic groups, and positions. If you enable the Allow Delegates to accept or reject a workflow delegation request option, the delegate has the option to approve or reject the delegated workflow request. A delegate can also view their delegations and delegation periods under the Delegation Requests for Me tab.

You can use an alternate workflow to include more approvers in a workflow process and take care of potential conflicts caused by future-dated records.

In the figure, Alternate Workflow, an address change would normally go to the Dynamic group, Talent Approval. However, if a future-dated record is identified, the system will instead trigger the alternate workflow, Data Change.

For example, Marcus Hoff has a future-dated address record effective December 15, 2099. Today, a request to change the zip code was submitted.

In the figure, Request Submission, you can see how the approval steps differ using the alternate workflow, Data Change, because of the future-dated record.

Note

A business rule could be used instead of alternate workflows.

You can specify that the current workflow approver is reminded to take action on a pending workflow after a certain number of days. You can configure the notification in two ways:

• Set up the same number of days in all workflows.

• Set up the individual number of days for different workflow records.

To configure reminders, you create a job in provisioning with the job type Workflow Action Reminder. You can set the Remind in Days value to the number of days for all workflows or leave the value blank to specify the days for each workflow configuration record.

If you are configuring the individual workflow configuration records, you must update the Corporate Data Model to include the remind-indays hris-field in the wfconfig hris-element as follows:

<hris-field id="remind-indays" visibility="both">
<label>Remind in Days</label>
</hris-field>

When the scheduled job runs, the system gets all the pending workflows. The number of days is determined based upon either:

• The number of days entered in the scheduled job in Provisioning.
• The number of days the Admin has entered for each workflow foundation object record if the number of days is empty in the scheduled job.

If the workflow has been pending for that number of days, the reminder notifications are sent to the current approver.

The reminder notification reuses the approver's original notification when a workflow is triggered, with "Reminder:" in the e-mail subject line. There is no need to configure a specific e-mail template for reminder notifications.

Note

If you configure a number of days in the notification job, values entered on Workflow Configuration Records are ignored.

It is possible to define an escalation path for a workflow. If an approver takes no action on the workflow, the workflow becomes stalled. With auto escalation, the workflow is automatically escalated to a specified user if the workflow is stalled for a specified number of days. The new approver can decline the escalation, returning to the previous approver. The previous approver can also revoke the escalation, thus bringing it back to themselves. After declining or revoking, the escalation would continue with the next escalation step after the defined number of days.

An escalation path must be created within the Manage Data tool, then attached to the workflow configuration record.

Configuration of Workflow Escalation

Steps to configure the escalation:

1. You must first add the escalation to the Foundation Object in the Corporate Data Model. Include this xml tag in the corporate data model under <hris-element="wfConfig"> :
   Code snippet

   Copy code

   
   <hris-field id="escalation" visibility="both" required="false" pii="false">
     <label>Escalation</label>
   </hris-field>

   Copy code
2. Create the escalation path in Manage Data.
3. Assign the required workflows to the escalation records.
4. Create a job in provisioning to run the Workflow Auto Escalation Job Type.

Caution

Escalation will not happen if you have enabled the auto-approval feature.