Introducing Foundation Objects

SAP SuccessFactors Employee Central has a fundamental corporate and employee data structure. Corporate data includes information about the company's organization, pay, and job structures. The data is organized in different data tables or objects. Objects that hold company-specific data are called Foundation Objects. Foundation objects are built before any employee data can be added to the system. Employee Central comes with standard predelivered foundation objects which can be customized to meet the customer requirements.

Foundation objects are either XML-based or MDF-based.

XML-based Foundation Object (also called Legacy) structures are contained in Corporate Data Model and Country-Specific Corporate Data Model. Both data models can be exported and imported from the Admin Center.

MDF-based (Metadata Framework) Foundation Object structures are directly configured in the Configure Object Definition tool without XML intervention.

In the image below, the lists of standard Foundation Objects are categorized into organization-related, pay-related, job-related, and others. It is also color-coded to indicate if the object is XML-based (orange) or MDF-based (blue).

For administrators to manage Foundation Objects, make sure permissions in the following permissions categories are selected:

• Manage Foundation Objects
• Manage Foundation Object Types
• MDF Foundation Objects

The standard Foundation Objects predelivered by SAP SuccessFactors are customizable. However, some customer requirements may be too complex for the standard objects. Custom generic objects can be created using Metadata Framework to support additional business processes.

These custom objects can maintain and store additional information and attributes for the company and people in the organization. For example, a customer that needs to add more hierarchy levels in the organization than SuccessFactors can deliver will create a custom object to provide an accurate representation of their organization in Employee Central.

Custom objects are configured with these common characteristics:

• It may or may not be effectively dated.
• It may or may not be secured.
• It may or may not be associated with another object.
• It may or may not be available for self-service.

To learn more about creating custom generic objects, visit the Explore the SAP SuccessFactors Platform course.

This is the company or legal entity where the employee is hired and has their contract of employment. A legal entity represents a company as registered against country laws. It cannot span across more than one country. The country assigned to the legal entity controls the country-specific data which is available on the employee's Job Information, Employment Details, and Compensation Information.

The legal entity in SAP SuccessFactors Employee Central is a one-to-one mapping with the company code in ECP/SAP HCM/S4. In Employee Central, the legal entity assigned to the Position object must be the same as the legal entity in Job information. In SAP SuccessFactors, the legal entity is the highest object that can be used in the organization hierarchy.

In the figure below, the fields below the Country field are specific to the United States. Country-specific fields will differ based on the country selected for that legal entity.

Business Unit is the Business area of the company, representing one operating unit or the business function or line of business within the Company (not geographical).

Division is a level of organization hierarchy lower than the Business Unit. It is a subdivision of the business function. In Employee Central, the Division object comes with a standard Parent Division field, which allows for hierarchical levels among the division records. Using associations, you can link a division to one or more business units. In this example, the Healthcare Division is associated to the Corporate Healthcare business unit.

A department has similar properties to a division. A department stores information for all departments within a company. You can create a hierarchy using the Parent Department field. You can also create an association between departments and divisions. In this example, the Sales Department is associated to two divisions: Industries and Enterprises.

The Location object stores the address information of all physical offices for a company where the employee works. Using associations, a location can be linked to a geo zone and legal entities. International address formats are supported and defined in the Business Address (Corporate Address) in the Country-Specific Corporate Data Model.

Location group is used for geographical grouping of multiple locations. This is optional. For example, Location Group West Coast contains several locations, including the San Mateo Office, San Diego Office, and so on. Location groups are primarily used for EEO reporting in the USA.

You can group multiple locations into one Geo Zone. For example, Geo Zone North America, Western Region contain business locations in San Mateo, San Diego, and so on. Geo Zone includes an Adjustment Percentage field, which allows the pay range to be adjusted based on the cost of living. For example, a company can decide to adjust the pay for employees on the West Coast by 15%.

Job Classification stores all job codes and associated information for a company. Common fields include the following: Supervisor Level, Job Level, Regular/Temporary, Full/Part-Time, Employee Class, Job Title, and Pay Grade. You can also have country-specific fields for Job Classification.

Several job classifications can share the same Job Function. For example, the Job Classification: Developer and Job Classification: Developer Manager belong to the Job Function: Engineering (ENG).

You can group employees who share the same payroll into one Pay Group. In the figure below, the instance is set up to the group by region, North America. Pay Group is primarily used for payroll-related activities.

You can decide the Pay Range for employees. In the figure below, Pay Range defines that the Minimum Pay, Maximum Pay, and Mid-Point are $120,000, $129,999, and $124,999.50, respectively, if the employee meets the following requirements:

• Geo Zone is set as North America, Western Region (NA_WEST).

• Pay Grade is set as Salary Grade 12 (GR-12).

• The Legal Entity is set as Ace USA (ACE_USA).

Pay Range is primarily used for the calculation of compa-ratio and range penetration. You can define as many pay ranges as needed.

The Pay Component FO stores all information about how the company pays an employee, such as base salary, bonus target, car allowance, and so on. For each pay component, you can define the following:

• Recurring (frequency) or one time pay

• Amount as percentage or value

• Earning or deduction

• Actual pay or a target

• Visibility for managers on Manager Self-Service

• Used in Comp Planning

• Taxable

You can group multiple pay components into one Pay Component Group. The amount of a Pay Component is equal to the sum of the pay components it includes. The system automatically completes annualization and currency conversion during the calculation. For example, "AnnualizedSalary" is a Pay Component Group that has five pay components.

The Pay Calendar stores pay periods within a year. It is associated with a Pay Group.

Frequency defines how often a payout occurs for a Pay Component.

The final classification of Foundation Objects is referred to as "Other". These objects are maintained in the Corporate Data Model. They include Event Reasons, Workflow Configurations, and Dynamic Roles. To create records for these objects, use the Manage Organization, Pay, and Job Structures tool in the Admin Center. You will learn about these Other Foundation Objects in a later unit.

Associations enable you to define relationships between Foundation Objects and their records. The associations are built in the Foundation Object configurations, on the MDF object, or within the XML. Once the association is built, the records are linked together. The associations you see in your production environment are configured by your implementation consultants based on your business requirement.

Foundation data provides the underlying information for employee records. Any Foundation Object associations must also be aligned with the employee data. The choices that you see on the different lists will be restricted based on the relationships and hierarchies that were built. This makes it easier for the person working on the employee file to find the correct value and ensures the information complies with the defined hierarchy.

For example, ACE Corp has 30 locations worldwide. Only 13 of these locations are within the United States. The association between the legal entity and the Location object establishes the relationship between the records. The 13 US location records are connected to the United States legal entity (ACE_USA).

The relationship between the legal entity and location records must be aligned in the employee data structure. For example, when the employee is moved to Ace USA legal entity, only the 13 US locations will display as options, even though we have 30 active location records in the system.

In the figure below, you can see that the San Mateo office is linked to the ACE_USA legal entity. When you change an employee’s company to ACE_USA, you can only select a location associated with ACE_USA.

Foundation records are often used to propagate employee records using business rules to simplify data entry.

Using business rules, you can use the information in the foundation record to auto-populate fields in the employee files. For example, your company is hiring multiple employees with the same job classification. During the new hire process, the HR admin selects Job Classification: Engineer (ENG). A business rule can be configured to copy the information from the FO record to automatically fill in subordinate fields like Job Title, Pay Grade, Regular/Temporary, and so on, in Job Information.

Propagation makes it easier for HR administrators and managers to complete new hires or data changes to existing employees, without having to look up details like the standard pay range for certain job classifications. The propagation rules in your production environment are created by your implementation consultants specifically for your business need.

If fields are set as editable, the auto-populated values can still be overwritten.