SF Training Library Volume 1 10 US Special Forces Manuals dating from the 1960s through to current. This is Volume 1 of 4. Check our other documents for the rest.
Descripción: install guide for app director
trDescripción completa
Deskripsi lengkap
PROFORMA DE BOMBA INDUSTRIALDescripción completa
pregatirea inaintea impartasirii cu Sfintele Taine ale lui Hristos
Full description
INSTAGRAMFull description
Q2 ProtocolFull description
ana
Q2 ProtocolFull description
Descripción: Proceso Administrativo Q2
Do itFull description
Full description
sFull description
respuestas
Implementation Guide
CUSTOMER
SAP SuccessFactors Employee Central Document Version: Q2 2017 – 2017-06-02
Implementing and Configuring Workflows in Employee Central
Setting Up Workflow E-mail Notifications [page 33]
Changes to this Guide in Q3 2016 Table 4: What's New
Description
More Information
August 24 New user guide for workflows
Topics removed from the Employee Cen tral Master Guide
Implementing and Configuring Workflows in Employee Central What's New
CUSTOMER
5
2
Workflows Overview
You can define workflows to set up approval processes for changes that any user makes to an employee’s data or to any other object. In order to automate business processes and ensure high data quality you can implement workflows. Let's say you have set up a workflow for changes to the national ID of an employee. If the user changes this national ID, a popup shows indicating who has to approve this change. If the user confirms the change, the approver gets an approval request in the To-Do List and in the Pending request page (Pending request portlet). The system does not process the change until the approver approves the request. The Admin defines which changes to an employee’s data trigger an approval workflow, and who needs to approve the change. For example, if the employee creates a leave request, the manager has to approve it. Or if the manager promotes an employee, the Admin can define that the manager's manager and the employee's HR responsible are automatically notified by email about this promotion and make their approval required. Only if both have approved this change, the change is processed by the system. This guide is valid for Employee Central customers using HRIS-and MDF-based workflows. Concerning MDF objects, if Pending Data is set to No, then changes will be applied before approval but if the user rejects the data, then it will be rolled back. In order to set up a workflow, you need to complete the following: ● Define a workflow For more information, see Defining Workflows [page 13]. ● Define a rule that triggers a workflow
Note For new customers, we recommended that you use the Business Rules Framework. For more information, see Triggering Workflows [page 25]. ● Assign the rule to the object For more information, see Triggering Workflows [page 25]. ● Set up workflow email notifications For more information, see Setting Up Workflow E-mail Notifications [page 33].
2.1
MDF Workflows for Customers Not Using Employee Central
MDF workflows use the Employee Central workflow framework and therefore Employee Central workflow features can used for customer not using Employee Central. All features described in this guide are available for MDF workflows for customers without Employee Central as well – with minor exceptions.
6
CUSTOMER
Implementing and Configuring Workflows in Employee Central Workflows Overview
Please find further information about what you need to do to use MDF workflows if you are an non-Employee Central customer in the Implementing the Metadata Framework guide.
Implementing and Configuring Workflows in Employee Central Workflows Overview
CUSTOMER
7
3
Prerequisites - Data Model Enhancements
Before you can use workflows in Employee Central, the following changes must be applied to the different data models listed below.
Remember As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact SAP Cloud Support.
Corporate Data Model Make sure the foundation object for workflow has been created as well as the following HRIS elements for approval steps:
Succession Data Model In the Succession Data Model, add the workflow-related HRIS elements that you are going to refer to in your workflow rules. Make sure the pending approvals tab has been created:
8
CUSTOMER
Implementing and Configuring Workflows in Employee Central Prerequisites - Data Model Enhancements
4
Prerequisites - Provisioning Settings for Managing Workflow Requests
Before you can use manage workflows in the new Home Page in Employee Central, you need to ensure that a few things are turned on in Provisioning.
Remember As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact SAP Cloud Support. The following must be turned on in Provisioning: ● Homepage V3 ● Intelligent Services
Implementing and Configuring Workflows in Employee Central Prerequisites - Provisioning Settings for Managing Workflow Requests
CUSTOMER
9
5
Permission Settings
5.1
Manager Permissions
To ensure that managers see requests from their employees, make sure that their permissions are correct. 1. Go to Admin Center. 2. In the Tools Search field, type Manage Permission Roles . 3. On the Permission Role List page, under Permission Role, click the permission role for which you want to manage the permissions. The Permission Role Detail page opens. 4. In the Permission settings section, click the Permission... button to specify the permission you want to assign to the role. The Permission Settings window opens. 5. Under User Permissions, click Employee Views. 6. Ensure that Pending Requests is selected. 7. Under User Permissions, click Manage Users. 8. Ensure that Allow Auto Delegation is selected. This is so that workflows will be automatically forwarded, for example, while a manager is on leave. 9. Under User Permissions, click Employee Data. 10. Select View Workflow Approval History. Choose the View and/or Edit permissions as required.
Note View: Show that there is an pending approval, but do not allow the user to click on the approval details Edit: Allow access to the approval details 11. Click Done and save your changes.
5.2
HR Admin Permissions
To ensure that HR admins have access to what they need, make sure that their permissions are correct. 1. Go to Admin Center. 2. In the Tools search field, type Manage Permission Roles . 3. On the Permission Role List page, under Permission Role, click the permission role for which you want to manage the permissions. The Permission Role Detail page opens. 4. In the Permission settings section, click the Permission... button to specify the permission you want to assign to the role. The Permission Settings window opens. 5. Under User Permissions, click Manage User. 6. Select the following: ○ Manage Workflow Requests You need Manage Workflow Requests to grant access to this transaction. Please specify the target population accordingly.
10
CUSTOMER
Implementing and Configuring Workflows in Employee Central Permission Settings
○ Manage Workflow Groups You need Manage Workflow Groups to be able to define dynamic groups. 7. Under User Permissions, click Manage Foundation Objects Types. ○ Select the permissions for Dynamic Role to enable the HR admin to maintain the dynamic role settings ○ Select the permissions for Workflow to enable the HR admin to create and maintain workflow definition
8. Click Done and save your changes.
Permissions for Managing Workflow Requests Professional Edition 1. Go to Admin Center. 2. In the Tools search field, type Manage Permission Roles . 3. On the Permission Role List page, under Permission Role, click the permission role for which you want to manage the permissions. The Permission Role Detail page opens. 4. In the Permission settings section, click the Permission... button to specify the permission you want to assign to the role. The Permission Settings window opens. 5. Under User Permissions, click General User Permission. 6. Select Professional Edition Manage Workflow Requests.
Implementing and Configuring Workflows in Employee Central Permission Settings
CUSTOMER
11
7. Click Done and then Save Changes.
12
CUSTOMER
Implementing and Configuring Workflows in Employee Central Permission Settings
6
Defining Workflows
Now that you have enhanced the data models to support workflows, you can setup workflow objects in the system. You can use these methods to define the workflows your company wants to use. You can create the workflow foundation objects in the system one by one, or in batch mode by uploading workflows using a CSV file. ● To create single workflows, use the Manage Organization, Pay and Job Structures option in the Admin Center. ● To mass upload workflow data using a CSV file, use the Import Foundation Data option in the Admin Center.
There are four main sections that define your workflow object: header, approval steps, contributors and CC-roles. ● Header: Here, you can define generic information, for example, whether delegation is allowed or whether workflows should be escalated. ● Steps: Here, you define any number of steps required in the approval process. Once the last step is approved, the workflow as a whole is approved and the workflow transaction will be released. You can also define a workflow with no approval steps but with a CC notification step, which means that the workflow will be approved immediately, but the respective CC role will be notified about the change. ● Contributors: In this section, you can define employees who do not act as approvers, but should still follow the workflow as it is executed. Contributors are notified about changes, and can provide comments. In addition to the generic options, you can define a specific person who should contribute.
Implementing and Configuring Workflows in Employee Central Defining Workflows
CUSTOMER
13
● CC-Role: Employees who are listed in CC-roles are informed whenever a workflow is completed. In addition to the generic routing options, you can define a specific person or an email address to be informed.
Header Fields The following table explains the fields in the header.
Note If a field is not visible, it can be added to the Corporate Data Model within wf-config hris element. Once it is added, it will show up on the Workflow Foundation Obbject UI. For example: Is Delegate Supported:
Source Code Remind in Days
Source Code Future Dated Alternate Workflow corresponds to “alt-wf-config-code” hris-field. Table 5: Field
Description
Workflow ID
Specify an ID
Is Delegate Supported
This must be set to YES for the workflow to be either manually delegated or is automatically forwarded, in case auto-delega tion is activated.
Escalation
If you want to have the workflow escalated automatically, if it is stalled/stuck, you can define an escalation object and as sign it here.
Name
You can specify a name for the workflow in the various lan guages.
14
CUSTOMER
Implementing and Configuring Workflows in Employee Central Defining Workflows
Field
Description
Remind in Days
You can set up individual number of days for different work flow foundation objects. For example, you might want to have a more frequent re minder for promotion-related workflows than for job relation ship changes.
Description
You can add additional information on the workflow.
CC Link to approval page
This setting is only relevant for CC users. If Yes is selected, the CC-Role will be redirected to the work flow approval page, so that they can also access the workflow content (using the option Redirect CC Users To Workflow Approval Page). If No is selected, they access the workflow object itself. Exception for workflows without any approval steps: Since we do not have an approval page, user will always access the workflow object itself. In EC v12 systems, this will redirect to Public Profile page. In PP3-enabled systems, it will redirect to the People Profile.
Future Dated Alternate Workflow
When at least one future dated record exists, use this field to trigger the workflow. In order to improve the handling of situations where at least one future dated record for the data record in the workflow content exists, it is possible to trigger an alternate workflow in stead of the original workflow. This workflow can then include additional approvers, preferably on HR side, who can take care of potential conflicts, arising from the future dated record.
Example Here is an example for future-dated alternate workflows: A change to an employee's Job Information triggers workflow 1. In workflow 1, you can set Future Dated Alternate Workflow to workflow 2. The user has 2 Job Information records: ● 9/1 to 10/31 ● 11/1 to current If the manger wants to insert a new record effective on 10/6, the system checks that the user has 1 future record (compared with 10/6) and then uses workflow 2 to trigger the workflow. If the manger wants to insert a new record effective on 11/10, the system checks that the user has 0 future records (compared with 11/10) and then uses workflow 1 to trigger the workflow.
Implementing and Configuring Workflows in Employee Central Defining Workflows
CUSTOMER
15
Steps Fields You can specify for each approval step, contributor or notification (CC Role): Table 6: Field
Description
Approver Type
Choose: Role, Dynamic Role, Dynamic Group, Position or Posi tion Relationship For more information, see Routing Workflows [page 19].
Approver Role
Choose the role, for example, manager or HR Admin.
Edit Transaction
You can control how approvers are allowed to do changes to the content of the workflow transaction. For information, see In-Flight Changes [page 47] ●
No Edit: Approver does not have inflight edit capability.
●
Edit with Route Change: The workflow route is recalcu lated when the approver makes changes and submits the request.
●
Edit without Route Change: The workflow route is not re calculated when the approver makes changes and sub mits the request.
●
Edit Attachments Only: Approver has capability for edit ing any attachments associated with the workflow trans action.
Note This is currently supported only for these workflow types:
16
CUSTOMER
○
New hire/ rehire/internal hire workflow
○
Job Info change workflow
○
Termination workflow
○
Global Assignment workflow
Implementing and Configuring Workflows in Employee Central Defining Workflows
Field
Description
Context
In case of a manager or position change, you can define whether the source or the target responsible needs to approve it. By default, Source and Target point to the same evaluator unless a workflow step changes the attribute value. Select Source to base the evaluation on the original attribute values of the workflow, before triggering the workflow. When you select Target, evaluation of the next step will be based on the new value of the attribute after the execution of the work flow. For example, when changing the manager, you can ad dress the workflow to the former manager (source) in the cur rent step, and to the new manager (target) in a subsequent step. For Global Assignments, selecting Source assigns the Home manager as the evaluator while selecting Target assigns the Host manager as the evaluator.
Relationship to Approver
Here you can specify whether the relationship of the workflow initiator, the subject user or the position (only if position rela tionship is selected) should be considered.
Note This field is only available if role or position relationship is used as Approver Type.
No Approver Behavior
Implementing and Configuring Workflows in Employee Central Defining Workflows
Define what should happen if no approver is found: ●
Skip this step
●
Stop workflow
CUSTOMER
17
Field
Description
Respect Permission
By default, role-based permissions are considered and the workflow participant can only see fields that he/she for which they have permission. If changed to NO, the workflow participant can see all the fields irrespective of the permission.
Note Role-based permissions are NOT supported for the follow ing: ●
New Hire/Rehire
●
Global Assignment
●
Concurrent Employment
●
Pension Payout
●
Dependents
●
Work Permit
●
Workflow Foundation Object
Note If user has entity level pending approval link but is not part of the workflow, then the permissions will be applied irre spective of this setting.
Note When the initiator role overlaps with the approver, cc, or contributor role, then they may be able to edit fields that should be read-only.
Note For sent back workflows, the following applies to the work flow initiator: ●
If all of the workflow steps incl. CC and contributor are marked with respect RBP = No, then this applies also for the initiator, to whom the workflow was sent back, which means that the system does not respect the permissions.
●
If one of the workflow steps is marked with respect RBP = Yes, then this applies also for the initiator, to whom the workflow was sent back, which means that permissions are respected.
18
CUSTOMER
Implementing and Configuring Workflows in Employee Central Defining Workflows
Field
Description ●
If the initiator is at the same time an approver/cc/ contributor and for this step the setting is respect RBP = No, then this applies also for the sent back workflow.
6.1
Routing Workflows
For the approval steps, workflow contributors and CC role, you can use different methods of evaluating the respective approver/employee(s). ● Role: With this, you can evaluate the reporting line of the employee or initiator and address the workflow, for example, to the employee self, manager, manager's manager, matrix manager or to further job relationships. ● Dynamic Role: A dynamic role can be used to route workflows to different approvers, depending on attributes that are used in the workflow content. It is typically used to define different behaviors in different parts of the company. You can do so by matching one or more attribute values to specific approvers of type user, dynamic group, or position. ● Dynamic Group: Similar to permission groups, you can define a group of employees that are dynamically included into this group on the basis of the employees’ job information attributes. When a workflow is addressed to a dynamic group, all employees will receive the workflow request in their inbox. ● Position: If position is selected, the workflow will go to all employees who are incumbents of this position at the time when the workflow participants are evaluated.
Note This is only available if Position Management is activated. ● Position Relationship: Relationships at the position, like parent position or assigned matrix managers, are derived to define the Step approver, Contributor and CC users. ● Person: Only available for CC role and Contributors, a concrete person can be defined. ● External Email: Only available for CC role. You can use this option, for example, to inform an external service center upon on a change.
Implementing and Configuring Workflows in Employee Central Defining Workflows
CUSTOMER
19
Workflows Steps Skip and Auto Replace Logic The following section explains how the system identifies whether a step or approver is skipped or replaced: Table 7: Parameters Note for approver type: Role and approver role: self, manager
System Response 1.
(EM) or manager's manager (MM)
If the self/EM/MM is the first step approver and the work flow initiator is same as the approver, the first step is skipped.
2. When a workflow is changed in flight with route change so that it starts over, then the first step shall not be skipped if the initiator is the approver. This is because the content has changed and the initiator needs to understand what has changed. 3. If the self/EM/MM is used in two subsequent steps as ap prover, one step is skipped to avoid redundant approver. Note for approver type: Dynamic Group & Position & Position
1.
If the dynamic group/position/position relationship is the first step approver and the initiator is one of the mem
Relationship
bers, this step is NOT skipped, since any other member in the group can approve the workflow. 2. Even if the dynamic group only has one member and the initiator is the member, this step is NOT skipped. 3. If the subject user is a member of the dynamic group & position & position relationship, we change the approver to the subject user's manager.
Note The exception to this is in a position workflow where the subject user = initiator. If the subject user is a member of the dynamic group & position & job rela tionship, we DON'T change the approver to subject us er's manager.
Note for approver type: Dynamic Role
1.
If the dynamic role is the first step, and If revolved Role type = PERSON, and the person = initiator, then the step will be skipped.
2. If the dynamic role is the first step, and If revolved Role type = dynamic group/position, and the initiator is one of the group members, then the step will NOT be skipped.
20
CUSTOMER
Implementing and Configuring Workflows in Employee Central Defining Workflows
6.1.1 Setting Up Dynamic Roles Use a dynamic role to route workflows to different approvers, depending on attributes that are used in the workflow content
Context Since Dynamic Roles are foundation objects, the fields the Admin can fill out for setting up a new Dynamic Role have been previously defined in the Corporate Data Model. By default, all foundation objects on Job entity will be shown when you create a new Dynamic Role. If you want to hide any fields, set their visibility attribute to “none”. In the following example, the fields Event Reason and Pay Grade will not appear on the UI for creating a new Dynamic Role: To set up the Dynamic Role, do the following: 1. Navigate to the Admin Center. In the Tools Search field, type Manage Organization, Pay and Job Structures. 2. In Create New, select Dynamic Role. 3. Enter the header data:
○ Dynamic Role ID ○ Dynamic Role ○ Description ○ Base Object Implementing and Configuring Workflows in Employee Central Defining Workflows
CUSTOMER
21
Note If Job Info is selected, the job info of the subject user or initiator is used to derive the respective approver. For position workflows, select Position as the base object. Then the respective fields from the position GO object are made available to define the criteria. To define an approver, the job info values of the workflow initiators are compared against the dynamic role criteria. 4. Enter the Dynamic Role Assignment data This defines the criteria which need to be matched in order to find an approver. Several criteria can be combined. At the end of each row you need to resolve the approver. In the field Resolver Type, select either Person, Dynamic Group, or Position.
5. Save your work.
Example Here is an example for a dynamic group for Finance Controller, where specific people are assigned for the respective legal entity and business units. If the employee whose data is changed belongs to Corporate Healthcare business unit, then Janet James is asked to approve.
22
CUSTOMER
Implementing and Configuring Workflows in Employee Central Defining Workflows
6.1.2 Setting Up Dynamic Groups Use dynamic groups to define a group of employees responsible for the workflow. The employees can be dynamically included into this group on the basis of the employees’ job information attributes.
Context If you want to need to have a group of employees responsible for a workflow step, then you need to set up Dynamic Groups in the system. Once the workflow is triggered, all members of the Dynamic Group receive the approval. As soon as one of the members approves the workflow request, it is removed from all members' pending approval requests. 1. Navigate to the Admin Center. In the Tools search field, type Manage Workflow Groups. 2. The workflow groups are listed here. You can create, edit, or delete groups as needed. Under Membership, you can see how many people are part of this group. Once the workflow is triggered, all members of the Dynamic Group receive the approval request. As soon as one of the members approves the workflow request, it is removed from all members' pending approval requests. 3. Click Create New Group. Enter a name and assign the group members. You can directly assign users, flexibly define based on employee’s criteria who is part of the group and you can exclude employees. You can add several people pools.
4. Click Done to save your work.
Implementing and Configuring Workflows in Employee Central Defining Workflows
CUSTOMER
23
6.1.3 Position Relationships Position relationships are only available if Position Management is enabled in your system. Relationships at the position are derived to define the Step approver, Contributor and CC users. For the Approver Role, select either Position, Parent Position, or Parent Parent Position. And in addition, you can select the HR manager and Matrix manager if the PositionMatrixRelationship is set to visible in the Position object definition. Then relationships at the position are derived to define the Step approver, Contributor and CC users.
Note The PositionMatrixRelationship options (HR Manager and Matrix Manager) in the Approver drop down are only shown if the PositionMatrixRelationship is visible in the Position object definition.
For the Relationship to Approver field, the following options are available: ● Employee Position: Will resolve based on Subject Users line of position ● Initiator Position: Will resolve based on Initiator users line of position ● Position: This option will be effective for position-based workflows
Note If you define 2 approval steps with the same position relationship, for example, manager, but one step with source and one step with target, and there is a data change without manager change, then the system will ask the manager to approve the same workflow twice.
24
CUSTOMER
Implementing and Configuring Workflows in Employee Central Defining Workflows
7
Triggering Workflows
Once you've defined the workflows that should be used for your company's processes, you will need to decide how workflows are triggered in the system. There are 3 ways to trigger workflows: ● Directly assign the workflow to the generic object This works best for simple cases where one workflow works for this object. For more information, see Assigning Workflows Directly [page 26]. ● Using business rules This works best where multiple workflows are needed for an object. For more information, see Defining Workflow Derivation Rules with Business Rules [page 26].
Recommendation We recommend using this where possible. ● Using YouCalc rules
Note This is NOT recommended for new customers. However, if you are still not using Time Off for leave of absenses (LOA) and you want to have LOA approvals, you need to use YouCalc. Using the new MDF-based business rules framework, customers can define business rules to set workflow configuration and event reasons. These rules can then be triggered when the entities are saved by defining them in the Succession Data Model (SDM). With the Business Confirguartion UI (BCUI), customers can assign the rules (defined in Admin Center Configure Business Rules ) to the respective base object. This assignment is stored in the Succession Data Model. Configure Business Rules and BCUI make this a complete solution for the Admin user. No provisioning access is required. It is recommended that new users adopt the event reason and workflow configuration derivation using business rules. For existing customers, we recommend the continued use of YouCalc rules since automatic migration from YouCalc to Business Rules is not supported.
Note These options are mutually exclusive with the existing option Enable youCalc rules engine for HRIS. Both options (youCalc and business rules) cannot be enabled together. This means that you either use youCalc rules for both workflow and event-reason derivation or you use business rules.
Implementing and Configuring Workflows in Employee Central Triggering Workflows
CUSTOMER
25
7.1
Assigning Workflows Directly
In case you have simple workflow processes, you can directly assign the workflow at the GO object. For example, if one workflow works for all Time Off processes, then you can assign this workflow directly at the Employee Time object definition in the Workflow Routing field.
Alternatively you can define a rule and assign the rule to the MDF object. This is described in Assigning a Workflow Derivation Rule to the Object [page 28]. However, if a rule and a direct assignment are in place, then only the rule will be considered.
7.2
Triggering Workflows Using Business Rules
7.2.1 Defining Workflow Derivation Rules with Business Rules Workflow configuration derivation rules are used to set an appropriate workflow configuration for a corresponding action. To achieve this, a transient field called wfConfig has been added to the entities that can be modified using workflows.
Note Business Rules must be set up for your system and you need to have the appropriate permissions. For more information, see the Using Business Rules in SuccessFactors guide on the SAP Help Portal.
Note Customers not using Time Off for Leave of Absence need to use You Calc Rules. For more information, see Triggering Workflows with XML File-Based Derivation (You Calc Rules) [page 30]. A few points about the field wfConfig:
26
CUSTOMER
Implementing and Configuring Workflows in Employee Central Triggering Workflows
● This field must not be defined in the data model. Note that the value of this field is not stored. ● This field must not be used when the YouCalc Alternative is enabled (Enable Business Rules for Workflow Derivation option). The following describes how you define workflow rules: 1. Navigate to the Admin Center. In the Tools search field, type Configure Business Rules. 2. On the Business Rules UI, select Basic rule and then choose a base object. You do not need to specify a Rule Type. 3. Configure the IF condition based on your business case. 4. In the THEN statement, set the wfConfig field with an appropriate workflow configuration.
Example Here is an example where a rule with “Job Information Model” as base object is configured. The IF condition checks the event reason and then sets the wfConfig field with the appropriate workflow configuration.
Note Exception for New Hire Workflows The base object must be: Employee Information The set workflow config field must be: Employee information.workflow information and not wfconfig You can put this rule under jobInfo, compInfo, employmentInfo or any element in the Succession Data Model You can find more examples in the Appendix at the end of this guide: Example Workflow Rules for the New Hire UI [page 78].
Implementing and Configuring Workflows in Employee Central Triggering Workflows
CUSTOMER
27
Recommendations for Workflow Rules ● It's recommended to have one rule with several IF statements rather than several single rules. ● When the entity is processed on the UI, the corresponding onSave rule is evaluated and the appropriate workflow configuration assigned is triggered if the rule condition is met successfully. On the other hand, if a workflow configuration is not assigned using the onSave rule, the system saves the data directly. ● New hire rules for workflow configuration derivation must be defined under the jobInfo entity. It’s recommended to configure the new hire rules in the beginning so that other rules further down can check for null values before setting it. ● Checking whether the wfConfig field is null before assigning a value to it can prevent overwriting the field wfConfig. ● All the onSave rules configured for an entity/element are evaluated. The value of the workflow configuration set by the last matching rule is considered by system. With youCalc rules framework, the value of the workflow configuration set by the first matching rule is considered by the system. Therefore, ensure that the rules are defined in an appropriate sequence.
Using Different Workflows for Different User Permission Groups Normally every transaction should trigger the same workflow, irrespective of who is doing the change. However there may be situations where you would like that for example administrators may make changes that would not trigger any workflow, or that should trigger a different workflow instead. For workflows that are triggered via business rules it is possible to support this. You can use the function “Is User in Permission Group()” to evaluate if the current user is part of a specific permission group (not the workflow group!) and then adapt the workflow that is selected. For more information, see the Functions chapter in the Using Business Rules in SuccessFactors on the SAP Help Portal.
7.2.2 Assigning a Workflow Derivation Rule to the Object A rule is only triggered when it is assigned to the corresponding object. The object to which you assign the rule can be an EC object (foundation object, person object, or employment object) that is defined as an HRIS element or an MDF object that is defined using the Metadata Framework (MDF). Depending on the object type, you have to follow different ways of assigning the rule to the object. For HRIS elements, the onSave Workflow Derivation Rule can be assigned in the Business Configuration UI within Trigger Rules.
28
CUSTOMER
Implementing and Configuring Workflows in Employee Central Triggering Workflows
For MDF objects, you can either assign the rule at the object or at generic object. The onSave Worklow Derivation Rule needs to be assigned within Configure Object Definition of the respective object.
Note You should only assign configuration rules to MDF objects, and not composites.
Implementing and Configuring Workflows in Employee Central Triggering Workflows
CUSTOMER
29
The order in which you place your rules is very important. Generally you should place specific rules at the bottom of the list since all the rules will be processed and only the last matched will be considered. More general rules should be higher up the list. onSave rules are NOT supported for country-specific fields.
7.3
Triggering Workflows with XML File-Based Derivation (You Calc Rules)
This is the legacy method for triggering workflows.
Note New customers should not use this method of triggering workflows. However, customers not using Time Off for Leave of Absence need to use You Calc Rules. The advantage of using business rules for triggering workflows is that any changes can be made in Admin Center without the need to access Provisioning. You can define whether a workflow is triggered based on a change on the UI, or if you want to use events you have set up before. Here are some examples of how you can set up the workflow in the XML file.
Note XML workflow rules doesn't support recurring pay component value comparison. For example, this setup doesn't work:
Sample Code You can find more examples in the Appendix at the end of this guide.
Example Select Workflow Based on Employee or Job Data In this example, whenever the user changes the department, workflow DEPT_CHANGE is used. DEPT_CHANGE is the external code of the workflow foundation object. You reference the department field as follows: ● The HRIS-element ID you defined before in the Succession Data Model is jobInfo. ● The HRIS-field ID is department.
Sample Code
30
CUSTOMER
Implementing and Configuring Workflows in Employee Central Triggering Workflows
DEPT_CHANGE
7.4
Limitations for Workflow and Event-Reason Derivation OnSave Rules
Context ● Processing grid/row type entities Defining rules that involve grid type entities can result in an unpredictable outcome since there is no guarantee on the order in which the individual row is processed.
Note Example: Consider a rule defined on the National ID entity as follows: IF NationalID.Country = USA THEN -> SET wfConfig = USA National ID Change ELSE -> SET wfConfig = Data Change. On the UI the following records are added for National ID: Table 8: Country
National ID Card Type
National ID
Is Primary?
USA
Social Security Number
778-22-7337
Yes
India
Permanent Account Number ABCDF8987E
No
Australia
Tax File Number
No
887 766 399
When the rule is evaluated the wfConfig is set with "Data Change" and not "USA National ID Change" as one might expect. The reason for this is when record with Country = Australia is processed at the end, the IF condition is not met and the ELSE branch sets wfConfig with value "Data Change". ● External codes of picklist cannot be configured in a rule. Implementing and Configuring Workflows in Employee Central Triggering Workflows
CUSTOMER
31
Example: Consider the following youCalc rules XML definition: JOBREL_WORKFLOW It is not possible to configure the same rule using business rules framework since all picklist options with external_code = custommanager will match the rule. ● It is not possible to access multiple entities in one rule for non-hire cases. For example, the Global Assignment entity cannot be used in conjunction with the jobInfo entity in a single rule for an "Add Global Assignment" case. The exception to this is that you can have a cross-portlet rule between jobInfo and compInfo using the Employement Information. During the rule configuration, choose jobInfo or jobInformationModel as the base object. ● It is not possible to have derivation rules for country-specific fields/objects Assigning a workflow derivation rule at a country specific field/object or in the CSF SDM is possible, but the system does not read the rule which means that no workflow is created.
32
CUSTOMER
Implementing and Configuring Workflows in Employee Central Triggering Workflows
8
Setting Up Workflow E-mail Notifications
You can edit email notifications to inform workflow participants about an action, so that you get an email if someone approves a workflow or writes a comment.
Context
Note The email address must be set up as type=Business AND Primary=Yes. If a user does not have this setup, then that user will not receive any workflow notifications This is an optional step; if you don't define email notifications, the approvers will still get the approval request in their To-Do List. To edit email notifications:
Procedure 1. Go to the Admin Center. 2. In the Tools search field, type E-Mail Notification Templates Settings. 3. Select the desired email template. For workflows, the following notifications are available. Template
Description
Workflow Action Approval Notification
Sends email notification on completion Initiator of the workflow.
Workflow Action Rejected Notification
Contributor
Sends email notification on rejection of Initiator the workflow.
Workflow Action Pending Notification
Target User
Sends email notification to current
Contributor Current approvers
approvers at every step approval (but not on the final step) and initiation of the workflow. Workflow Action Cancelled Notification Sends email notification on
Current approvers and contributors
cancellation of the workflow.
Implementing and Configuring Workflows in Employee Central Setting Up Workflow E-mail Notifications
CUSTOMER
33
Template
Description
Target User
Workflow Action Skipped Notification
Sends email notification when the
Skipped user
admin is skipped the user on the workflow. Workflow Comment Posted
Sends email notification when the
Notification
comment is posted on the workflow.
Initiator Contributor Previous Step Approver Current Approvers
Workflow Action Lockdown
Sends email notification when the
Notification
admin is locked down the workflow.
Initiator Contributor Previous Step Approver Current Approvers
Workflow Action Unlock Notification
Sends email notification when the
Initiator
admin is unlocked the workflow.
Contributor Previous Step Approver Current Approvers
Workflow Action Contributor
Sends email notification when the
Notification
workflow is initiated.
Workflow Action CC Role Notification
Sends email notification when the
Contributors
CC Users
completion of the workflow. Workflow Step Approved Notification
Sends email notification to initiator & contributor on approval of every step in the workflow.
Workflow Sent Back Notification
Sends email notification to initiator, previous approver's & contributor(s) when the approver sendback the
Initiator Contributors
Initiator Contributor Previous Step Approver
workflow to initiator.
Current step approvers Workflow Action Delegate Notification
Sends email notification when the
Initiator
workflow request is delegated. Workflow Action Delegate Revoke
Sends email notification when the
Notification
workflow request delegation is revoked
Initiator
by deleagator user.
34
CUSTOMER
Implementing and Configuring Workflows in Employee Central Setting Up Workflow E-mail Notifications
Template
Description
Target User
Workflow Action Delegate Decline
Sends email notification when the
Initiator
Notification
workflow request delegation is declined by delegatee user.
Workflow Action Escalate Notification
Sends email notification when the workflow request has been escalated.
Initiator Escalation previous approver Escalation new approver
Workflow Action Escalate Revoke Notification
Sends email notification when the workflow request escalation is revoked by escalation previous approver.
Workflow Action Escalate Decline
Sends email notification when the
Notification
workflow request escalation is declined by escalation new approver.
Initiator Escalation new approver
Initiator Escalation previous approver
4. You can change the templates using the following tags:
Note Make sure to always add the tags using the double brackets. Table 9: Tag Name
Description
ACTION_TYPE
The action the user has performed. This is used to distinguish if the user has created, updated, or deleted the object. This is only relevant for foundation object workflows.
APPROVAL_CHAIN
The approval chain up to the current user who gets the email notification. A user (step approver) gets added to an approval chain only if that user approves the workflow. If the first step approver declines the workflow, the approval chain tag would hold just the initiator value.
CREATED_USER
The user who created the workflow.
CREATED_TIME
Date/time at which the workflow was created. The company's default date format is selected.
CREATED_PERSON_ID_EXTERNAL
Person ID external of the user creating the workflow
CREATED_USER_EMAIL
Email ID of the user who initiated the change. This tag is used to uniquely identify a user.
CURRENT_OWNER
The current owner of the workflow with whom the workflow is or by whom the workflow is rejected (if the workflow is rejected by an approver)
Implementing and Configuring Workflows in Employee Central Setting Up Workflow E-mail Notifications
CUSTOMER
35
Tag Name
Description
DELEGATOR
User who delegated the workflow This tag is used to support workflow del egation.
DELEGATEE
User to whom this workflow has been delegated This tag is used to sup port workflow delegation.
EFFECTIVE_DATE
The effective start date for the suggested change
END_DATE
Time off (employee time) end date.
ESCALATION_PREV_APPROVER
This user is the previous approver from whom the workflow was escalated.
ESCALATION_NEW_APPROVER
This is the new approver to whom the workflow gets escalated.
EVENT
The event associated with the workflow
EVENT_REASON
Event reason associated with the workflow
Note For Employee Central 2.0, we suggest you use event reasons instead of HRIS actions.
Note If a portlet is used that does not use event reasons, the system derives the event-reason from a combination of the label and adds a concaten ated respective model name, for example, for personal info, national ID, home address, global assignment, pension payout, dependents, or work permit changes.
INITIATOR_COMMENT
The first comment made by the initiator while triggering the workflow.
PERSON_ID_EXTERNAL
Person ID external of the subject user.
RECENT_APPROVAL_DATE
This shows the latest approved step along with the last modified date.
RECENT_COMMENT_POSTED
Recently posted comment on workflow by the approver or contributor.
RECENT_COMMENT_POSTED_BY
Full name of the user who recently posted the comment.
RECENT_COMMENT_POSTED_DATE
Date/time when the latest comment was posted
RECENTLY_APPROVED_BY
The name of the user who recently approved the workflow request.
RECENTLY_APPROVED_BY_COMMENT
Comments entered by the user who recently approved the workflow re quest.
RECIPIENT_NAME
36
CUSTOMER
Full name of the email recipient
Implementing and Configuring Workflows in Employee Central Setting Up Workflow E-mail Notifications
Tag Name
Description
RECIPIENT_USERNAME
The user name of the recipient
REJECTED_BY
The user who rejected/declined the workflow.
REJECTED_BY_COMMENT
Comments entered by the user who rejects the workflow request.
REJECTED_DATE
If the status is rejected, then this shows the last modified date of the step.
START_DATE
Time off (employee time) start date.
SENTBACK_BY
Shows the last processor.
SENTBACK_BY_COMMENT
Shows a comment from the last processor
SUBJECT_USER
The full name of the user for whom the change is suggested. However, for new hire/rehire case, it will use the subjectUserId from the workflow re quest table. For foundation object workflows, it will print the object name. For objectbased MDF workflows, it will print the external name (if it exists or else it will print GO External code). If it is a user-based MDF workflow, it will print the name of the user.
SUBJECT_USER_ID
The user ID of the user for whom the change is suggested. However, for FO workflows, it would be empty.
SUBJECT_USER_USERNAME
The user name of the user for whom the change is suggested. However, for FO workflows, it would be empty.
SUBJECT_USER_COSTCENTER
Current cost center of the subject user. This tag is used to locate an em ployee in the org structure.
SUBJECT_USER_DEPARTMENT
Current department of the subject user. This tag is used to locate an em ployee in the org structure.
SUBJECT_USER_JOBCODE
Current job code of the subject user. This tag is used to know what an em ployee's job is.
SUBJECT_USER_JOBTITLE
Current job title of the subject user. This tag is used to know what an em ployee's job is.
The current local job title of the subject user. Current legal entity of the subject user. This tag is used to locate an em ployee in the org structure.
SUBJECT_USER_PREFERRED_NAME
The preferred name of the subject user.
SUBJECT_USER_BUSINESS_UNIT
The business unit of the subject user.
Implementing and Configuring Workflows in Employee Central Setting Up Workflow E-mail Notifications
CUSTOMER
37
Tag Name
Description
SUBJECT_USER_LOCATION
The location of the subject user.
TIME_OFF_TYPE
Time off (employee time) type.
VIEW_LINK
Link to the approval page
Note For CC Role, only workflows, meaning only notifications, we do not have an approval details UI, so we have a different behavior. For user-based workflows, we will go to the employee profile page (EC v12 = will redi rect to Public Profile page and for PP3 = will redirect to People Profile), for non-user based MDF workflows the link will direct the user to the ini tiator’s profile page. For object-based workflows, the user is directed to the FO management page.
5. Save your changes.
38
CUSTOMER
Implementing and Configuring Workflows in Employee Central Setting Up Workflow E-mail Notifications
9
Managing Workflows
9.1
Reminding Approvers About Stalled Workflows in Their Inbox
You can specify that the current workflow approver is reminded to take action on a pending workflow after a certain number of days.
Context To achieve this, you need to set up reminder notifications for approval workflows. You can either: ● Set up the same number of days for all workflows. In this case, you only have to set up the number of days once in Provisioning. ● Set up individual number of days for different workflow foundation objects. For example, you might want to have a more frequent reminder for promotion-related workflows than for job relationship changes. For simple data changes, you might even decide not to have any reminder notifications at all. The Admin can define the number of days for each workflow foundation object individually in the Admin Center.
Procedure 1. Log in to Provisioning, and select your company.
Remember As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact SAP Cloud Support. 2. Under Managing Job Scheduler, click Manage Scheduled Jobs. 3. On the Manage Scheduled Jobs page, click Create New Job. 4. On the Create New Job page, enter the required details: ○ Job Name: Enter a name for the job. ○ Job Owner: Enter a valid user in the system. ○ Job Type: Select Workflow Action Reminder. ○ Job Parameters: Remind In Days: Here you have two options: ○ To set up the same number of days for all workflows, enter a number into this field. This is the number of days after which a reminder notification is sent to the current approver of a pending workflow. Implementing and Configuring Workflows in Employee Central Managing Workflows
CUSTOMER
39
○ To set up individual number of days for different workflow foundation objects, leave this field empty. ○ Occurrence: Select Recurring. Choose an appropriate time. We recommend running this job daily, once a day. ○ Start Date: Enter the date when this job should be run for the first time. ○ Additional E-mail Recipients: You can enter additional email recipients who should be notified when this scheduled job is completed. Note that this has nothing to do with the actual workflow notification sent to the workflow approvers. 5. Click Create Job. 6. In the row that contains the created scheduled job, click If you have chosen to set up the same number of days for all workflows by entering a number in the Remind In Days field, you are done with setting up the reminder notifications. If you have chosen to set up individual number of days for different workflow foundation objects by leaving the Remind In Days field empty, there's one more step. 7. In Provisioning, check that the following HRIS field is part of the Corporate Data Model: ... ... The resulting system behavior looks like this: When the scheduled job runs, the system gets all the pending workflows. The number of days is determined either based on what you have entered in the scheduled job in Provisioning, or — if that field is empty — from what the Admin has entered for each workflow foundation object in the Admin Center. 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 original notification the approver gets when a workflow is triggered, with “Reminder:” in the email subject line. So there is no need to configure a specific email template for reminder notifications.
Example You have configured the number of days as 2 for a workflow foundation object. If no action has taken place for that workflow, then a reminder is sent on day 2, 4, 6, 8, and so on, until the current approver takes action on that workflow. The action could be adding a comment or changing approvers in the workflow. Let's say the current approver gets a reminder on day 2. The approver then makes a minor change on the third day, like adding a comment, and then again leaves the workflow pending for another 2 days. The next reminder is sent on day 5. This behavior is repeated until the approver finally approves or rejects the workflow.
9.2
Escalating Workflows Automatically
This sections describes how to automatically escalate workflows. It is now possible to define an escalation path for a workflow. When the workflow is then stalled for the specified number of days, the workflow is automatically escalated to the specified user. The new approver can decline the escalation, so it goes back to the previous approver. The last previous approver can also revoke the escalation.
40
CUSTOMER
Implementing and Configuring Workflows in Employee Central Managing Workflows
After decline or revoke, the escalation would continue with the next escalation step after the defined number of days. When an approver for a workflow is changed, the new approver will now receive an email and a new item in the activity log is created. Also, delegation/escalation records are removed and thus access for previous approvers is removed. The last escalation step is a recurring step and will be repeated until the workflow is approved or declined/sent back.
Note The admininstrator can set up the email templates and add tags for the escalation. The following templates are available: ● Workflow Action Escalate Notification ● Workflow Action Escalate Revoke Notification ● Workflow Action Escalate Decline Notification For more information, see Setting Up Workflow E-mail Notifications [page 33].
Remember As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact SAP Cloud Support. 1. You must first add the escalation to the Foundation Object table in the Corporate Data Model and reimport it from Provisioning.
Sample Code Include this xml tag in corporate data model under hris-element="wfConfig" 2. Navigate to the Admin Center. In the Tools search field, type Manage Data. 3. In the Create New field, select Escalation. 4. Create an escalation for each workflow required. Enter the following information: ○ Code ○ Escalation ID ○ RouteFrom ○ Target Value ○ After Days This is calendar days and not working days. For example: After 2 days, the workflow is escalated from the current approver to the current approver’s manager (step 1). In case the current approver’s manager is not reacting, step 2 of the escalation will be processed. Since the original approver is selected, the respective approver before escalation will be used to determine to relationship to the target – so in our case it will be escalated to the original approver’s manager manager. If the manager manager is not reacting within 3 days, step 3 will be processed. In this case, the HR of the person for whom the workflow is created, will be asked to approve the workflow. Based on the escalation object, the stalled workflow gets escalated to the escalated approver (new approver). What this means is that now the workflow sits in the To Do list of the escalated approver and can no longer Implementing and Configuring Workflows in Employee Central Managing Workflows
CUSTOMER
41
be approved by the original approver unless the escalated approver sends it back or the original approver revokes the escalation.
Note The escalation path is processed for each workflow step. If the final escalation step is defined with escalatedRouteFrom = current approver, the last step is of type recurring. This means that the final escalation step is escalated up the organization, meaning that after escalation if the workflow is stalled again for the defined day, it will be esclated up the defined targetValue. For example, a workflow is set up to be escalated after 4 days to the current approver’s manager. If after another 4 days the approver manger does not react, the workflow will be escalated to the manager’s manager, after another 4 days to the manager’s manager manager.
5. Save your settings.
42
CUSTOMER
Implementing and Configuring Workflows in Employee Central Managing Workflows
6. You can then assign the escalation in the workflow.
7. In Provisioning, configure a Workflow Auto Escalation background job to run daily. 1. In Provisioning, select the company. 2. Under Managing Job Scheduler, click Manage Scheduled Jobs. 3. On the Manage Scheduled Jobs page, click Create New Job. 4. On the Create New Job page, enter the required details: ○ Job Name: Enter a name for the job ○ Job Owner: Enter a valid user in the system ○ Job Type: Workflow Auto Escalation 5. Save your job.
Limitations ● You cannot escalate the workflow and then delegate it. You can only delegate it first and then escalate it. ● If there is no valid approver (based on the selection Stop the Workflow in the field No Approver Behavior), then the workflow will not be escalated automatically.
● We don't support Dynamic Group, Dynamic Role, Position and Position Relationship in the escalation targetValue field. If there is an escalation from A to B, then B cannot be a multi-user (B can be only one of the following single user Manager/ Manager Manager/HR manager) but A can be of multi-user type (A can be Dynamic Group, Dynamic Role, Position and Position Relationship). ● The escalator will not have a ToDo item. For example: After escalation from A to B, the ToDo from A will be deleted and A will not have a ToDo in for that workflow anymore. If the escalation goes further, meaning A->B->C, then both A and B will no longer have ToDos. A and B can access the workflow from the page. Implementing and Configuring Workflows in Employee Central Managing Workflows
Pending Requests
Requests waiting for my approval
CUSTOMER
43
In an escalation scenario with more than 2 levels of escalation, meaning A->B->C->D, only the original approver (A) and last escalator (C) and escalatee (D) can see the request from the Pending Requests page. The middle user (B) cannot see the pending request.
9.3
Delegating Workflows
There are 2 ways to delegate workflows. With delegation you can enable an option that will allow an approver to forward the workflow to another user in the company, who will take over the workflow and approve or decline in lieu of the initial approver. The recipient can then take over the workflow and approve or decline it in place of the initial approver. He or she also has the option of refusing the delegation. The initial approver can also recall the workflow. There are two options how to delegate workflows: ● Manual delegation: done individually by the employee workflow by workflow ● Auto delegation: if switched on, all workflows are delegated For both options it is necessary that delegation is supported at the workflow, meaning Is Delegate Supported is set to Yes.
Manual Delegation In each workflow configuration, you can define whether delegation should be allowed or not:
44
CUSTOMER
Implementing and Configuring Workflows in Employee Central Managing Workflows
If delegation is allowed, the initial approver has the option within workflow details to delegate a worflow:
Within the activity, you can see if a workflow has been delegated and by whom.
Auto Delegation With auto delegation switched on, all workflows that are set up with Delegation Allowed Yes are delegated to somebody else. If a manager goes on leave, he/she can activate this feature to have their workflows managed by a substitute in a timely manner. In order to allow auto delegation, the user needs to have the Allow Auto-Delegation permission. For more information, see HR Admin Permissions [page 10]. If a user has the rights, they can activate and de-activate it using the homepage tile
Quicklinks
Auto
Delegate
Implementing and Configuring Workflows in Employee Central Managing Workflows
CUSTOMER
45
46
CUSTOMER
Implementing and Configuring Workflows in Employee Central Managing Workflows
9.4
In-Flight Changes
You can control how approvers make changes to the content of the workflow transaction. The different options available are: ● No Edit: The option restricts the approver from making any changes. ● Edit with Route Change: This option gives the approver permisson to modify the workflow transaction. After the changes are made, the transaction will be re-evaluated and a new workflow automatically triggered. This can be the same workflow, but based on the given changes, this can also result in a different workflow. ● Edit without Route Change: Similar to the above, the approver can make changes. However, the workflow then continues to the next step and there is no new workflow. ● Edit Attachment Only: With this option, the approver can only make changes to any attachments available in the workflow content. Changes to the route are not permitted.
Note In-flight changes for dependents and work permit workflows are NOT supported. For in-flight changes to work with MDF objects, you must set the Pending Data field to Yes.
Implementing and Configuring Workflows in Employee Central Managing Workflows
CUSTOMER
47
9.4.1 Editing Workflow Attachments Approvers can upload or make changes to attachments in a workflow. The attachment is part of the transaction and is saved with it.
Note This is currently supported only for these workflow types: ● New hire/ rehire/internal hire workflow ● Job Info change workflow ● Termination workflow ● Global Assignment workflow The Workflow Attachment portlet is visible in the following scenarios:
48
CUSTOMER
Implementing and Configuring Workflows in Employee Central Managing Workflows
● If the workflow is pending and the user is the current step approver (includes delegatee and excludes delegator). In other words, when the approve, delegate, send back, decline delegation buttons are visible and the workflow step setting is either Edit attachment only, Edit with route, or Edit without route. ● If the workflow is sent back and the user is the initiator. The following actions will save the attachment: approve, send back, delegate, decline delegate( for delegatee), resubmit( for initiator). A message is displayed confirming the update to the attachment..
Implementing and Configuring Workflows in Employee Central Managing Workflows
CUSTOMER
49
10 Alerts and Notifications
This section describes how to set up alerts and notifications for workflows in Employee Central. You can set up To-Do alerts and email notifications that are sent when a certain period approaches its end to remind the user to take action. For example, you can define that the HR Admin is notified 10 days before an employee's contract ends. You can also customize the alert and notification template.
Note You can set up this feature for changes done to records for: ● Compensation ● Employment Information ● Global Assignments ● Job Information ● Non-Recurring Pay Components ● Recurring ● Time Off ● Work Permit Alerts are NOT supported for country-specific fields. You can flexibly define the following: ● Notification only: an email is sent to notify the defined person. In this case, define only the CC role in the workflow settings.
● Alert only: only an alert is generated in the ToDo of the defined person. In this case, define only the approver role in the workflow settings.
50
CUSTOMER
Implementing and Configuring Workflows in Employee Central Alerts and Notifications
● Alert and notification: an alert and an email notification are generated. In this case, define both the approver role and the CC role in the workflow settings. Here's an overview of the implementation sequence: Table 10: Step
Details
1. (Optional) Defining an Alert and Notification Template [page
If you want to deviate from the default template, you can de
52]
fine your own.
2. Defining an Alert Workflow [page 54]
The workflow defines which users get the alerts and notifica tions.
Implementing and Configuring Workflows in Employee Central Alerts and Notifications
CUSTOMER
51
Step
Details
3. Defining an Alert Rule [page 55]
Here you define.... ●
When the rule should be generated (for example, 10 days before a contract ends)
●
Which workflow is assigned to it The workflow defines which users get the alerts and noti fications: ○ ○
The CC users receive an email notification. The workflow step approvers receive an alert in their To-Do list.
○
If only CC users are assigned to a workflow, only email notifications are sent. If only workflow step ap provers are assigned to a workflow, only To-Do items are created as alerts.
●
Which alert message template is used for the alerts and notifications
4. Assigning an Alert Rule to the Object [page 59]
This enables the rule to be triggered.
5. Scheduling a Job [page 59]
The first time you are setting up alerts and notifications using rules, you need to schedule a job in Provisioning.
10.1 Defining an Alert and Notification Template This section describes how to set up alert messages in Employee Central.
Context If you do not define an alert message, the alerts and notifications follow this default format: ● Email Header/To-Do item name: Alert for (subject user name), (event reason) ● Email Body/To-Do item detail: Alert for (subject user name), (event reason) on (effective start date) To define your own alert message:
Procedure 1. Configuring the Object Definiton a. Navigate to the Admin Center.
52
CUSTOMER
Implementing and Configuring Workflows in Employee Central Alerts and Notifications
b. In the Tools Search field, type Configure Object Definitions. c. On the Configure Object Definitions page, search for Object Definition: AlertMessage. d. Change the Alert Description maximum length to 4000. This enables the user to enter long description texts. 2. Creating the Alert Message a. Go back to the Admin Center. b. In the Tools Search field, type Manage Data. c. Select Create New: AlertMessage. d. Enter the required fields: externalName: Enter a name for the alert message. externalCode: Enter a unique ID for the alert message. effectiveStatus: Select Active. alertHeader: Enter the default format for the header of the email notification message, and the To-Do item’s label. alertDescription: Enter the default format for the description of the email notification message and the ToDo item.
Note Make sure to always add the tags using the double brackets.
Note You can use only the following tags: ○ Subject user in the format [[SUBJECT_USER]] ○ Event reason in the format [[EVENT_REASON]] ○ Effective date in the format [[EFFECTIVE_DATE]] The effective date is the date when the data change comes into effect.
Note For Time Off, you can use these additional tags: ○ Time off start date in format [[START_DATE]] ○ Time off end date in format [[END_DATE]] ○ Time off type (PTO or maternity leave) in format [[TIME_OFF_TYPE]] ○ Time off status (pending, pending approval, or cancelled) in format[[TIME_OFF_STATUS]]
Implementing and Configuring Workflows in Employee Central Alerts and Notifications
CUSTOMER
53
3. Save your changes.
10.2 Defining an Alert Workflow The workflow defines which users get the alerts and notifications.
Context The CC users receive an email notification. The workflow step approvers receive an alert in their To-Do list. If only CC users are assigned to a workflow, only email notifications are sent. If only workflow step approvers are assigned to a workflow, only To-Do items are created as alerts.
Approvers in workflows are treated as equal participants, which means that, for alerts, there is no step consideration. If there are 3 steps in in the workflow object, when the alert triggers, the notification goes to all 3 at the same time. However, contributors do not have any role in Alerts. The CC user does not get any alerts in the ToDo list. CC users only get alert email notifications.
54
CUSTOMER
Implementing and Configuring Workflows in Employee Central Alerts and Notifications
10.3 Defining an Alert Rule You can define when the rule should be triggered, with which workflow, as well as which template should be used.
Procedure 1. Navigate to the Admin Center. 2. In the Tools search field, type Configure Business Rules. 3. Click Create New Rule. Select Basic. Enter the following fields: ○ Rule ID: Enter a unique external code for the rule. ○ Rule Name: Enter a name for the rule. ○ Base Object: We recommend using the same base object that matches the element to which you want to set the alert rule: Table 11: Base Object
HRIS element
Compensation Information
compInfo
Employee Information
employmentInfo
EmployeeTime
employeeTime
Global Assignment Details
globalInfo
Job Information
jobInfo
Non-Recurring Payment
payComponentNonRecurring
Recurring Deduction
payComponentRecurring
Work Permit Info
workPermitInfo
Note ○ Employee Information or Employment Details This accesses job info, job relationship, compensation and other entities. ○ Job Information This accesses all fields in job info plus the fields in Employment Detail. ○ Employee Information Model The difference between Employee Information and Employee Information Model is that, in the model, we can use current value and previous value comparison as well as the isVisible and isRequired properties.
Implementing and Configuring Workflows in Employee Central Alerts and Notifications
CUSTOMER
55
We recommend that you use the same base object that matches the element to which you want to set the saveAlert rule. For example, if you want to define a saveAlert rule for jobInfo, then use "Job Information" as the base object. However, using Employee Information as a base is an exception. We can access all entities through Employee Information. It is possible to define a saveAlert rule for jobInfo and use as the base object. But in the rule condition, you woud need to specify the fields from Job Information. ○ Rule Type: Select a rule type. You do not have to use a specific rule type for setting up alerts and notifications. 4. Edit the Parameters section. Select Alert from the dropdown list for the Object. Enter the text for both Code and Name fields. Make sure that the text is exactly Alert. Do not enter translated words here. It must be set to to work.
Note You do not need to add this parameter to Time off alerts.
5. Enter the IF conditions for the rule:
Note You must specify an IF condition. DO NOT use the IF Always condition. This would always trigger an alert. Avoid alert rules without an IF condition to avoid alert duplication / re-sending (creating alerts for every record change in the database) as well as performance issues. The following are examples for defining IF conditions. You can use them as examples for setting up the system and even combine them where necessary.
56
CUSTOMER
Implementing and Configuring Workflows in Employee Central Alerts and Notifications
Define IF conditions for certain criteria, for example, employees in Germany:
Define IF conditions for relevant employees, for example, employees who are not terminated or whose status is Inactive:
Define IF conditions for a data change of a certain field: You can set the system to look for data changes by comparing previous values. However, you can only use this comparison for effective-dated objects. For objects, where a user may have multiple records with the same field value, you need to avoid triggering multiple alerts. For example, every jobInfo record has Location = A. If you specify a rule condition: Location =A, then multiple alerts will be triggered because all records match the rule.
This condition will only check the record when the field is changed for Location Amsterdam. Define IF conditions for current records: When the employee has multiple historic records, all the job records will be involved to rule evaluation based on the last modified date. You can use the start data (event date) and the end date to control only the current and future record(s) into your alert.
Implementing and Configuring Workflows in Employee Central Alerts and Notifications
CUSTOMER
57
Combine all of these into one rule:
6. Enter the THEN conditions for the rule: Note the following for the THEN condition of the rule. You can use these set expressions: ○ Alert.Workflow Information defines which workflow is assigned to this rule. The workflow defines which users get an alert and/or a notification message. This is a required entry for the alert rule. This is a required entry for the alert rule. ○ Alert.Effective Date defines when the rule is triggered. This is a required entry for the alert rule. ○ Alert.Alert Message defines which custom alert message format is used for the alert and notification information. This is an optional entry for the alert rule; if it is not defined, the system uses the default message template as explained in step 1: Define an alert message.
However, for Time Off alerts, you have to set it to execute Trigger Employee Time Alert Event()
7. Save the rule.
58
CUSTOMER
Implementing and Configuring Workflows in Employee Central Alerts and Notifications
10.4 Assigning an Alert Rule to the Object
Procedure 1. Go to Admin Center. For HRIS elements, follow step 2. For MDF Objects, follow step 3. 2. In the Tools search field, type Manage Business Configuration. Assign the rule as SaveAlert to the object, for example for work permit.
Note If your company makes updates only using the data model, then the Sucession Data Model must be updated by exporting it, updating it, and then reimporting it to the system.
3. In the Admin Center, in the Tools search field, type Configure Object Definition. Assign the rule as a postSaveRule to the base object, for example, employeetimes.
10.5 Scheduling a Job You only have to do this once when you set up alerts and notifications for the first time.
Procedure 1. Log in to Provisioning, and select your company. Implementing and Configuring Workflows in Employee Central Alerts and Notifications
CUSTOMER
59
Remember As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact SAP Cloud Support. 2. Under Managing Job Scheduler, click Manage Scheduled Jobs. 3. On the Manage Scheduled Jobs page, click Create New Job. 4. On the Create New Job page, enter the required details: ○ Job Name: Enter a name for the job. ○ Job Owner: Enter a valid user in the system. ○ Job Parameters: Modified date since: Here you have two options: ○ Last successful EC Alert job run date If the scheduled job runs for the first time and you choose this option, the alert job checks all the history job information records. After the first scheduled job run, the alert job checks all the job information records that have been modified on or after the last successful EC alert job run date. ○ Specify a date If you choose this option, the alert job checks all the job information records that have been changed on or after the specified date.
Caution Carefully select the modified date to avoid long running or interrupted jobs. For the first time the job is run, we recommend that you define a meaningful date for the field Specify a date. If you choose the Specify a date, the job will scan the records that are updated after the date selected in Specify a date. If there are a large amount of records created/updated/imported in the setup date range, expect the job run to take awhile. Please avoid large amounts of records created/ updated/imported in the setup date range to ensure that the job will be completed successfully. After the first job, you can change the date to Last successful EC Alert job run date. If you choose to run from the Last successful EC Alert job run date, the job will scan the records that are updated after the last successful run date of the job.
60
CUSTOMER
Implementing and Configuring Workflows in Employee Central Alerts and Notifications
○ Occurrence: ○ If you have chosen Last successful EC Alert job run date, we recommend you select Recurring. ○ If you have chosen Specify a date, you have to select Once. 5. Click
10.6 Creating Alerts This sections explains how and when alerts are generated in the system. Rules are processed when the scheduled job (as explained in the the Scheduling a Job [page 59] section) scans all the records that have been modified since the specified date. Keep in mind that changes to the record are only saved directly if they don't have to go through an approval workflow themselves. Let's say the user changes the location. There is an approval workflow assigned to this type of change. The change will only be made to the job information record after the last approver of that workflow has approved the change. If the data change matches the rule you have defined beforehand, the system triggers the rule and creates an alert with an effective date. On that date, the alert is sent out to the defined employee(s).
Example
Implementing and Configuring Workflows in Employee Central Alerts and Notifications
CUSTOMER
61
Same Alert Message for 2 Different Rules When the job information record change matches multiple rules, and the rules use the same message object, only one To-Do alert or email notification are created. Table 12: Example 1: Two rules triggered on same date Job Information Re
Rule
Alert Effective Date
Alert Message
Alert
Job change 1
Rule 1
January 01
Message 1
Alert XY
Job change 1
Rule 2
January 01
Message 1
Alert XY
cord Change
As a result, only one To-Do item is created and one email notification is sent, as the message is the same.
Same Alert Message for 2 Different Rules on 2 Different Dates Table 13: Example 2: Two rules triggered on different dates Job Information Re
Rule
Alert Effective Date
Alert Message
Alert
Job change 1
Rule 1
January 01
Message 1
Alert AB
Job change 1
Rule 2
January 15
Message 1
Alert CD
cord Change
As a result, when the first rule is triggered, one To-Do item is created and one email notification is sent for Alert AB. When the second rule is triggered, the first To-Do item is deleted, as the message is the same. A new To-Do item is created and an email notification is sent for Alert CD. The system only updates the alert before the To-Do item is created. Once the To-Do item is created, no new To-Do item is created for the same alert message.
10.6.1 Example Alert for Time Off This sections shows how alerts work for a Time off alert. When an employee books extended time off or unpaid leave, you can have a rule set up to notify the manager 10 days prior to the return of an employee.
62
CUSTOMER
Implementing and Configuring Workflows in Employee Central Alerts and Notifications
Example Susan goes on maternity leave and requests on Sep 1, 2017 the following leave: Leave September 2, 2017 – November 15, 2017. So Susan’s manager will receive an alert on November 5th (effective date of the alert) about her return. Technically the alert is generated on September 1st with an effective date of November 5th.
Alternative Scenario - Leave Extension Susan changes her leave request on November 1st to extend her leave: Leave September 2, 2017 – November 30, 2017 The alert will be triggered on Nov 20th. The system deletes the previous alert and creates a new for the new effective date of November 20th.
Alternative Scenario - Leave Reduction Susan changes her leave request on November 1st to shorten her leave: Leave September 2, 2017 – October 30, 2017 Implementing and Configuring Workflows in Employee Central Alerts and Notifications
CUSTOMER
63
The alert will be triggered on November 1st. The system deletes the previous alert, creates a new alert with an effective date of October 20th, and sends it immediately.
Alternative Scenario - Leave Reduction Susan changes her leave request on November 1st and shortens her leave: Leave September 2, 2017 – November 5, 2017 The alert will be triggered on November 1st. The system deletes the previous alert, creates a new alert with an effective date of October 25th, and sends it immediately.
10.6.2 Example Alert for Work Permits This sections shows how alerts work for work permit alerts. You can set up a rule to have an alert that notifies the manager 1 month prior to the expiration date of a work permit for an employee.
Note Make sure the value for Alert.Effective Date is not null. If Alert.Effective Date field is null, then alerts will be sent immediately.If you don’t want to send an email in case of a null value for Alert.Effective Date, then add them to If condition of the rule.
64
CUSTOMER
Implementing and Configuring Workflows in Employee Central Alerts and Notifications
Example On September 1, 2012, Susan updates her work permit info in the system. Work Permit Germany expiration date 15.2.2017 So, Susan's manager will receive an alert on January 15, 2017 (effective date of the alert). Technically, the alert is generated on September 1, 2012 with an effective date of January 15, 2017.
Alternative Scenario - Extension On January 2, 2017, Susan updates the expiration date of her work permit in the system. Work Permit Germany expiration date 15.2.2020 So, the original alert created for January 15, 2017 is no longer needed. The system deletes the previous alert and creates a new one for the new effective date of January 15, 2020.
Alternative Scenario - Reduction On January 2, 2017, Susan updates the expiration date of her work permit in the system. Work Permit Germany expiry date 10.1.2017. The alert will be triggered on January 2nd. The system deletes the previous alert, creates a new alert with an effective date of January 2nd, and sends it immediately.
Alternative Scenario - Extension On February 1, 2017, Susan updates the expiration date of her work permit in the system. Work Permit Germany expiration date 10.1.2020 So, the original alert created for January 15, 2017 was triggered and sent. There is no automatic updates or deletion however. The system generates a new alert and creates a new one for the new effective date of December 10, 2019.
Note Already created alert To Dos are not updated automatically when a data change occurs. The alerts only react to changes in conditions set in the rule. For example, if there is a rule set to create an alert 30 days prior to the end of the probation end date for an employee, but the employee was terminated without changing the probation period end date, then the system will still trigger an alert, even though the employee is no longer at the company.
Implementing and Configuring Workflows in Employee Central Alerts and Notifications
CUSTOMER
65
11
Behavior of Object-Based Workflows
11.1
Foundation Objects
Prerequisites Note There are specific restrictions and ways to trigger workflows for foundation objects. For most of these objects, this no longer applies once they become generic objects. You have to create a workflow that considers the limitations for approver types.
Context You can create rules that trigger a workflow when a foundation object is created, changed, or deleted. The change to the foundation object is not executed until the workflow is approved. You use the Rules Engine to create such a rule. The following steps are required to set up foundation object workflows: 1. Create a rule that defines which workflow is triggered under which condition 2. Assign the rule to the corresponding foundation object in the Corporate Data Model 3. (Optional) Adjust the email notification template Limitations ● You can only create workflows for effective-dated foundation objects. ● The workflow is triggered when a foundation object is created, changed, or deleted. You cannot define a rule that triggers the workflow only when a foundation object is changed, or only when a foundation object is deleted. ● The workflow used for the foundation object supports only the following approver types: ○ For step approvers: Dynamic Group, Position ○ For contributors: Dynamic Group, Position ○ For CC users: Person, External Email, Dynamic Group, Position
Note All other approver types are skipped when the workflow is triggered. If the workflow has no valid step approver, the workflow is skipped completely and the changes to the foundation object are saved without triggering the workflow.
66
CUSTOMER
Implementing and Configuring Workflows in Employee Central Behavior of Object-Based Workflows
● Currently, you cannot edit or update workflows for foundation objects on the workflow approval page. ● If you have multiple workflows for creating a foundation object for the same foundation object, and these are triggered on the same effective date, the second workflow cannot be approved when the first workflow has been completed. Example: You create a foundation object Department A on effective start date 01/01/2014, and trigger workflow 1. Then you create a foundation object Department A on effective start date 01/01/2014, and trigger workflow 2 before workflow 1 is completed. When workflow 1 has been approved, the foundation object Department A (on 01/01/2014) is created. If you now want to complete workflow 2, the request will be rejected because the foundation object with the same data already exists.
Procedure 1. Create a rule that defines which workflow is triggered under which condition: a. Go to the Admin Center. b. In the tools Search field, type Configure Business Rules. c. Click the Create New Rule button. d. Enter a rule ID, rule name, and select any rule type. For more information about these fields, refer to the Implementing Business Rules in SuccessFactors Guide. e. In the Base Object field, select the foundation object to which you want to assign the rule later in the Corporate Data Model in step 2. Note: For rules without IF conditions, it does not matter which base object you choose. f. Click Manage Parameters. g. In the Manage Parameters dialog box, click Add New Parameter. h. Enter the following information: ○ Code: You have to enter FOWorkflow, using this exact spelling and capitalization. ○ Name: Here you can enter any name you want. This name will appear in the dropdown list for the IF and THEN statements of the rule as shown here:
○ Object: Select FO Workflow from the dropdown list. Implementing and Configuring Workflows in Employee Central Behavior of Object-Based Workflows
CUSTOMER
67
i.
Click Apply .
j.
Create the IF conditions of the rule. Here, you have two options: ○ Rules without IF conditions: If every change to the foundation object should trigger a workflow, define a rule without IF conditions by selecting the Always True checkbox as in this example:
○ Rules with IF conditions: If the workflow should only be triggered when specific conditions are met, define these IF conditions in the IF part of the rule as in this example:
In this example, the workflow is triggered for any change, including: ○ When the legal entity status changes to Active ○ When an inactive legal entity is deleted ○ When any other field of the legal entity is changed k. Create the THEN statement, where you refer to the workflow foundation object.
68
CUSTOMER
Implementing and Configuring Workflows in Employee Central Behavior of Object-Based Workflows
○ As left expression, select the FO Workflow object you have added before using Manage Parameters, and select Workflow Information as in this example:
○ As right expression, select the workflow you want to assign to the foundation object. l.
Save your changes.
2. Assign the rule to the corresponding foundation object in the Corporate Data Model: a. Go to Provisioning.
Remember As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact SAP Cloud Support. b. Download the Corporate Data Model. c. Assign the rule to the corresponding foundation object hris-element by adding the trigger-rule XML tag. Here’s an example where the rule is added to the foundation object Location in the Corporate Data Model: ...
Note Please consider the following: ○ You should assign only one foundation object workflow rule to each foundation object in the Corporate Data Model. ○ Use onSave as trigger-rule event.
Implementing and Configuring Workflows in Employee Central Behavior of Object-Based Workflows
CUSTOMER
69
3. Optional: Adjust email notification template When an email notification is sent for a foundation object workflow, the subject line contains information about whether the foundation object has been created, updated, or deleted. Here’s an example: “Department: JingDep123_1(JingDep1) [update]” If you want this information also to be included in the body of the email notification template, you can adjust the template by adding the tag [[ACTION_TYPE]]. To change the email notification template: a. Go to the Admin Center. b. In the Tools Search field, type E-Mail Notification Templates Settings. c. Insert the [[ACTION_TYPE]] tag in the body of the email as in this example:
Here’s an example of how the sent email notification looks like:
70
CUSTOMER
Implementing and Configuring Workflows in Employee Central Behavior of Object-Based Workflows
d. Save your changes.
Results Specifics for foundation object workflows ● Workflow approval page The following information is displayed on the workflow approval page when a foundation object workflow is triggered: ○ When a new foundation object has been created, all fields with values are displayed. ○ When a new foundation object record has been inserted for an existing foundation object, only the fields with changes are displayed. ○ When an existing foundation object is updated, only the fields with changed values are displayed. ○ When an existing foundation object is deleted, all fields are displayed. ● CC user notification When a workflow with CC users assigned to it is completed, the CC users are informed by email. The email includes a review link to the changed or new foundation object. Only users with the corresponding permission can view the foundation object page in read-only mode.
Implementing and Configuring Workflows in Employee Central Behavior of Object-Based Workflows
CUSTOMER
71
If the foundation object has been deleted, the email notification does not include a review link. However, currently, the tag [[VIEW_LINK]] is displayed, as in this example:
11.2
Generic Objects
Like foundation objects, workflows for generic objects must be triggered by business rules. For more information see, Integrating with Workflows in the Implementing the Metadata Framework guide.
Maintain ToDo Category Configure the ToDo Category in the object header of the base object within Configure Object Definition by selecting one entry, for example, Time Off Requests. This will ensure that the corresponding workflow will be displayed in the To Do list.
72
CUSTOMER
Implementing and Configuring Workflows in Employee Central Behavior of Object-Based Workflows
12
Troubleshooting
12.1
Troubleshooting Alerts
This section will help you with some issues related to alerts and notifications.
Why does the EC Alert Job run for long time? Remember As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact SAP Cloud Support. Check in Provisioning:
Reports
Monitor Jobs , then select the link under Details for that job.
For example, the number of job info records to be checked might be high. The EC alert and notification job is not designed to scan a huge amount of data. It is for monitoring the daily record update. There are more than 8 HRIS element need to be evaluated with saveAlert rule. When there are multiple saveAlert rule defined in each element and the record number is high, then the job will take a long time to run. There are a few ways to avoid an issue with a large amount of data: ● If the job has never been run before and the "last successfully run date" is empty. You must run the first job once with a "specify a date" = a reasonable run from date. For example: today is 12/14/2015. Set specify a date = 11/1/2015. That means it will scan the records that has been updated from last month. ● If the customer wants to evaluate all the imported job record with the saveAlert business rule, they have to wait until the job finished. They may expect a long run and the server may be down in the middle due to error or maintenance. The job will be re-started after the server is up. ● If the customer doesn't want to check all the imported record, run the schedule job once by choosing "specify a date" instead of "last successfully run date". For example: The customer imported 571089 records on 12/23/2015. Set the EC alert job to run from "specify a date = 12/24/2015" or after. This means the job will only scan the records updated after 12/24/2015. After the job is completed, the last successfully run date = current date( 12/24/2015). Then change the job setup to recurring daily job and use "last successfully run date".
Implementing and Configuring Workflows in Employee Central Troubleshooting
CUSTOMER
73
12.2 Troubleshooting Notifications This section will help you with some issues related to notifications.
Why are emails for workflow pending action, approval, declined and for cc users not being sent? Make sure that the user to which the email is intended to be sent has Email notification flag set to true or 1 (from database, users_sysinfo table for that user or from UserBean) Make sure that the email addresses are valid for ● initiator ● sender ● recipient In Provisioning, in the Mail Preference section, the Single Sender and Single Recipient checkboxes must be disabled along with Forward options.
Remember As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact SAP Cloud Support.
74
CUSTOMER
Implementing and Configuring Workflows in Employee Central Troubleshooting
12.3 Troubleshooting Approvals This section will help you with some issues related to approvals.
Application Error Attempting to Approve a Workflow If you receive an application error when trying to approve a workflow, it might be due to missing field values for the country code in the MDF Country object. For example:
To resolve the error, do the following: 1. Determine the legal entity associated with the user who is subject of the workflow in the Job Information section for the user. 2. Determine which country is associated with the legal entity. 3. Navigate to the Admin Center. In the Tools search field, type Manage Data. 4. Select the object Country and then select the actual country associated with the legal entity as determined in the previous step. 5. Enter the appropriate values for the 2 character Country Code as well as the 3 digit Country Code.
Implementing and Configuring Workflows in Employee Central Troubleshooting
CUSTOMER
75
6. Save. 7. Edit the Country object to update the values.
12.4 Troubleshooting Data Traceability This section describes a behavior change to data traceability.
Created By/Last Modified By Previously, for all EC HRIS workflows, Created By and Last Modified By used to have final approver as the value of workflow and not the person who initiated the change (as is the case without workflow). Now, however, the fields Created By and Last Modified By are filled with the workflow initiator. For cases where a user made an update to the workflow request, the value of Created By is the workflow initiator and the user who makes the correction/ update will be the value of Last Modified By. For workflows with effective-dated objects, Created By and Last Modified By is the create/insert initiator. After a data update, Created By is the create/insert initiator and Last Modified By is the data updater. For workflows with non-effective-dated objects, Created By and Last Modified By is the data creator. After a data update, Created By is the data creator and Last Modified by is the data change initiator. Workflows with the changed behavior: ● Concurrent Employment ● Global Assignment ● Job information ● Leave of Absence/ Return from Leave of Absence ● New hire /rehire/RCM hire/internal hire: only Job Info record has the behavior change ● Pension Payout ● Termination ● Work Permit
Note All MDF-entity based workflows already follow this principle, where Created by/Modified by is filled with the initiator of the data or the data change.
Created Date/Last Modified Date The Created Date and Last Modified Date stand for the date the change becomes active, meaning after the final approval of the workflow.
76
CUSTOMER
Implementing and Configuring Workflows in Employee Central Troubleshooting
12.5 Troubleshooting MDF-Based Workflow Objects This section will help you with some issues related to MDF-based workflow objects In the Configure Object Definition screen for the specific MDF object, make sure that the workflow MDF objects are set secured = No for the following: ● Alert message ● Auto delegation ● Escalate ● Email configuration Employee Central workflows do not leverage this MDF functionality, but has its own logic for permission access.
Implementing and Configuring Workflows in Employee Central Troubleshooting
CUSTOMER
77
13
Appendix
13.1
Example Workflow Rules for the New Hire UI
In the case of a new hire scenario, workflow configuration derivation rules must always be defined with the base object Employee Information/Employee Information Model. The field wfConfig is available on the Employee Information/Employee Information Model entity.
Note For New Hire Workflows: ● The base object must be: Employee Information ● The set workflow config field must be: Employee information.workflow information and not wfconfig ● You can put this rule under jobInfo, compInfo, employmentInfo or any element in the Succession Data Model A sample workflow configuration derivation rule for new hire is shown below.
78
CUSTOMER
Implementing and Configuring Workflows in Employee Central Appendix
In this example, the base object is "Employee Information" and there are two conditions. The behavior of the rule is as follows: Condition 1: Checks if the hire record's jobInfo event reason is set to New Hire and the jobInfo company is Ace USA and the hire record's compInfo Annualized Salary is greater than $200,000. If this condition is satisfied, the workflow configuration Hire (New or Rehire) is triggered. Condition 2: Checks if the hire record's jobInfo event reason is set to New Hire and the jobInfo company is Ace USA. This condition handles the case where the annualized salary is lesser. If this condition is satisfied, the workflow configuration New Hire General is triggered.
Related Information Defining Workflow Derivation Rules with Business Rules [page 26]
13.2 Example Workflow Rules for the ESS Workflow configuration derivation rules can be configured with an appropriate base object, such as personalInfo. The field wfConfig must be set with an appropriate value and when the rule condition matches, the workflow is triggered.
Example: Personal Info An example of configuring the workflow configuration derivation rule for an ESS case is illustrated below. In the example shown, the base object is “Personal Information Model” and there are three conditions. The behavior of the rule is as follows:
Implementing and Configuring Workflows in Employee Central Appendix
CUSTOMER
79
Condition 1: Checks if the personalInformation last name is changed (not equal to the last name’s previous value). If this condition is satisfied, the workflow configuration Last Name Change is triggered. Condition 2: Checks if the personalInformation marital status is changed (not equal to marital status’s previous value). If this condition is satisfied, the workflow configuration Marital Status change is triggered. Condition 3: An else condition that treats any other change to the employee’s personal information as a data change action and sets the workflow configuration to Data Change. This workflow is triggered if neither condition 1 nor condition 2 is satisfied.
Example: Work Permit In the rule, select Personal Document Information Model as the base object and add this rule to work permit object as onSave rule.
80
CUSTOMER
Implementing and Configuring Workflows in Employee Central Appendix
Once you have created the rule, you need to assign it to the Work Permit portlet.
Source Code Here is a sample YouCalc workflow rules to trigger the a work permit workflow:
Sample Code >
13.3 Example Workflow Rules for the MSS Workflow configuration derivation rules can be configured with an appropriate base object such as jobInfo, compInfo or jobRelationshipInfo. Set the field wfConfig with an appropriate workflow configuration and the corresponding workflow will then be triggered.
Implementing and Configuring Workflows in Employee Central Appendix
CUSTOMER
81
Example Global Assignments For global assignment workflows, you have to configure the corresponding event or event reason in the workflow rules XML, for example: jobInfo.event="GA" or: jobInfo.event-reason="AddGA" The workflow for editing a global assignment does not require an event or event reason specific to global assignments. You can assign configurable business rules (trigger-rules) to the Global Assignments portlet (in Job Info) for the rule events ● onView ● onChange ● onSave
Note For certain rules, you must pay attention to the Employment Type and the select the relevant entry (Home or Host Employment).
82
CUSTOMER
Implementing and Configuring Workflows in Employee Central Appendix
Example Job Info There are two rules defined for base objects jobInfo and compInfo entities - SET_JOBINFO_WF and SET_COMPINFO_WF.
Implementing and Configuring Workflows in Employee Central Appendix
CUSTOMER
83
The rule SET_JOBINFO_WF is configured as an onSave rule for jobInfo and the rule SET_COMPINFO_WF is configured as an onSave rule for compInfo. From the MSS Take Actions page, when both the jobInfo and compInfo entities are changed, the onSave rules behave as follows: 1. If the condition set by rule SET_JOBINFO_WF is met as well as the condition set by rule SET_COMPINFO_WF is met, then the workflow that is triggered is Promotion which is set on the jobInfo entity. 2. If only the jobInfo is changed and the condition mentioned by SET_JOBINFO_WF is met, then the workflow that is triggered is Promotion. 3. If only the compInfo is changed and the condition mentioned by SET_COMPINFO_WF is met then the workflow that is triggered is either Pay Rate Change or Range Penetration Change. 4. When multiple entities are processed from the MSS UI, the preference is given to the workflow configuration set on the jobInfo entity. If none is set on the jobInfo entity, then the system checks whether a workflow configuration is set on the compInfo entity. If none is set on the compInfo entity either, then the system proceeds to check whether a workflow configuration is assigned on any other entity. If none is assigned then the system saves the data directly. The table given below illustrates the case when multiple entities are being processed from the MSS UI.
Note If the MSS workflow has multiple entities, such as jobinfo, comp info and/or job relationship workflow, the wfConfig is derived from the onSave result in this order: 1. Pick from jobinfo entity's wf config result 2. Else: pick from compinfo entity's wf config result
84
CUSTOMER
Implementing and Configuring Workflows in Employee Central Appendix
3. Else: pick from other entity's wf config result 4. Else: pick from jobRelationship entity's wf config result Table 14: Scenario
Entities Proc
Rule ID
Rule Evaluated
Rule Result
essed
Workflow Con
Comments
figuration Trig gered
Change Job and jobinfo
SET_JO
Compensation
BINFO_WF
Yes
Success, Con
Promotion with
Though com
dition Matched
Pay Change
pinfo.wfConfig
(PROMO_PAY)
is set with Pay
Information compinfo
SET_COM
Yes
PINFO_WF
Success, Con
Rate Change,
dition Matched
wfConfig set on jobinfo is pre ferred.
Change Job In
jobinfo
formation
SET_JO
Yes
BINFO_WF
Success, Con
Promotion
The ELSE IF
dition Matched
(PROMO)
branch of the rule succeeds and sets the wfConfig with the value Pro motion (PROMO).
Change Com
compinfo
pensation Infor
SET_COM
Yes
PINFO_WF
Success, Con
Range Penetra
The ELSE IF
dition Matched
tion Change
branch of the
(RANGE_CHG)
rule succeeds
mation
and sets the wfConfig with the value Range Penetration Change (RANGE_CHG). Change Job In
jobinfo
formation, Job
SET_JO
Yes
BINFO_WF
Relationship,
Failed, Condi
No workflow
jobinfo.wfCon
tion Not
triggered, data
fig is not set
Matched
saved directly
and neither is
and Compensa
com
tion Information compinfo
SET_COM
Yes
PINFO_WF
jobRelationship
No rule
N/A
Failed, Condi
pinfo.wfConfig.
tion Not
There is no rule
Matched
configured for
N/A
the job relation ship and there fore wfConfig is not set. The data is saved di rectly to the system.
Implementing and Configuring Workflows in Employee Central Appendix
CUSTOMER
85
Note Table 15: For... ●
Internal Hire workflow
●
Global Assignment workflow
●
Concurrent Employment workflow
●
Termination workflow
●
New Hire workflow
Assign rule at ... Job Info
The rule can put in Job Info, Comp Info or any element but the base object must be Employee Information Model.
13.4 Example Workflows with XML File-Based Derivation (You Calc Rules)
Select Workflow Based on Event To base a workflow on an event, enter the ID in the following format: hris-element-id.event The event field is a picklist. Value “5” is the external code of the event. As you compare this value with what the user enters on the UI, or with the value derived by the system if you use event-reason derivation rules, you use the compareToNew attribute.
Tip If you have uploaded the standard picklist from SAP SuccessFactors without changing the labels, you can find the external codes and what their labels are in that file. In this example, the external code 5 refers to the event Data Change. If the picklist labels have been adjusted by the company, you need to check the picklists that were uploaded in the system: Go to the Admin Center. In the Tools Search field, type Manage Picklists.This is where you can download and open the picklist used in the system. In the column for the external code, look for the value. In the same row, you find the label for your language (for example, in column en_US). OnLeave
86
CUSTOMER
Implementing and Configuring Workflows in Employee Central Appendix
Select Workflow Based on Event Reason of the Change You can use any foundation object to create a workflow, including event reason. If you use event-reason derivation rules, create the rules required for your workflows in the corresponding XML file. So, in the example of a new hire, you can define a rule based on the event reason foundation object in the workflow XML file. The value is the external code of the event reason foundation object. The ID follows the following format: hris-element-id.event-reason See the following example: NewHire
Select Workflow Based on Country You can have different workflows for each country. The 3-letter ISO code is used for each country. In the following example, two workflows are configured for the same change, but for users belonging to different countries. The ID follows the format: hris-element-id.hris-field-id.country You also need to include the country as a value: value=”USA” CountryUSACountryIndia
Implementing and Configuring Workflows in Employee Central Appendix
CUSTOMER
87
Logical Operands for Rules Configuration You can use the following logical operands when defining rules: ● AND: Both conditions have to be true ● OR: At least one of the conditions has to be true ● XOR: a XOR b is true only when one of a, b is true, but NOT both are true (a so-called “exclusive OR”)
Note You cannot combine AND with OR, but you would have to create 2 different rules. For example, if you want a rule for a data change to manager and cost center or department, you have to set up a rule for a data change to manager and cost center, and then a second rule for manager and department.
Comparative Operands for Rules Configuration ● Greater: The new value is greater than the old value. ● Lesser: The new value is less than the old value. ● Equal: The new value is the same as the old value. If you want to set something to unequal, meaning data has changed, add inverse=”true” to it: Example for “greater” In this example, the rule is met when the value for the pay grade is increased: PAYGRADEINC Example for “lesser” In this example, the rule is met when the value for the pay grade is lower than before: PAYGRADEDEC Example for “equal”
88
CUSTOMER
Implementing and Configuring Workflows in Employee Central Appendix
“Equal” is mostly used in its reverse sense, meaning, that something has changed and thus is not equal anymore. This is achieved by adding theinverse=”true” attribute. In the following example, the rule is met when the location in the job information portlet is changed: PAYGRADEDEC
Field Change to a Certain Value Triggers Rule In this example, if an employee's department is changed to “ENG”, the workflow ENG_DEPT_CHANGE is used. The compareToNew attribute determines whether to use the new value for comparison or the old value; that is, if the compareToNew attribute value is true, then it uses the new department value that is changed in Employee Central. If the compareToNew attribute value is false, then it uses the user's current department. So in this example, if the user’s department is changed to something other than ENG, this rule will not be used: ENG_DEPT_CHANGE You can also set the compareToNew attribute to “false” if you want to evaluate the initial value of an attribute as in the following example:
Change to Specific Data Object Triggers Rule Instead of defining the HRIS-field ID as you did in the previous two examples, you can also define the ID of a specific foundation, person or employment object. In the following example, the pay component group A1 has been defined in the system. A1 is the external code of the pay component group (standard label on the UI is Pay Component Group ID). In the XML file, you follow this syntax: hris-element-id.externalCode The following rule is met when a change, such as a salary change, to A1 takes place: SC01 Implementing and Configuring Workflows in Employee Central Appendix
CUSTOMER
89
Rules for Dependents Here is an example of a rule for dependents. The country restriction can be applied to the active employment of employee rather than the country that refers to the employment. Without country restriction:
Sample Code DependentChange With country restriction:
Sample Code DependentChange Notes: will not work
Workflow Rule XML/ Event Reason Rule XML Doesn't Support Recurring Pay Component Value Comparision Since the XML rule doesn't support a value comparison, you can try this workaround: 1. In Manage Business Configuration, define a custom field in compensation information in the data model, and make sure to set the visibility to visible = both 2. If you want this field to be displayed in the UI, give permissions for this field. If no, then no permissions are needed.
90
CUSTOMER
Implementing and Configuring Workflows in Employee Central Appendix
3. In Configure Business Rules, define a business rule. Use compensation info as the base object. If "compensation information.compensation.pay component" = xx, then set custom field = Yes
4. In Manage Business Configuration, in compInfo, set this rule as an onSave rule. 5. In the workflow rule.xml, make this setting: 6. Trigger the expected workflow.
13.5 Mapping Existing YouCalc Rules to Rules in the Business Rules Framework This section describes how rules defined in the existing youCalc rules XML file can be configured using the business rules framework to derive workflow configuration. For more information about workflow, see the Setting Up Approval Workflows chapter. Consider the extract of a sample youCalc workflow derivation rules XML below. COMMONWF Implementing and Configuring Workflows in Employee Central Appendix
CUSTOMER
91
>
NEWHIREWF
There are two rules defined one intended to handle common data changes and the other to handle the new hire case. This scenario can be realized using the business rules framework by creating multiple rules as shown below: 1. RULE_ID : RULE_JOBINFO_WF Base Object: Job Information Model Rule Definition: IF jobInfo.jobCode.Value NOT EQUAL TO jobInfo.jobCode.PreviousValue OR jobInfo.FTE.Value NOT EQUAL TO jobInfo.jobCode.PreviousValueTHEN SET jobInfo.wfConfig.Value = COMMONWF. 2. RULE_ID : RULE_COMPINFO_WF Base Object: Compensation Info Model Rule Definition: IF compInfo.pay-type.Value NOT EQUAL TO compInfoM.pay-type.PreviousValue OR compInfo.benefitsRate.Value NOT EQUAL TO compInfo.benefitsRate.PreviousValueTHEN SET compInfo.wfConfig.Value = COMMONWF. 3. RULE_ID: RULE_GLOBALASSIGNMENT_WF Base Object: Global Assignment InfoModel. Rule Definition: IF globalAssignmentInfo.assignment-type.Value NOT EQUAL TO globalAssignmentInfo.assignmenttype.PreviousValue THEN SET globalAssignmentInfo.wfConfig.Value = COMMONWF. 4. RULE_ID: RULE_PERSONALINFO_WF Base Object: Personal Info Model Rule Definition: IF personalInfo.suffix.Value NOT EQUAL TO personalInfo.suffix.PreviousValue THEN SET personalInfo.wfConfig.Value = COMMONWF. 5. RULE_ID: RULE_NEWHIRE_WF Base Object: Employee Information Rule Definition: IF employeeInformation.jobInfo.eventReason = New Hire (H) THEN SET employeeInformation.wfConfig.Value = NEWHIREWF
13.6 Example Rules for Alerts The following section shows example rules for alerts.
How to Avoid Triggering an Alert for All Historic Records of an Employee When the employee has multiple historic records, all the job records will be involved to rule evaluation based on the last modified date. You can use the start data (event date) and the end date to control only the current and
92
CUSTOMER
Implementing and Configuring Workflows in Employee Central Appendix
future record(s) into your alert. Also, you can use the previous value comparison to narrow down the record. For example: "jobinfo.job code.previous value is not equal jobinfo.job code.value".
How to Avoid Triggering an Alert for Inactive Employees Use Jobinfo's employee status/event reason to detect whether user is terminated. Also, only check the "current " and "future" record. For example, you want to send an alert 30 days before the qualifying period end date for active employee only.
Implementing and Configuring Workflows in Employee Central Appendix
CUSTOMER
93
However, the drawback is that if the user is currently active but he/she has a future record as terminated. The current record will still trigger alert. It may confuse the user. You can say this user is an active user because he/she currently is active. You can say the user is terminated in the future and you don't want to send alert for this kind of user. The alternative solution is to use Employment detail.termination date because this field will be set even though it is a future-date terminated user.
94
CUSTOMER
Implementing and Configuring Workflows in Employee Central Appendix
How to Set Up an Alert for Employment Info Use the rule where the base object = Employment Details/Employment Details Model.
Note The model name in the rule selection drop-down may differ depending on the your SDM setup. Hris element id = employmentInfo The default/English label = Employment Details. So you see "Employment Details Model" as name in rule definition is easy to confuse with Employee Information / Employee Information model.
Implementing and Configuring Workflows in Employee Central Appendix
CUSTOMER
95
How to Set Up an Alert for Contract End You can create an alert to trigger 14 days before contract end of an employee.
96
CUSTOMER
Implementing and Configuring Workflows in Employee Central Appendix
Implementing and Configuring Workflows in Employee Central Appendix
CUSTOMER
97
Important Disclaimers and Legal Information
Coding Samples Any software coding and/or code lines / strings ("Code") included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended to better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, unless damages were caused by SAP intentionally or by SAP's gross negligence.
Accessibility The information contained in the SAP documentation represents SAP's current view of accessibility criteria as of the date of publication; it is in no way intended to be a binding guideline on how to ensure accessibility of software products. SAP in particular disclaims any liability in relation to this document. This disclaimer, however, does not apply in cases of willful misconduct or gross negligence of SAP. Furthermore, this document does not result in any direct or indirect contractual obligations of SAP.
Gender-Neutral Language As far as possible, SAP documentation is gender neutral. Depending on the context, the reader is addressed directly with "you", or a gender-neutral noun (such as "sales person" or "working days") is used. If when referring to members of both sexes, however, the third-person singular cannot be avoided or a gender-neutral noun does not exist, SAP reserves the right to use the masculine form of the noun and pronoun. This is to ensure that the documentation remains comprehensible.
Internet Hyperlinks The SAP documentation may contain hyperlinks to the Internet. These hyperlinks are intended to serve as a hint about where to find related information. SAP does not warrant the availability and correctness of this related information or the ability of this information to serve a particular purpose. SAP shall not be liable for any damages caused by the use of related information unless damages have been caused by SAP's gross negligence or willful misconduct. All links are categorized for transparency (see: http://help.sap.com/disclaimer).
98
CUSTOMER
Implementing and Configuring Workflows in Employee Central Important Disclaimers and Legal Information
Implementing and Configuring Workflows in Employee Central Important Disclaimers and Legal Information
