As with SAP ERP HCM, companies using SuccessFactors Employee Central need to manage data changes, data governance, and permissions with workflows. In SuccessFactors Employee Central, workflows provide an approval and notification mechanism for events that are triggered in the system. Events may be triggered for a number of different reasons, and a workflow can be created and triggered for each Event Reason. Workflows can also be triggered by Generic Objects such as Time Off Objects, Position Objects, and customer-specific objects using rules.

Overview of Workflows in SuccessFactors Employee Central

A workflow can be triggered in one of the following scenarios for an Event:

• For effective-dated data, when a new record is inserted in history in a portlet in the Personal Information or Employment Information views
• For non-effective-dated data, when a record is edited in a portlet in the Personal Information or Employment Information views
• When an Add New Employee action is performed
• When a transaction (such as Manage Global Assignment or Change Job and Compensation Information in the Take Action menu) is performed

A workflow is triggered in one of the following scenarios for a Generic Object:

• When a rule is triggered for a Generic Object (using the OnInit or OnSave Event) that triggers a workflow
• When a rule is triggered for a field of a Generic Object (using the OnChange Event) that triggers a workflow
• When a leave request has been submitted by an employee in Time Off
• When a manager makes an adjustment to an employee time account in Manage Time Off

Figure 1 is an example of a workflow request being triggered for a change of Business Unit for an employee, Ram Varma. As you can see, there is one approver, Nancy Market. Next I discuss the different participants that can be configured in a workflow.

Examples of Workflows

There are many examples of different scenarios in which a workflow can be triggered, such as:

• New hire
• Rehire
• Transfer
• Job change
• Promotion
• Termination
• Resignation
• Leave request
• Salary increase or change
• Bonus
• Social Security Number change
• Address change
• Work permit change
• Location change
• HR administrator change

This is a fairly limited list of examples as the number of scenarios in which a workflow can be triggered is endless. As long as the requirements for triggering a workflow can be defined and do not conflict with other requirements (for example, using the same fields with similar conditions or a similar set of fields in two or more workflows), then there is no limit to the number of workflows that can be implemented. Quite often workflows involve a manager or HR representative, but in some instances, they may require other participants. This may influence the number of workflows that are created in the system.

Creating New Workflows

Here I show a method for creating a new workflow. Many elements of this method also can be applied to modify an existing workflow. To create a workflow, follow these three required steps:

1. Create Dynamic Groups: Create any Dynamic Groups or Dynamic Roles to be used in the workflow
2. Create a workflow configuration
3. Assign the workflow

Step 1. Create Dynamic Groups

A Dynamic Group – also known as a Workflow Group – is a pool of approvers in which any individual can approve the workflow. They are created in OneAdmin in Employee Files > Manage Workflow Groups. Figure 2 shows the screen in which Dynamic Groups are managed. Here Dynamic Groups can be viewed, created, edited, or deleted. The process for creating a Dynamic Group is the same as when creating a Permission Group. To create a new Dynamic Group, click the plus sign icon next to Create New Group (Figure 2). The clone group icon can be used to copy an existing group (this icon is shown to the left of the trash icon in Figure 2). Clicking the Create New Group button opens the Group Definition screen (Figure 3). Enter a name for the Dynamic Group and select the required criteria. For example, all employees in the San Francisco Location or all employees in the Corporate Industries Business Unit. When you’ve completed your selections, click the Done button.

Create Dynamic Roles

A Dynamic Role is a group of individuals or Dynamic Groups in which the approver is determined by the system based on one or more fields from the employee’s data or from the Event Reason. Dynamic Roles are Foundation Objects. Dynamic Roles allow either a Person, Dynamic Group, or Position to be assigned a workflow based on certain criteria. The standard criteria are listed below, but any Foundation Object can be added in the corporate data model XML:

• Job Classification
• Department
• Location
• Legal Entity
• Business Unit
• Cost Center
• Pay Grade
• Pay Group
• Division
• Event Reason

For example, a number of Departments can be defined with a specific person defined for each Department. When being created, a Dynamic Role requires an ID to be entered, and also (optionally) a name and description. The criteria must then be defined. In this example, I define the criteria listed in Table 1. This means that if, for example, the Location of the employee is Philadelphia, PA, and the Business Unit of the employee is Corporate Industries, then the workflow routes to Marcus Hoff. Dynamic Roles are created in OneAdmin in Employee Files > Manage Organization, Pay and Job Structures. Figures 4 and 5 (different views of the same screen) show the Dynamic Role being configured with the criteria from Table 1. Once the configuration is complete click the Save button to save the new Dynamic Role object.

Step 2. Create a Workflow Configuration

In my example I create a workflow for a change of Department. You have already created some new Dynamic Roles and Dynamic Groups. The next step is to create the new workflow and assign it to an Event using Event Derivation. A Workflow configuration is a Foundation Object and is configured in OneAdmin in Employee Files > Manage Organization, Pay and Job Structures. A Workflow configuration requires an ID, with an optional name and description. For my Workflow configuration I use these values:

• Workflow ID: WF_Department_Change
• Name: Change of Department
• Description: Change of Department process

The main part of configuring a workflow revolves around configuring each type of participant that is required. There are three types of participants:

• Approvers
• Workflow Contributors
• CC roles

These participant roles are discussed in more detail below. Figure 6 shows the workflow configuration of the Position Transfer workflow with different participants. For each type of participant there can be multiple participants. Below is a description of each type of participant as I explain how to configure your workflow.

Approvers

An approver must approve a workflow request, and all approvers of a workflow must provide approval for it to be approved and the data changes to be active. There can be multiple approvers, each of which is added in a step. The approver in each step must approve the request before it can move to the next step. Depending on the configuration, an approver may also be able to change data as part of the workflow request. There are different types of approvers available in the system and three additional fields to configure for each approver. The Approver Type field (Figure 6) determines the type of approver, which is either a Role, a Dynamic Role, or a Dynamic Group. The following values are available for the Role field:

• Employee: The employee who is the subject of the workflow
• Employee Manager: The employee’s manager
• Employee Manager Manager: The manager of the employee’s manager
• Employee HR: The employee’s HR representative
• Matrix Manager: The employee’s Matrix Manager
• Custom Manager: The employee’s Custom Manager
• Second Manager: The employee’s Second Manager
• Additional Manager: The employee’s Additional Manager

This list of values is also used for the Role field for the participants of both the Workflow Contributor Type and the CC Role Type. For each approver, there are additional fields that can be configured:

• Approver Role: Here a Role, Dynamic Role, or Dynamic Group is selected depending on the approver type that was chosen.
• Edit Transaction: Defines whether or not the approver can edit the data of the workflow and whether the approver can edit the data with a rerouting of the workflow through each step.
• Context: Defines whether the Approver Role is from the employee’s current job (Source) or their new job (Target).

For this Workflow, you configure the values listed in Table 2. These values define that the employee’s current manager, the future manager, and the future HR representative all will be approvers. These types of approvers are usually used in a transfer so that both the existing and new responsible approvers can approve the workflow. The employee’s current manager is the first approver and must approve the workflow before the employee’s future manager can approve it, and so on. Neither manager can edit the workflow, but the HR representative can edit the workflow without it being rerouted to all the approvers. The system configuration is shown in Figure 7. Next I show you how to add some workflow contributors to your workflow.

Workflow Contributors

The Workflow Contributor participant can add comments to a workflow, but doesn’t have any other role or permissible actions. This is used, for example, when a responsible participant (e.g., a manager, HR representative, or executive) needs to be notified of workflow and who may wish to provide feedback for other participants to review. The workflow contributor has four contributor type values, three of which are the same as for the approver type (Role, Dynamic Role, and Dynamic Group). The fourth type is the person type, a specific user in the system. The format for configuring a Workflow Contributor is the same as an Approver, although there is no Edit Transaction field. Unlike the Approver, because a Workflow Contributor does not approve anything, there is no step concept. All the Workflow Contributors can perform this role at any time. For this workflow I assign two Workflow Contributors (Table 3). These values are configured in the bottom of the screen in Figure 7, shown in Figure 8. Now that the new Workflow Contributor roles are configured, you can add any individuals to be notified.

CC Roles

CC Role participants, as the name suggests, simply receive a notification of the workflow once it is approved. This may be a payroll manager in cases in which a salary change has been made by a manager and approved by an HR administrator. Again, like the Approver and Workflow Contributor, there are different types of CC Roles. The CC Role Type features all four types used for Contributor Type, but also has a value called External Email. This field allows an email address to be entered, and an email is then sent to that email address once the workflow is approved. For this workflow I add the Dynamic Group called Group HR and our generic HR email address notifications.hr@acecompany.com (Figure 9). After you add all your roles in the CC Role section of the screen, it should look like the one shown in Figure 10. Click the save icon at the bottom of the screen (not shown) to save the workflow. The Workflow configuration is complete. Now it’s time to assign it so that it can be triggered.

Step 3. Assign the Workflow

In this step you want to assign the workflow to the Department field using Event Derivation. Please note that this step requires access to both Provisioning and knowledge of XML configuration, so only an experienced SuccessFactors systems integrator consultant should perform this part of the workflow exercise. The first step is to create an Event Reason. Because an Event Reason is a Foundation Object, it is created in OneAdmin in the same place as a Workflow configuration: Manage Organization, Pay and Job Structures. An Event Reason has six fields:

• Event ID: The ID of the Event Reason
• Event Name: The name of the Event Reason
• Description: A description for the Event Reason
• Status: The status of the object (Active or Inactive)
• Event: The event to which this Event Reason is linked
• Employee Status: The status of the employee once the event has taken place

For your Event Reason enter the following details:

• Event ID: ER_Department_Change
• Event Name: Change of Department
• Description: Change of Department
• Status: Active
• Event: Transfer
• Employee Status: Active

Once configured and saved, your new Event Reason object screen should look like the example shown in Figure 11. After you create your new Event Reason, you need to save it and then assign it in the Rules for Event Reason Derivation XML. This file defines the rules for triggering an Event Reason in SuccessFactors.

Save the New Event Reason

First, download the Rules for Event Reason Derivation XML from Provisioning and make a backup. Open this file and insert into it the code shown in Figure 12. This cut-and-pastable version of the code should be inserted above all the other rules that contain the Department so that your new workflow will trigger. (Click here for a downloadable version of the code: Rules for Event Reason Derivation XML.) The rule ID should be a unique name, so if the ID in the example above already exists, change it to a unique name. In the example you can see that your Event Reason ID is placed between the <trueoutput> tags, and the Event Reason is set to trigger if the Department field in the jobInfo portlet is changed. Next, save your file and upload it in Provisioning. After uploading the file, you need to download the Rules for Workflow Derivation XML. This file defines which data changes trigger the specific workflow and, therefore, the Event Reason that you just defined. Once you make a backup, open the file and insert the code shown in Figure 13 above all the other rules that contain the Department so that your new workflow will trigger. (Click here for a downloadable version of the code: Rules for Workflow Derivation XML.) As with the rule in the Rules for Event Reason Derivation XML, the rule ID needs to be a unique name. In the example you can see that your workflow ID is placed between the <trueoutput> tags and the workflow will trigger if the Event Reason rules are met in the JobInfo portlet. The Event Reason is defined in the value attribute of the <equal> tag. Save your file and upload it in Provisioning.

Test the New Workflow

After you uploaded the file to Provisioning, it’s time to test your new workflow. Go to the Change Job and Compensation Info transaction for Carla Grant and change her Department (Figure 14). Select the Change Job and Compensation Info radio button and the Job Information check box, and enter the required date for when you want the changes to take effect (12/09/2013 in this example). In the Job Information section, make your required change to the Department field. After you make your changes, click the Save button, which displays the workflow pop-up confirmation window (Figure 15). Select the Show Workflow Participants option, which allows you to see all of the participants of the workflow. (Conversely, the participants can be hidden by selecting the Hide Workflow Participants option that appears in the same place as the Show Workflow Participants option.) In some instances you may notice that not all of the employees in each Role appear in the list of workflow participants. This is because sometimes there is no employee in that Role for the employee who is the subject of the workflow or because that specific change does not call a target role. Now I discuss the notifications and workflow approval requests process.

Notifications and Workflow Approval Requests

Workflow participants can be notified of workflows in three ways, depending on which methods are configured in the system:

• By email (with a link to access the pending workflow)
• In the Pending Requests view in Employee Files
• In the To-Do Tile of the Home page

In Figure 16, you can see a number of pending workflows and notifications for the user (Alexander Thompson) in the Pending Requests view in Employee Files, including the workflow request that you just triggered for Carla Grant (listed in the Requests Waiting for My Approval portlet). To view the workflow request, double-click the desired workflow request (in this example, Change of Department for Carla Grant – effective 12/09/2013). This opens the screen for that specific workflow request (Figure 17). The workflow request shows the following details:

• Event Reason (e.g., the change of Department for Carla Grant in Figure 17)
• Employee (e.g., Carla Grant)
• Workflow creator (e.g., Luke Marson)
• Data change(s) (e.g., the Organization Information in Figure 17)
• Comment box
• Options for the next step (e.g., Send Back or Yes, I Approve buttons)
• Post workflow creator comments (Post Comments button)

The Comments box and the three buttons at the bottom (Send Back, Post Comments, or Yes, I Approve) are only visible to Approvers. Other participants do not see these buttons as they are only being notified of the workflow. If the participant is an Approver then, depending on the configuration of the workflow, they may be able to edit data included in the workflow or data about the employee as part of the workflow prior to approving it. For example, a manager may be launching a Job Reclassification Event and cannot edit the Pay Grade. HR administrators – as Approvers – can edit this data during the approval of the workflow before they send it to the next Approver. Again, depending on the workflow configuration, this workflow may be routed back to the first Approver or it may be routed to the next Approver if the data is changed. If the participant is an Approver, then he or she can either approve, deny, or send back the workflow. The Send Back button (Figure 17) sends the workflow back to the creator so that further action can be taken, such as making additional data changes.

Administering Existing Workflows

HR administrators have a number of options available to administer and manage workflows in OneAdmin. These include:

• Review workflows
• Lock or unlock pending workflows
• Add to, change, or remove Approvers from a pending workflow
• Reroute a pending workflow
• Decline a pending workflow
• Modify workflow email templates
• Enable or disable workflow emails

Workflows are administered in OneAdmin in Employee Files > Manage Workflow Requests, except for the email notification templates and enabling or disabling emails, both of which are administered in Company Settings > Email Notification Template Settings. In Figure 18 you can see all the workflows with a Pending status in the Manage Workflow Requests portlet. An HR administrator can double-click the workflow request in the Request Type column to view the workflow or double-click the Take Action option in the Actions column to initiate one of the actions listed above.