Product Documentation
INTERNAL
SuccessFactors
Table Of Contents
1
Overview: implementation sequence . . . .
5
1.1 What is Employee Central? . . . 5
1.2 What do you need to know before starting an implementation? . . . 5
1.3 Recommended 13-step implementation sequence . . . 5
2
Establishing a new customer account . . . .
7
2.1 Provisioning . . . 7
2.2 Initial configuration tasks . . . 7
2.3 Configuration Setup for To-Dos . . . 11
3
Managing role-based permissions . . . .
14
3.1 Managing permission roles for Employee Central . . . 14
3.2 User permissions relevant for Employee Central . . . 16
3.3 Administrator permissions relevant for Employee Central . . . 25
4
Setting up data models . . . .
30
4.1 What are data models? . . . 30
4.2 Setting up the Corporate Data Model . . . 40
4.3 Setting up the Succession Data Model . . . 46
4.4 Using the Business Configuration UI to Maintain Elements of the Succession Data Model . . . 57
4.5 Setting up country-specific data models . . . 69
4.6 Setting up country-specific picklists . . . 73
5
Working with foundation objects . . . .
78
5.1 What are foundation objects? . . . 78
5.2 What are the characteristics of foundation objects? . . . 78
5.3 Which foundation objects can you use to structure your business? . . . 80
5.4 Which foundation objects can you use to handle job-related areas? . . . 81
5.5 Which foundation objects can you use to handle pay-related areas? . . . 81
5.5 Pay-Related Objects A-Z . . . 81
5.6 Which other foundation objects are available? . . . 82
5.7 Setting up country-specific picklists for pay components or event reasons . . . 83
6
Working with generic objects . . . .
88
6.1 What are generic objects? . . . 88
6.2 What are the characteristics of generic objects? . . . 88
6.3 How do you configure and manage generic objects? . . . 89
6.5 How do you create associations for generic objects? . . . 91
7
Creating rules . . . .
95
7.1 Setting up propagation rules . . . 95
7.2 Setting up event-reason derivation rules . . . 98
7.3 Setting up configurable rules . . . 105
8
Setting up approval workflows . . . 126
8.1 What are approval workflows? . . . 126
8.2 When do you want to use approval workflows? . . . 126
8.3 What are approver types? . . . 126
8.4 What do you need to do first before you can create workflows? . . . 127
8.5 How do you create workflows? . . . 128
8.6 XML examples . . . 129
8.7 How do you set up alerts and notifications? . . . 133
9
Working with data imports . . . 143
9.1 Introduction to Data Imports . . . 143
9.2 Importing Foundation Data . . . 143
9.3 Translating Foundation Data . . . 144
9.4 Importing Employee Data . . . 150
9.5 Importing Picklists . . . 153
9.6 FAQs: Importing Data . . . 154
10
Managing HRIS sync . . . 160
10.1 Human Resource Information System (HRIS) Synchronization . . . 160
10.2 Data Integration for the Performance Management Suite . . . 167
10.3 HRIS Sync configuration workbook . . . 195
11
Employee Central and your mobile device . . . 197
11.1 Using Employee Central on your mobile device . . . 197
11.2 Mobile Time Off . . . 199
11.3 Mobile To-Dos in Employee Central . . . 201
12
Data Objects: Quick Reference Tables . . . 203
12.1 Foundation object tables . . . 203
12.2 HR Data . . . 240
Person object tables . . . 240
1 Overview: implementation sequence
1.1 What is Employee Central?
Employee Central drives a lot of the information you see in Employee Profile and talent information. Information is natively stored in our product so other modules can access the information. It captures information about a company’s organization, pay, job structure and employees.
Employee Central data is smart because it allows you to capture history, create associations, use effective-dated objects, define automated workflows and automatically configure options for on-screen selections.
1.2 What do you need to know before starting an implementation?
Now that you’ve completed your training and are familiar with how to set up Employee Central, you can use this handbook as a reference to reinforce your learning. This handbook further explains key EC concepts and provides a sequence to help you organize your implementation. Tips and recommendations based on seasoned PS experiences have been included through this handbook.
Use this handbook in tandem with the Configuration Workbook that you will be giving your customers. The Configuration Workbook is a working document that you will use to capture your customer’s requirements and is typically provided by your Team Leader.
While your customer will be completing the Configuration Workbook, you’ll be guiding them to get the right answers. Use the handbook to determine the type of questions you want to ask them so you’re able to implement successfully.
1.3 Recommended 13-step implementation sequence
To help you with your implementation, we recommend following this proven 13-step formula. This formula is based on PS expertise.
We strongly recommend you follow this sequence for the first few implementations and discuss any variations with your Team Lead.
For information on this step… See…
Step 1: Setting up a new account in Provisioning
Initial configuration tasks [page 7]
This section describes the steps to get started with your implementation, including the different options you need to select in Provisioning to enable Employee Central.
Step 2: Creating the
Super Admin Initial configuration tasks [page 7]The section How do you create the Super Admin describes the different steps required to create the
Super Admin. Step 3: Defining the
Corporate Data Model
Setting up the Corporate Data Model [page 40]
For information on
this step… See…
Step 4: Configuring the Succession Data Model
Setting up the Succession Data Model [page 46]
This section describes how to set up the Succession Data Model for your customer. Step 5: Configuring
the Country-Specific Corporate and Succession Data Models
Setting up country-specific data models [page 69]
This section describes how to set up Country-Specific Corporate and Succession Data Models for your customer.
Step 6: Importing the
Picklist Importing Picklists [page 153]This section describes how to import the different values that a customer sees when they click on a
dropdown menu. Step 7: Creating
Foundation Objects Working with foundation objects [page 78]This chapter describes what foundation objects are including how you can define them.
Step 8: Configuring
Propagation Rules Setting up propagation rules [page 95]This chapter describes how to set up the different rules that determine what options display on screen,
depending on user selections. Step 9: Creating
Event-Reason Derivation Rules
Setting up event-reason derivation rules [page 98]
This section describes how to set up the different rules. Depending on the attributes that change, the system automatically determines the rule to apply.
Step 10: Creating Workflow Derivation Rules
Setting up approval workflows [page 126]
This chapter describes what workflows are, when to use them and how to set them up. Step 11: Managing
Role-Based Permissions
Managing permission roles for Employee Central [page 14]
This section describes which permission roles are specific to Employee Central and how you manage them.
Please refer to the Role-Based Permissions Handbook for details on how to set up role-based permissions, permission groups and permission roles.
Step 12: Importing
Employee Data Working with data imports [page 143]This section describes everything you need to know about importing employee data.
Step 13: HRIS Sync Managing Human Resource Information System (HRIS) synchronization [page 160]
2 Establishing a new customer account
2.1 Provisioning
Provisioning is an internal tool that Professional Services consultants and partners use to set up SuccessFactors modules for a customer. You can access each customer instance from within Provisioning.
Customers do not have access to Provisioning.
2.2 Initial configuration tasks
To get started with the customer implementation, you need to do a number of initial configuration tasks as described below. These are the minimum settings you need to start working. You will make further Provisioning settings based on the customer's requirements as you progress through the implementation.
Prerequisite
An instance has already been created for the customer.
Tasks
Do the initial configuration tasks in the following sequence.
What basic options do you need to set?
1. Log on to Provisioning with your user name and password, and select the company from the list shown or through the initial letter of the company ID.
2. Select Edit Company Settings Company Settings .
3. Enable the company languages by selecting the checkboxes of the relevant language packs.
Make sure you select a minimum of one language pack. 4. Select the following Employee Central checkboxes:
5. Select the Role-based Permission checkbox:
6. Select the following checkboxes for Compensation and Generic Objects.
7. Select the following profile checkboxes:
8. Select the following user interface checkboxes:
9. Scroll back up to the top and select Save Feature on the right of the screen.
What Reporting options do you need to set?
1. On the Company Settings page of Provisioning, scroll down to the section Analytics and Dashboard Tabs & Misc Reporting.
3. Scroll to the top of this section and, on the right of the page, select Save.
What Attachment options do you need to set?
1. On the Company Settings page of Provisioning, scroll to the section Document Attachment.
If the customer requirements are not known at this time, make the following settings:
3. On the right of the page, select Save.
How do you create the Super Admin?
The Super Admin is the person who can give an employee the authorizations to work as a Security Admin or System Admin. The Super Admin is sometimes referred to as the “Super User.” For more information about Super Admins, refer to the Role-Based Permissions Handbook.
1. On the Company Settings page of Provisioning, scroll down until you are nearly at the bottom of the page.
2. Specify entries in the following fields:
The Super Admin will be asked to change the password on first logon. 3. On the right of the page, select Create Admin.
How do you keep the User Directory and Org Chart up to date?
The User Directory and Org Chart use data that is maintained and stored in Employee Central. You need to make sure that the data in the different systems is kept up to date. Use a Quartz job to sync the data automatically, based on the dates on which changes become effective.
1. Navigate away from the Company Settings page of Provisioning by clicking the company name on the top left.
2. Scroll down and select Manage Job Scheduler Manage Scheduled Jobs . 3. Select Create New Job (above the Job Type) field.
4. Enter a suitable job name (such as EC Effective Dates Sync).
5. As the job owner, specify the Super Admin you created in the previous task. You can use the Find User function to do this.
6. From the dropdown list, select the job type HRIS Sync.
7. Based on the customer requirements, specify the time and frequency of the job. 8. Specify additional email recipients and job start notifications as required. 9. On the bottom right, select Create Job.
Activating Employee Central SOAP APIs
1. Go to Edit Company Settings Company Settings .
2. Under Web Services flag the Employee Central SOAP API setting and save your changes. With this option turned on, you can use Employee Central SOAP APIs.
Activating the New Home Page
1. Go to Edit Company Settings Company Settings . 2. Flag the Wow Home Page setting and save your changes.
Activating the Admin Alert
To make the Admin Alert available for a user in your company flag the Manage Workflow Requests permission under Administrator Permissions Manage User .
2.3 Configuration Setup for To-Dos
Overview
As the name suggests, to-dos are tasks you are expected or required to carry out. For example, as a manager, you might be expected to approve an employee's rating or assessment.
Features
To-dos appear in your profile, but you must enable the feature before they appear there. You do this on Provisioning by choosing Company Settings, then checking the Show ToDo Portlet option under Home Page Settings.
To-Dos
You can manage how your To-Dos look using the To-Do List Manager. For example, you can:
● Choose how long completed tasks continue to be displayed.
● Choose how long before they're due pending tasks are displayed.
● Generate lists of to-dos covering a given period, such as a month or a year.
● Opt to drop “supplemental tasks” — that is, tasks you actually create from the list. Here's what the manager looks like:
To-Do List Manager
See Also
3 Managing role-based permissions
3.1 Managing permission roles for Employee Central
Role-based permissions allow you to grant different levels of read or write access depending on the role of the employee. For example, an employee is only allowed to read their own compensation information, but an HR Admin is allowed to edit it. You define these kind of permissions by managing permission roles.
As based permissions are used by all modules within SuccessFactors, we provide you an overview of the role-based permissions relevant for a basic implementation of Employee Central and what to consider when setting these up.
Note: The Add New Employee screen does not respect the role-based permissions you set up here. Instead it respects the settings from the data models with regards to whether a field or portlet is visible or editable.
What you need to do first:
You need to have set up role-based permissions before you can manage permission roles. You find more information about this in the Role-Based Permissions Handbook.
How do you manage permission roles?
1. Go to Administration Tools.
2. In the Manage Employees portlet, select Set User Permissions 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.
5. On the left side of the window, you see the different permission categories. Click a permission category to reveal the different permissions, for example, Employee Data which is listed under User Permissions. The list of permissions associated with this category are displayed on the right side. In our example, you can see the HR Information section that contains several permissions, for example, for Biographical Information. For more information about the different permissions, refer to User permissions relevant for Employee Central [page 16] and Administrator permissions relevant for Employee Central [page 25].
6. Select the checkboxes against the permissions you'd like to grant to the role. 7. Click the Done button when you finish marking your selection.
8. Back on the Permission Role Detail page, scroll down to the Grant this role to... section. Click the Add button to select the employees to be granted this permission.
The Grant this role to... page opens.
10. Specify the target population accordingly in step 2.
11. Click the Done button to assign this role to the corresponding users in the system. You are taken back to the Permission Role Detail page.
12. Click the Save Changes button to complete creating the role. If you click Cancel at this stage, the role will not be created.
For more information and examples on how to grant permission roles to employees, refer to the Role-Based Permissions Handbook.
3.2 User permissions relevant for Employee Central
Under User Permissions, the following permission categories are relevant for Employee Central:
● Employee Data
● Employee Central Effective Dated Entities ● Employee Views
In the following, you can find more information about each of these categories.
Employee Data
Under Employee Data, the following sections are relevant for Employee Central:
● HR Information ● Employment Details ● Global Assignment Details
Only available if you have activated Global Assignment Management in Provisioning.
● Pension Payout Details
Only available if you have activated pension payouts in Provisioning.
● HR Actions
● Future Dated Transaction Alert ● Transactions Pending Approval ● View Workflow Approval History ● Pay Component Groups ● Pay Components
Permissions relevant for these sections are:
● View ● Edit
Here you can find more information to each of these sections:
HR Information
Here you assign permissions for portlets that refer to non-effective dated entities for Employee Central. Non-effective dated means that the history for the changes will not be maintained (for example, for Phone Information).
The entries listed here refer to the different portlets that have been defined as HRIS elements in the Succession Data Model. You can choose these permissions:
● View: The user can see the portlet.
● Edit: The user can edit the portlet on the Personal Information or Employment Information page by clicking the Edit link in the portlet:
Note that the labels depend on the labels defined in the Succession Data Model. If you have taken over the standard Succession Data Model, the following entries are displayed under HR Information:
This HR Information
entry... ...refers to this HRIS element:
Biographical Information personInfo National ID Information nationalIdCard Phone Information phoneInfo Email Information emailInfo Business Email
Address This entry is an exception: It refers to the Email Type field of the
emailInfo HRIS element, where you can
select the type Business:
It is listed here because normally every employee needs a business email address. If a company assigns the email addresses to the employees and does not want them to be editable by the employees, select only
View permission here.
Social Accounts Information imInfo Primary Emergency Contact emergencyContactPrimary
This HR Information
entry... ...refers to this HRIS element:
Spot Bonus payComponentNonRecurring
Here you define the permissions for the manager:
● Select View to allow the user to view the Spot Bonus portlet on the Employment Information page.
● Select Edit so that the user can navigate from the Employment Information page to the Update
Employee Records page using the Take Action button:
You can assign approval workflows for changes done on the Update Employee Records page.
Spot Bonus Edit
Action payComponentNonRecurringHere you define the permissions for the employee for changes done on the Employment Information page.
Payment Information paymentInfo Work Permit Info workPermitInfo Global Assignment Details globalAssignmentInfo
This entry is only relevant when you have activated Global Assignments Management in Provisioning. You can find more information in the Global Assignments Handbook.
● Select View to allow the user to view the Global Assignment portlet on the Employment Information
page.
● Select Edit to allow the user to manage global assignments on the Update Employee Records page
using the Take Action button.
You can assign approval workflows for changes done on the Update Employee Records page.
Pension Payout
Details pensionPayoutsInfoThis entry is only relevant when you have activated pension payouts in Provisioning.
You can find more information in the Pension Payouts Config Guide.
● Select View to allow the user to view the Pension Payout Details portlet on the Employment
Information page.
● Select Edit to allow the user to manage pension payouts on the Update Employee Records page using
the Take Action button.
You can assign approval workflows for changes done on the Update Employee Records page.
Employment Details
This section refers to the Employment Details portlet. Listed here are the fields from the Succession Data Model for the HRIS element employmentInfo. Only the HRIS fields with visibility "both" or "view" are available for setting
For this Employment
Details entry... ...select this permission:
Employment
Details MSS For the manager: ● View to allow the manager to view the Spot Bonus portlet on the Employment Information page.
● Edit to allow the manager to navigate from the Employment Information page to the Update Employee
Records page using the Take Action button.
You can assign approval workflows for changes done on the Update Employee Records page.
Employment
Details Edit For the employee: ● View to allow the user to view the Employment Details portlet on the Employment Information page.
● Edit to allow the user to edit the portlet on the Employment Information page by clicking the Edit link
in the portlet.
Note that workflows cannot be assigned for changes done this way. Bonus Pay
Expiration Date This field is listed here because of a functional limitation of the role-based permissions framework. Hide thisfield from the user interface by deselecting View and Edit.
Global Assignment Details
This section refers to the Global Assignment Details portlet. Listed here are the fields from the Succession Data Model for the HRIS element globalAssignmentInfo. Only the HRIS fields with visibility "both" or "view" are
available for setting permissions. There is one exception:
For this Global Assignment
Details entry... ...select this permission:
Global Assignment Details Edit
● View to allow the user to view the Global Assignment Details portlet on the Employment Information
page.
● Edit to allow the user to edit the portlet on the Employment Information page by clicking the Edit link
in the portlet.
Note that workflows cannot be assigned for changes done this way.
Pension Payout Details
This section refers to the Pension Payout Details portlet. Listed here are the fields from the Succession Data Model for the HRIS element pensionPayoutsInfo. Only the HRIS fields with visibility "both" or "view" are available for
setting permissions. There is one exception:
For this Pension Payout Details
entry... ...select this permission:
Pension Payout Details Edit
● View to allow the user to view the Pension Payout Details portlet on the Employment Information page.
● Edit to allow the user to edit the portlet on the Employment Information page by clicking the Edit link in
the portlet.
Note that workflows cannot be assigned for changes done this way.
HR Actions
The HR Actions section controls mainly who has access to the Update Employee Records page for actions defined in the Succession Data Model.
This HR Action... ...defines this permission:
Update Employment Records (displayed as Take Action button)
This option overrules all other permissions in this section. It controls whether the user can see and use the Take Action button from the Employment Information page.
View Higher Grades This option defines if a manager can view an employee's job classification if it is higher than
the manager's.
To restrict a manager’s view, leave the permissions unchecked. Make sure that the job
classifications are assigned to a pay grade, and have a paygradeLevel maintained. When
the manager goes to the Update Employee Records page for Job Information, the list of job
classifications in the dropdown is limited to those whose paygradeLevel is less than the
manager’s. Note that this function is limited to this page; it does not have any effect on the Job Info History page.
hireAction This is an hris-action from the Succession Data Model. It defines if the user can access the
Add New Employee link in the Administration Tools.
reHireAction This is an hris-action from the Succession Data Model. It defines if the user can access the
Rehire Inactive Employee link in the Administration Tools.
terminateAction This is an hris-action from the Succession Data Model. It defines if the user can access the
Take Action button on the Employment Information page and select Terminate from the
dropdown menu.
Manage Leave of Absence This is an hris-action from the Succession Data Model. It defines if the user can access the
Take Action button on the Employment Information page and select Manage Leave of
Absence from the dropdown menu.
returnLeaveOfAbsenceAction This is an hris-action from the Succession Data Model. It defines if the user can enter a return date for an employee that is returning from a leave of absence. On the user interface, the user
can access the Return from Leave link on the Update Employee Records page for Manage
Leave of Absence.
Permissions to access the Update Employee Records page for Global Assignments are set in the section HR Information [page 16].
Future-Dated Transaction Alert
In this section, you define if a user has the permission to view future changes for effective-dated entities by clicking on the Pending future change… link as in this example:
Only the View permission is applicable here (Edit has no function). Future-dated transaction alerts can be set for the following portlets:
This portlet... ...refers to this HRIS element:
Personal Information personalInfo
Home Address homeAddress
Dependents personRelationshipInfo
This entry is only relevant if you have activated the Dependents Management feature in Provisioning. You can find more information in the Dependents Management Config Guide.
Job Information jobInfo
Compensation Information compInfo
Job Relationships jobRelationsInfo
Transactions Pending Approval
In this section, you define if a user can see if a workflow has been initiated, but has not been approved so far, by clicking on the Pending Approval link:
View means the pending approval link is shown, but you cannot click on it to get to the details of the workflow request.
Edit means you can view and click on the pending approval link. You can set the permission for the following portlets:
This portlet... ...refers to this HRIS element:
Personal Information personalInfo
Employment Details employmentInfo
Job Information jobInfo
Compensation Information compInfo
Spot Bonus payComponentNonRecurring
Job Relationships jobRelationsInfo
View Workflow Approval History
In this section, you can define the permissions to view the workflow history from the History page of the following effective-dated entities:
This portlet… ...refers to this HRIS element:
Personal Information personalInfo
Job Information jobInfo
Compensation Information compInfo
Here, only the View permission is relevant, Edit has no function. The user with View permission can select View Approval History from the Take Action dropdown menu from the History page as in this example:
Pay Component Groups
This section lists all pay component groups that exist in the system. Pay component groups are foundation objects.
AnnualizedSalary is a default pay component group that exists already in the system; the remaining entries in this section are the pay component groups the Admin has created in the system.
Only View is applicable here; Edit has no function. If you select View, the user can see the pay component group in the system, for example, on the Employment Information page:
Pay Components
This section lists all pay components that have been created in the system. Pay components are foundation objects.
View and Edit are both applicable for pay components. Select View to allow the user to see pay components on the user interface as read-only. Select Edit to allow the user to edit and delete a pay component on the Update Employee Data page by clicking the Take Action button and selecting Change Job and Comp Info from the dropdown menu:
Employee Central Effective Dated Entities
Here you can set field-level permissions for effective-dated portlets and fields. This includes also country-specific fields that are prefixed by the 3-letter ISO code (for example, FRA for France, DEU for Germany, and so on). There are 5 different permissions you can select for effective-dated entities:
● Delete: The user to delete an effective-dated entity. This is only applicable at element or portlet level, not at field level.
● View Current: The user can see only the current field value of an effective-dated entity. When the user looks at the history page, the past data record for this field is not displayed.
● View History: The user can see past values on the History page. This permission also includes the View Current permission, so that the user can also see the current field value.
● Edit/Insert: The user can edit an effective-dated entity by inserting a new data record for it which is effective as of a certain date. As the user does not really change the data record itself (then it would just overwrite the past data record), past data records are still available in the History. The field is also available for editing when a new data record is inserted.
● Correct: The user can make corrections to a field from the History page:
The following sections are relevant for Employee Central:
For this portlet… …you can set permissions for fields from:
Personal
Information personalInfoplus globalInfo fields from the country-specific Succession Data Model
Home Address homeAddress
This is an exception: Here you can only set permissions on portlet level, but not on field level.
Dependents personRelationshipInfo
This entry is only relevant if you have activated the Dependents Management feature in Provisioning. You can find more information in the Dependents Management Config Guide.
Job Information jobInfo
plus jobInfo fields from the country-specific Succession Data Model
Note: The field FTE is a calculated field and thus read-only; select only View Current and/or View
History. Compensation
Information
compInfo
Note: The fields range penetration and compa-ratio are calculated fields and thus read-only;
select only View Current and/or View History.
Job Relationships jobRelationsInfo
For a complete list of all listed fields, refer to the fields listed in your Succession Data Model and country-specific Succession Data Model.
In addition, for each of the sections, you can set these two permissions on portlet level:
○ Insert a new record from the History page
○ Add a new record using the Take Action dropdown menu, or add a new record using the Edit link in the portlet for those portlets that are listed on the Personal Information page
Use this option when you want to associate an approval workflow with the changes done in this portlet.
Select Correct as minimum if you want to grant this permission to a user.
● Edit Link: Allows the user to edit fields in the portlet by clicking the Edit link in the portlet on the Employment Information or Personal Information page.
The remaining entries refer to the fields listed in the Succession Data Model and country-specific Succession Data Model. If a field is configured in both the Succession Data Model and the country-specific Succession Data Model, only the field from the Succession Data Model is shown in this list.
Employee Views
Under Employee Views, you define if the user can access pages from the Employee Files using the dropdown menu like in this example:
The following employee views are relevant for Employee Central:
● Employment Information: Grants access to the Employment Information page
● Personal Information: Grants access to the Personal Information page
● Pending Requests: Grants access to the Pending Requests page for workflows requested by you, or of which you are the approver as shown here:
3.3 Administrator permissions relevant for Employee Central
Under Administrator Permissions, the following permission categories are relevant for Employee Central:
● Manage Compensation ● Manage System Properties ● Manage User
● Manage Time Off ● Manage Mass Changes ● Employee Central API ● Manage Foundation Objects ● Manage Foundation Object Types ● Metadata Framework
● Manage Business Configuration ● Manage Position
In the following, you can find more information about each of these categories.
Manage Compensation
In this category, one entry is required for Employee Central to ensure that the calculation of the pay groups works: Select the Manage Currency Conversion Rate Tables checkbox.
Manage System Properties
Select the Company System and Logo Settings checkbox. This allows the Admin to access the Company System and Logo Settings link in the Administration Tools, which has Employee Central relevant settings.
1. Go to Administration Tools. In the Company Processes & Cycles portlet, select Company
Settings Company System and Logo Settings .
2. On the Company Logo page, select the following three checkboxes that are relevant for Employee Central:
● Enable Address Validations ● Enable National ID Validations ● Enable Bank Account Validations
3. Optional: Depending on the customer's requirements, you can make an entry in the field Next Person Id Assigned.
Example: Let's say a company with 10.000 employees acquires another company. When merging the employees into one company, 5.000 new employees are added with a CSV file import to the system. You would then need to set the ID for the next person that is hired to be the current number of employees plus 1, so you would enter 15.001 in the Next Person Id Assigned field.
Manage User
● Add New User: Grants access to the Add New Employees link in the Administration Tools.
● Rehire Inactive Employee: Grants access to the Rehire Inactive Employee link in the Administration Tools.
● Include Inactive Employees in the search: Enables the search for inactive users on the Employee Files page as in this example:
and in the directory search:
● Import Employee Data: Grants access to the Import Employee Data link in the Administration Tools.
● Manage Workflow Requests: Grants access to the Manage Workflow Requests link in the Administration Tools, for example, to change the approver for a particular workflow.
Note that the Admin can only access the workflow requests for the target population to which the Admin role has been granted access.
● Manage Workflow Groups: Grants access to the Manage Workflow Groups link in the Administration Tools.
Manage Time Off
Here you set permissions relevant for Time Off Management. You can find more details about how to configure Time Off in the Time Off handbook.
Manage Mass Changes
Here you set permissions relevant for Mass Changes. You can find more details about how to configure Mass Changes in the Mass Changes Config Guide.
Employee Central API
Here you set permissions for SOAP-based application programming interfaces (APIs) for Employee Central. These are relevant for integrating Employee Central with other software products.
These permissions are only relevant when you have activated the corresponding APIs in Provisioning. The Foundation APIs are relevant for foundation data, the HRIS APIs for person and employment data:
● Employee Central Foundation SOAP API ● Employee Central HRIS SOAP API
● Employee Central Foundation OData API (read-only) ● Employee Central HRIS OData API (read-only) ● Employee Central Foundation OData API (editable) ● Employee Central HRIS OData API (editable)
Manage Foundation Objects
Here you define permissions for working with foundation objects.
● Import Foundation Data: Grants access to the Import Foundation Data link in the Administration Tools.
● Import Translations: Allows the Admin to import translations for the jobCode foundation object, using the Import Translations link in the Administration Tools. You can find more information under Translating Foundation Data [page 144].
Manage Foundation Object Types
Here you define permissions for the Admin that refer to the different types of foundation objects. Foundation objects are created, edited and deleted in the Administration Tools, in the Company Processes & Cycles portlet, under
Employee Files Manage Organization, Pay and Job Structures .
The following permissions are relevant here and refer to what the Admin is allowed to do on the Manage Organization, Pay and Job Structures page:
● View: The Admin can only view the corresponding foundation object type.
● Create: The Admin can create a foundation object of the selected type.
● Insert: The Admin can create a new data record for a foundation object type, by clicking the
● Correct: The Admin can correct foundation objects by selecting Take Action Make Correction in the
History page:
● Delete: The Admin can delete foundation objects by selecting Take Action Permanently delete record
in the History page:
Metadata Framework
The Metadata Framework is used to create generic objects that are also used in Employee Central, for example, to create customer-specific foundation objects. It is also used in Employee Central to create configurable rules. These are the permissions:
● Configure Generic Object Definition: Allows the Admin to access the Configure Generic Object Definition link in the Administration Tools, where the Admin can create generic object definitions and generic object picklists.
● Manage Data: Allows the user to access the Manage Data link in the Administration Tools.
● Configure Business Rules: Allows the Admin to access the Configure Business Rules link in the Administration Tools.
● Read/Write Permission on Metadata Framework: Allows the Admin to read/write generic objects on any page in the system.
What is the difference to the Manage Data permission?
Without the read/write permission, the user cannot see or manage generic objects on any page in the system. Without the Manage Data permission, the user cannot access the Manage Data page, but is still able to manage data from other pages, such as the Configure Business Rules page (if the
Configure Business Rules permission is granted).
● Import Permission on Metadata Framework: Allows the Admin to import and export data for generic objects or business rules using the Import and Export Data link in the Administration Tools.
You can find more information for the use of generic objects in Employee Central under How do you create customer-specific foundation objects? [page 90] and Setting up configurable rules [page 105].
For more information about the Metadata Framework in general, refer to the Metadata Framework Implementation Handbook.
Manage Business Configuration
This entry is only displayed if you have activated the Business Configuration in Admin Tools feature in Provisioning. Choose Select All to allow the Admin to use the Business Configuration UI to make changes to the Succession Data Model and the country-specific Succession Data Model.
Manage Position
Here you set permissions relevant for Position Management. You can find more details about how to configure Position Management in the Position Management Handbook.
4 Setting up data models
4.1 What are data models?
Data models are used to set up Employee Central in that way that satisfies a company's requirements. You define how a company's organization structure is reflected in the system and what entries a user can make to set up company, person, and employment data. You can add customer-specific fields and rename fields.
The data models are:
● Corporate Data Model
This is where you set up a company's organization, pay and job structure. The data model refers to data that is used throughout the entire instance of the customer.
● Succession Data Model
This is where you set up the data structure of data that relates to the people working in a company, such as compensation and address information.
● Country-specific Corporate Data Model
This is where you set up fields that are specific to a single country. This data model might be needed if the company has locations in more than one country, for example, to define the corporate address fields for each country.
● Country-specific Succession Data Model
This is where you set up international formats and fields, for example, for addresses and national IDs. You might want to set this data model up even if a company operates in only one country, as your employees might live or come from abroad.
What are foundation objects, generic objects, person objects, and employment
objects?
These are the four types of data objects that are used in the data models:
● Foundation objects
● Generic objects
● Person objects
● Employment objects
Foundation objects define company data. Generic objects make available certain settings and functions relating to employees, such as vacation and position information. Person and employment objects define employee data and are sometimes referred to as HR data objects. In the following section, you can find more information about these data objects.
What are foundation objects?
With foundation objects you set up data that can be shared across the entire company, such as job codes, departments, or cost centers. Foundation objects can be subdivided into four main areas:
● Organization structures
● Pay structures
● Other data objects, such as event reasons, workflows, and dynamic roles
You define foundation objects in the Corporate Data Model and the country-specific Corporate Data Model. You can find more information about foundation objects in What are foundation objects? [page 78] and under Foundation object tables [page 203].
What are generic objects?
You use generic objects for settings and information relating to the people working for a business. This information includes, for example, vacation and position information.
You have to enable generic objects in your installation before you can use them. You do this in Provisioning, by checking the Enable Generic Objects box.
You define generic objects in the Succession Data Model and the country-specific Succession Data Model.
What are person objects?
Person objects include information that is linked to the person and does not depend on the job, such as the employee's address and national ID.
You define person objects in the Succession Data Model and the country-specific Succession Data Model. You can find more information about person objects under Person object tables [page 240].
What are employment objects?
Employment objects include job-related information about a person, such as compensation and hire date. You define employment objects in the Succession Data Model.
You can find more information about employment objects under Employment object tables [page 255].
How do you work with data models?
The data models are XML files that you can adjust according to a company's requirements. The XML files have standard elements and fields included, so you need only touch those parts of it you want to adjust. You can use the existing XML coding as a guideline, and you also find XML examples and explanations in the following chapters.
General information on data model XML files
The following information is meant to help you understand how the XML files are structured and what you can change.
XML example
The following is an example of how a foundation object is defined in the Corporate Data Model:
<hris-element id=”company”> <label>Legal Entity</label>
<hris-field max-length=”32” id=”externalCode” visibility=”both” required=”true” pii=”false”>
<label>Legal Entity ID</label> </hris-field>
</hris-element>
HRIS element: Data objects are set up as HRIS elements in the XML files. Each HRIS element has an ID that you cannot change. In our example, the foundation object “Legal Entity” has the ID “company”. Whenever you refer to this foundation object in one of the XML files, you reference this ID.
HRIS field: Each HRIS elements has certain HRIS fields assigned to it. This is the field that appears on the UI, except when the visibility of the field is set to “none”.
Field types
In the data models, you define the data objects and the fields they refer to. There are different field types:
● Standard fields
Each HRIS element has a number of standard fields to handle the most common customer requirements. Standard fields have a predefined ID you should not change. The predefined XML files for the data models contain only a selection of the most widely used fields; for a detailed overview of all possible fields, check the data object tables:
○ Foundation object tables [page 203]
○ Person object tables [page 240]
○ Employment object tables [page 255]
● Custom fields
Each HRIS element has several custom fields to add customer-specific information. These can be text fields, date fields, or number fields. Some custom fields are included in the standard XML files and are by default hidden, so you have to explicitly change their visibility attribute if you want them to appear on the UI. You should also change the standard label to a meaningful name.
This is what a custom field looks like in the XML code that is by default hidden:
<hris-field max-length=”45” id=”custom-string1” visibility=”none”
required=”false” />
<label>Custom String1</label> ...
To find out how many custom fields you can use for an HRIS element and what their field ID is, check the corresponding tables for the data objects:
○ Foundation object tables [page 203]
○ Person object tables [page 240]
○ Employment object tables [page 255]
● Country-specific fields
You can add country-specific fields using the country-specific data models. For more information, see Setting up country-specific data models [page 69].
Field order
The order in which the fields are displayed on the UI is determined by the order in which they are listed in the Corporate or Succession Data Model. Exception is the start date: This always appears on top of the screen as the date when the change is supposed to be effective. For the order of specific fields, refer to chapter Setting up country-specific data models [page 69].
Visibility of fields
You define if a field is visible on the UI by setting the value of the attribute visibility accordingly: ● “none”: Field is hidden. You cannot import data for this field via CSV files.
● “view”: Field is read-only. You cannot import data for this field via CSV files. ● “both”: Field is visible on the UI and can be edited
Mostly, you would use either the values “none” — to hide fields that are not needed — or “both” — to allow data entry and data import.
This is what the XML code looks like for a hidden field:
<hris-element id=”company”> <label>Legal Entity</label>
<hris-field id=”end-date” visibility=”none” required=”false” pii=”false”> ...
If you want to allow data import for a field that is read-only (that is, with visibility=”view”), you can add
the attribute allow-import=”true” to it in the corresponding data model. This could be the case for the
employee ID field: If the ID is system-generated, you prevent the user from accidentally changing the ID by setting it to read-only. However, you might want to upload existing data for the employees, including their IDs, via CSV file. To make this possible, add the allow-import=”true” attribute as in this example:
<hris-field max-length=”32” id=”person-id-external” visibility=”view” allow-import=”true”>
<label>Employee ID</label> </hris-field>
Note that the person-id-external field is an exception: You can also use the allow-import attribute
when this field is hidden (that is, with visibility=”none”).
Mandatory fields
You can make a field mandatory by setting the attribute “required” accordingly:
● “true”: The field is mandatory. It is flagged as such on the UI and the user has to enter a value to be able to
save changes.
● “false”: The field is optional.
This is what it looks like in the XML code when a field is mandatory:
<hris-element id=”location”> <label>Location</label>
<hris-field max-length=”32” id=”externalCode” visibility=”view” required=”true” /> <label>Code</label>
...
For which fields can you not change the “required” attribute?
The following HRIS fields still require a user entry on the UI, even if you change the attribute in the XML file to
required=”false”: ● start-date ● externalCode ● status
…plus the following HRIS fields as listed below:
For this HRIS element in the Corporate Data Model... ...this HRIS field is always required:
company country
corporateAddress country
dynamicRoleAssignment person
eventReason event
For this HRIS element in the Corporate Data Model... ...this HRIS field is always required: payCalendar payPeriodBeginDate payPeriodEndDate payGroupCode payComponent payComponentType payRange frequency wfConfigCC actorRole actorType context wfConfigContributor actorRole actorType context wfStepApprover approverRole approverType context
For this HRIS element in the Succession Data Model... ...this HRIS field is always required:
compInfo currency-code emailInfo email-address email-type employmentInfo end-date start-date globalAssignmentInfo company end-date assignment-type planned-end-date imInfo im-id jobInfo job-code company business-unit jobRelationsInfo relationship-type rel-user-id nationalIdCard card-type national-id isPrimary country payComponentNonRecurring pay-component-code value pay-date payComponentRecurring pay-component frequency paycompvalue pensionPayoutsInfo company end-date personalInfo first-name last-name personRelationshipInfo relationship-type phoneInfo phone-type phone-number workPermitInfo issue-date
For this HRIS element in the country-specific Succession Data Model... ...this HRIS field is always required:
globalInfo country
homeAddress country
Labels
The label is the descriptor that appears on the UI. You can change this label by overwriting it with a name that the customer prefers.
In the following example, the value of the <label> tag of the HRIS element is the descriptor for the foundation object
“location”:
<hris-element id=”location”> <label>Location</label> ...
In the following example, the value of the <label> tag of the HRIS field is the descriptor for the field “externalCode”: <hris-element id=”location”>
<label>Location</label>
<hris-field max-length=”32” id=”externalCode” visibility=”both” required=”true” /> <label>Code</label>
...
Translatability of labels
The label is the descriptor that appears on the UI. You can change this label. It can also be translated into other languages using the xml:lang attribute and the corresponding language code. The corresponding translations are
stored in the XML file for the data model as shown below:
<hris-element id=”company”> <label>Legal Entity</label>
<hris-field max-length=”32” id=”externalCode” visibility=”both” required=”true” pii=”false”>
<label>Legal Entity ID</label>
<label xml:lang="de-DE">Kennung der juristischen Einheit</label> <label xml:lang="en-GB">Legal Entity ID</label>
<label xml:lang="es-ES">ID de entidad legal</label> <label xml:lang="fr-CA">ID d’entité juridique</label> <label xml:lang="fr-FR">ID de la personne morale</label> <label xml:lang="it-IT">ID entità legale</label>
</hris-field> </hris-element>
If the system does not find a corresponding label for the system language, it displays the label that has been configured without the xml:lang attribute; in the example above, “Legal Entity ID” would then be displayed.
Effective Dating
The HRIS fields “start-date” and “end-date” are used for effective dating. The “start-date” is mostly shown on top of all other fields on the UI. This is where the user has to enter the date when he wants the changes to be effective. Whether an HRIS element is effective-dated or not is defined by the system.
The HRIS field “end-date” does not appear on the UI but is used for reporting purposes. For example, if you change an effective-dated field such as pay grade and set the date when the change should be effective to 01/01/2012, the system records 12/31/2011 as the end date in the background. If you run a report on the pay grade in the time from 01/01/2011 until 12/31/2011, the pay grade value that was valid in that time frame will be shown.
This is what the XML code looks like for start and end date:
<hris-field id=”start-date” visibility=”both” required=”true” pii=”false”> <label>Start Date</label>
</hris-field>
<hris-field id=”end-date” visibility=”none” required=”false” pii=”false”> <label>End Date</label>
</hris-field>
Search criteria
You can define search criteria that are used to find an entry in the system. In the following example, you define that you can search for a location by entering a city or a country. The system then tries to find a match with the information stored in the corporate address and shows the corresponding result.
<hris-element id=”location”> <search-criteria> <search-field id=”corporateAddress.city” /> <search-field id=”corporateAddress.country” /> </search-criteria> </hris-element>
List of XML elements and attributes
The following tables provide a quick overview of the XML elements and attributes that are most commonly used in the data models.
● XML elements can contain other XML elements nested inside them. For example, the hris-element XML element can contain label and hris-field XML elements:
<hris-element id=”location”> <label>Location</label>
<hris-field max-length="32" id="externalCode" visibility="both" required="true" pii="false" showTrailingZeros="false" >
<label>Code</label> </hris-field>
<hris-associations>
<association id=”id” multiplicity=”ONE_TO_ONE” destination-entity=”geozone” required=”false” /> </hris-associations> <search-criteria> <search-field id=”corporateAddress.city” /> </search-criteria> </hris-element>
● XML elements can contain several attributes, for example, the XML element hris-field contains the
attributes max-length and id:
<hris-field max-length=”256” id=”amount”>
● Attributes are name-value pairs; it is predefined which values can be entered for which attributes. In the following example, the attribute with the name max-length can have a number as value: max-length=”256”
<hris-element>
...can include these XML elements
or attributes: How to use this XML element or attribute:
Attribute id This is the identifier for an HRIS element, which represents one foundation object, or
one person or employment object.
You cannot change the ID; to find out which data object has which ID, refer to the hris-element id of the data object tables:
● Foundation object tables [page 203]
● Person object tables [page 240]
● Employment object tables [page 255]
Element description This is where you enter a text that describes an XML element, or what the data model
is used for, for example. This description does not appear on the UI.
Element label This is the text that is shown on the UI. You can change it if the customer wants to use
a different naming. This text is also translatable.
Element trigger-rule This is used to assign a configurable rule the customer has created to a user action on
the user interface. For example, when a page is loaded or saved, a specific system behavior defined in the configurable rule is triggered.
For more information, see Setting up configurable rules [page 105].
Element hris-field With hris-field you define each individual field within this HRIS element.
Element
hris-associations
Associations define the relationship between foundation objects. Associations can only be defined in the Corporate Data Model.
Element
search-criteria
Search criteria define what fields can be used to search this HRIS element.
<hris-field>
...can include these XML elements or attributes:
These are possible attribute
values: How to use this XML element or attribute:
Attribute max-length 256 This defines the maximum length of this field on the UI.
For boolean fields, you can leave out this attribute.
Attribute id start-date This is the identifier for a field within an HRIS element.
You cannot change the ID; to find out which HRIS field has which ID, refer to the column Field ID in the data object tables:
● Foundation object tables [page 203]
● Person object tables [page 240]
● Employment object tables [page 255]
Attribute visibility ● none
● view
● both
The visibility defines if this field is visible on the UI:
● “none”: Field is hidden. You cannot import data for
this field via CSV files.
● “view”: Field is read-only. You cannot import data for
this field via CSV files.
● “both”: Field is visible on the UI and can be edited
Attribute required ● true
● false
If this is set to “true”, the field becomes mandatory — that
means a user entry is required — and is marked as such on the UI.
...can include these XML elements or attributes:
These are possible attribute
values: How to use this XML element or attribute:
Attribute pii ● true
● false
If this setting is true (pii=”true”), it defines that the field
is a sensitive field; as such, it will be masked on the screen for security reasons. This is a setting used for password fields, for example. When the user enters his data, only asterisks or similar symbols are shown on the UI instead of the actual data entered. This is done to prevent over-the-shoulder snooping for the user's password.
Attribute maximumFractionDigits Possible values
are 0–5: ● 0 ● 1 ● 2 ● 3 ● 4 ● 5
With this XML attribute you define how many decimal digits are shown after the decimal point. Depending on the number of decimal digits you indicate here, the numbers displayed in the system get rounded up or down.
You can use this property only for HRIS fields with the data type DOUBLE, and you can define up to 5 decimal places. If you do not use this attribute for a DOUBLE data type, the number is rounded to three decimal places by default. If you define a value higher than 5, the system uses the maximum value, which is 5. If you define a negative value, for example, -1, the default value of 3 decimal places is used. Example:
maximumFractionDigits=”2”
If the user enters 4.394 on the UI and the
maximumFractionDigits have been defined to 2, the
system reduces the decimal digits from 3 to 2 as defined in the data model and rounds down the value to show the following: 4.39
Make sure that the following HRIS fields use the same
maximumFractionDigits value:
● payComponentValue of HRIS element payComponent
● paycompvalue of HRIS element payComponentRecurring
● value of HRIS element
payComponentNonRecurring
The pay component value field of the pay component foundation object is reused in the compensation information. If you then choose to override this field
and the value of the maximumFractionDigits
attribute is different for the fields, it leads to an error.
Attribute showTrailingZeros ● true
● false
With this XML attribute you define if trailing zeros after a decimal number are displayed, and how many. You can use this attribute only for HRIS fields with the data type DOUBLE. If you do not use this attribute for a DOUBLE data type in the XML file, by default no trailing zeros are shown.
If maximumFractionDigits is set to 4 and
showTrailingZeros is set to “true”, and the user enters
1.3 on the UI, the value is displayed as follows: 1.3000.
Element label — This is the text that is shown on the UI. You can change it if the
customer wants to use a different naming. This text is also translatable.
...can include these XML elements or attributes:
These are possible attribute
values: How to use this XML element or attribute:
Element trigger-rule — This is used to assign rules the customer has created in the
Rules Engine to a user action on the user interface. When a field is changed, a specific system behavior defined in the rule is triggered.
For more information, see:
● Setting up configurable rules [page 105]
● How do you set up alerts and notifications? [page 133]
Element picklist — If the value of this HRIS field comes from a picklist, define the
associated picklist information.
You can find more information about picklists in How do you manage picklists?
<hris-associations> (only valid for Corporate Data Model)
...can include these XML elements or
attributes: These are possible attribute values: How to use this XML element orattribute:
Element association — Associations define relationships
between foundation objects, or between a foundation object and a generic object.
Attribute id The only possible value is:
id
This is the identifier for an association between this foundation object and another object; do not change this value.
Attribute multiplicity ● ONE_TO_ONE
● ONE_TO_MANY
Multiplicity defines whether this relationship is ONE_TO_ONE or ONE_TO_MANY. If you create new associations, define the multiplicity as ONE_TO_MANY.
Attribute destination-entity ● division
● company
● Generic_Object_Building
This is where you define the other foundation object or generic object that this object has a relationship with. You enter the HRIS-element ID of that foundation object or the external code of the generic object as attribute value. The destination entity is the controlling object of the association.
Attribute required ● true
● false
If this is set to “true”, the field
becomes mandatory — that means a user entry is required — and is marked as such on the UI. <search-criteria>
...can include these XML elements or
attributes: How to use this XML element or attribute:
Element search-field This defines a searchable field of this HRIS element.
You can define search criteria that are used to find an entry in the system. In the following example, you define that you can search for a location by entering a city or a country. The system then tries to find a match with the information stored in the corporate address and shows the corresponding result.
...can include these XML elements or
attributes: How to use this XML element or attribute:
Attribute id This is the ID that the system is searching for. You use the HRIS-element ID
followed by the HRIS-field ID, separated by a period. <label>
...can include these XML
elements or attributes: These are possibleattribute values: How to use this XML element or attribute:
Attribute xml:lang ● en-GB
● fr-CA
● it-IT
The label that appears on the UI can also be translated into other languages
using the xml:lang attribute and the corresponding language code. The
corresponding translations are stored in the XML file for the data model. If the system does not find a corresponding label for the system language, it
displays the label that has been configured without the xml:lang attribute;
in the example, Legal Entity ID would then be displayed.
<trigger-rule>
...can include these XML elements or
attributes: These are possibleattribute values: How to use this XML element or attribute:
Attribute event For hris-elements:
● onInit ● onSave ● onView ● onEdit ● saveAlert For hris-fields: ● onChange
This is the event on the user interface that triggers the execution of the rule. Possible values are:
● onInit: Rule is triggered when the page is loaded
● onSave: Rule is triggered when a page or HRIS-element is saved
● onChange: Rule is triggered when a field is changed.
● onView: Rule is triggered when portlet or page with transient field
is loaded
● onEdit: Rule is triggered when portlet or page is opened in edit
mode
● saveAlert: Rule is triggered when a data record change has
taken place and the current date is equal or after the effective date of the defined alert
For more information, see:
● Setting up configurable rules [page 105]
● How do you set up alerts and notifications? [page 133]
Attribute rule external code of the rule This is the rule that is triggered when the event on the user interface takes
place. You must have defined this rule in the Rules Engine and refer to the external code of the rule.
4.2 Setting up the Corporate Data Model
What is the Corporate Data Model?
The Corporate Data Model is your starting point to set up a company's structure for Employee Central. This is where you define how the organization, pay and job structures that define the company are reflected in the system. For example, if a company's departments can be funded by several cost centers, you allow that more than one cost center can be assigned to a department in the system. You set this up by defining foundation objects in the Corporate Data Model and define the relationships between them by creating associations in the XML file for the data model. Only the foundation objects defined in this data model can later be used in Employee Central, and the associations define what a user can enter. You also define what fields are going to be used on the UI, what they are called, which fields are hidden, and you can also add customer-specific fields.