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.
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. You find more information about foundation objects in What are foundation objects?
[page 78]
In the XML file for the Corporate Data Model, you can make changes to the standard setup that is predelivered by SuccessFactors. The following table lists all foundation objects that are included in the standard XML file. The columns define the following:
● HRIS-element ID: This is the ID that is used to identify the foundation object in the XML files.
● Standard label: This is the label for the HRIS element that appears on the UI. You can overwrite this label. If no label is included in the standard XML file, then the label that appears on the UI is pulled from the backend system. To overwrite the label, add the corresponding label tags in the XML file below the corresponding HRIS element and put the new label text inside the label tags.
● Subtype: Foundation objects can be logically divided into four main areas:
○ Organization structures
○ Job structures
○ Pay structures
○ Other objects, such as event reasons, workflow, and dynamic roles
The fields for the foundation objects legalEntityLocal and jobClassLocal are defined in the country-specific Corporate Data Model. For more information, see Setting up country-country-specific data models
[page 69].
HRIS-element ID Standard label Data object type Subtype
company Legal Entity Foundation object
This is the only mandatory HRIS element you should not delete from the XML files.
Organization structure
legalEntityLocal — Foundation object
All fields for this HRIS element are set up in the country-specific Corporate Data Model.
Organization structure
businessUnit Business Unit Foundation object Organization structure
locationGroup Location Group Foundation object Organization structure
geozone Geo Zone Foundation object Organization structure
location Location Foundation object Organization structure
division Division Foundation object Organization structure
department Department Foundation object Organization structure
costCenter Cost Center Foundation object Organization structure
jobCode Job Classification Foundation object Job structure
jobClassLocal — Foundation object
All fields for this HRIS element are set up in the country-specific Corporate Data Model.
Job structure
jobFunction Job Function Foundation object Job structure
payGroup Pay Group Foundation object Pay structure
payRange Pay Range Foundation object Pay structure
payGrade Pay Grade Foundation object Pay structure
payComponent Pay Component Foundation object Pay structure
HRIS-element ID Standard label Data object type Subtype
payComponentGroup Pay Component Group Foundation object Pay structure
payCalendar Pay Calendar Foundation object Pay structure
frequency Frequency Foundation object Pay structure
corporateAddress — Part of foundation object location Organization structure
dynamicRole Dynamic Role Foundation object Dynamic Role
dynamicRoleAssignment — Part of foundation object dynamicRole Dynamic Role
wfConfig Workflow Foundation object Workflow
wfConfigStep — Part of foundation object wfConfig Workflow
wfStepApprover — Part of foundation object wfConfig Workflow
wfConfigContributor Contributor Type Part of foundation object wfConfig Workflow wfConfigCC CC Role Type Part of foundation object wfConfig Workflow
eventReason Event Reason Foundation object Event reason
Can you add more foundation objects?
In addition to the foundation objects listed above that SuccessFactors predelivers, you can define more foundation objects specific for your customer. For more information, see How do you create customer-specific foundation objects? [page 90]
What are associations?
Associations define relationships between foundation objects, or between a foundation object and a generic object.
For example, a business unit consists of several departments, so you would create an association of one business unit to many departments — a ONE_TO_MANY association. Whereas a location can only have one geozone associated to it — this is a ONE_TO_ONE association. The type of association restricts what the user can display or enter in Employee Central — for a ONE_TO_ONE association from location to geozone, for example, the user can enter exactly one geozone for a location on the UI.
The standard XML file for the Corporate Data Model already contains some associations. These are listed in the table below. You can add more ONE_TO_MANY associations, or change the existing associations in the XML file if needed.
Each association has a “driving object” that acts as the basis for the association.
Source Target Multiplicity Description
Location Geozone ONE_TO_ONE A location can only belong to one geozone. (Location is the driving object)
Location Legal Entity ONE_TO_MANY Several companies can have the same location. (Legal Entity is the driving object)
Division Business Unit ONE_TO_MANY A division can have several business units. (Division is the driving object)
Department Division ONE_TO_MANY A department can have multiple divisions. (Division is the driving object)
Job Code Business Unit ONE_TO_MANY A job code can be used across several business units. (Job Code is the driving object)
Pay Range Geozone ONE_TO_ONE Companies generally have different pay ranges for each combination of Legal Entity, Job Code, and Geozone.
Pay Range Pay Grade ONE_TO_ONE A pay range is generally associated with one pay grade.
Source Target Multiplicity Description
Pay Range Legal Entity ONE_TO_ONE Companies generally have different pay ranges for each combination of Legal Entity, Job Code, and Geozone.
Pay Component Group Pay Component ONE_TO_MANY A Pay Component Group can contain multiple Pay Components.
How do you set up the Corporate Data Model?
1. Download the XML file for the Corporate Data Model.
● If you're setting up the Corporate Data Model the first time for a company, download the most current version from this link: http://
confluence.successfactors.com/display/PRODINFO/Data+Models+and +Picklists .
● If you're changing an already uploaded Corporate Data Model, download the XML file from Provisioning under Succession Management Import/Export Corporate Data Model XML .
2. If no changes are required to the XML file, you can proceed directly to step 3. Otherwise, open the XML file in an XML editor and adjust the data model according to the company's requirements you have discussed with the customer before.
If you want to adjust the XML file, proceed as follows:
1. HRIS elements
You can change the following for the HRIS elements:
● Delete HRIS elements
Except for company, which is a mandatory HRIS element, you can delete the HRIS element you don't want to use from the data model.
Interaction between data models:
Consider the interaction between the data models when you delete HRIS elements that might be used in some other data model. Some of the foundation objects defined in the Corporate Data Model are used to fill fields that are part of person or employment objects defined in the Succession Data Model. For example, when you delete the costCenter HRIS element from the Corporate Data Model, you should also delete the cost-center field from the Succession Data Model (which belongs to HRIS element jobInfo), or set its visibility to
“none”, so it does not appear on the UI. Otherwise, when the user selects the cost-center field in the Job Information portlet on the UI, no information can be entered in this field.
The same applies to the following fields:
HRIS element in Corporate Data Model
HRIS field in Succession Data
Model HRIS element in Succession Data Model
company company jobInfo
businessUnit business-unit jobInfo
HRIS element in Corporate Data Model
HRIS field in Succession Data
Model HRIS element in Succession Data Model ● Change the label for HRIS elements
If you want to use a different label text on the UI, overwrite the existing label text of the corresponding HRIS element or, if there is no label included in the standard XML file, insert a label with the corresponding text.
2. HRIS fields
You can change the following for HRIS fields:
● Hide or show fields on the UI by setting the visibility attribute accordingly For example, set the visibility of HRIS fields the customer does not want to use to “none”, so they don't appear on the UI and no data import is possible.
● Change labels for HRIS fields by overwriting the existing label text
● Make fields mandatory by setting the required attribute to “true”
● Mask data entry on screen by including the pii attribute
● Configure custom fields 3. Search criteria
You can add search criteria to a field by adding the <search-criteria> element to an HRIS element.
4. Associations
To define relationships between foundation objects, or between a foundation object and a generic object, set up new associations or change the associations included in the standard XML file. The associations are included before the HRIS element end tag and define whether it is a ONE_TO_ONE or a ONE_TO_MANY association. For more information, see below under “How do you define associations?”
The HRIS field costCenter is part of the HRIS element department and as such behaves to it like a one-to-one association, even if there is no such association defined in the XML file. If you want to change this, set the visibility attribute value of costCenter to “none” and create an association (for example, to allow many cost centers for one department, you set up a one-to-many association from department to cost center).
For more information on the XML elements, attributes and their possible values, see What are data models? [page 30]
3. Upload the Corporate Data Model in Provisioning under Succession Management Import/Export Corporate Data Model XML .
What are the next steps?
The company's Admin can now create specific foundation objects in the system one by one, or mass upload data. You might have to show the Admin where this can be done in the system:
● To create single foundation objects, such as departments, business units, and so on, go to Administration Tools. In the Company Processes & Cycles portlet, select Employee Files Manage Organization, Pay and Job Structures .
● To mass upload foundation object data via CSV file, go to Administration Tools. In the Company Processes & Cycles portlet, select Employee Files Import Foundation Data .
XML examples
How is a foundation object defined in the XML file?
This is an example how the foundation object “location” is defined in the Corporate Data Model:
<hris-element id=”location”>
<label>Location</label>
<hris-field max-length=”32” id=”externalCode” visibility=”both” required=”true” />
<label>Code</label>
In the XML file for the Corporate Data Model, the HRIS element defines a foundation object. Each foundation object has an ID you should not change, in this example, “location”. The label name can deviate from the ID. This is the label shown on the UI. The field associated with “location” is “externalCode”. You can change the labels of the field and the HRIS element.
Below, you can find search criteria for the location. In this example, if the user searches for existing locations, and enters a city or country name, the system searches the entries of the fields “city” and “country” of the HRIS element
“corporateAddress”, which is also defined in the Corporate Data Model, for a match.
How do you define associations?
One-to-many association
Let's assume the company “ACE Services” has the locations “Chicago” and “Dallas”. This is a ONE_TO_MANY association from the company to the location:
<hris-element id=”company”>
...
<hris-associations>
<association id=”id” multiplicity=”ONE_TO_MANY” destination-entity=”location” />
</hris-associations>
</hris-element>
For the destination-entity, enter the HRIS-element ID of the foundation object, or the external code of the generic object you want to associate the foundation object with.
You can only define ONE_TO_MANY, but not MANY_TO_ONE associations. See the following example:
Two companies, “ACE Software” and “ACE Corporation”, have the same location: “Philadelphia”. Logically, this would be a MANY_TO_ONE relationship from the companies to the location. However, as only
ONE_TO_MANY associations are possible, this would need to be configured as a one-to-many association from location to the company. Once this association has been defined, the legal entities can be attached to the location in Employee Central when setting up the legal entities on the UI. You do this under Administration Tools. In the Company Processes & Cycles portlet, select Employee Files Manage Organization, Pay and Job Structures .
The following example shows the ONE_TO_ONE associations from payRange to the foundation objects geozone, payGrade and company.
Do not create more ONE_TO_ONE associations to those that are predelivered in the standard XML file.
<hris-element id=”payRange”>
...
<hris-associations>
<association id=”id” multiplicity=”ONE_TO_ONE” destination-entity=”geozone” />
<association id=”id” multiplicity=”ONE_TO_ONE” destination-entity=”payGrade” />
<association id=”id” multiplicity=”ONE_TO_ONE” destination-entity=”company” />
</hris-associations>
</hris-element>