Integrating MDF and Master Data (FO/GOs)

For the administrators who will work with GOs, enable the following options from Admin Center→Manage Permission Roles→Administrator Permissions:

• Metadata Framework: Configure Object Definitions, Manage Data, and Read/Write Permissions on Metadata Framework. Additional options can be selected as well.
• MDF Foundation Objects: Select all options for Department and Division except for Field Level Overrides. These permissions are required in order to add and edit data for the Generic Objects and to use the GOs on a job requisition. See additional details under Object Level Permissions.

The Division and Department GOs exist in the system as soon as they are enabled. View these objects from Admin Center→Configure Object Definitions.

Associations define a hierarchical relationship between two objects. Without associations, all objects are on the same level. The relationship between objects can be One-to-Many or One-to-One.

• One to Many relationship – A Division consists of several Departments, so you create an association of one Division to many Departments
• One to One relationship – A Location can only have one geozone associated with it

There are two types of associations:

• Valid When Associations allow data for objects to be connected, but leave the objects as separate entities. This is often used in Foundation Object relationships to create filtering capabilities between records. For Valid When associations, the associated object has its own lifecycle and exists even without the object that is being defined.
• Composite Associations create a parent-child relationship between two objects. For this association type, the entity being associated is a child entity that does not exist outside the parent object that you are defining. If an object is referred as a composite child in an object, it cannot be used as a top-level object, and records cannot be created separately for the child object.

For our Division and Department use case, use a Valid When Association. Associations are configured from the child object, which is the Department. Navigate to Department from Configure Object Definitions.

From the right side of the page, from the Take Action list, select Make Correction:

Scroll down to Associations.

Start typing in the second line, which contains the text: cust_. Enter the following information:

• Name = cust_to_division. (Note that "Name" is actually the "ID", not the label.)
• Multiplicity = One to Many.
• Destination Object = Division.
• Type = Valid When.
• Choose the Details link.
• Label = Division.

Save both the Details and the Object.

If you change an association, you will receive the following message, also shown in the screenshot below:

You have renamed the association [cust_toDivision]. This may cause reference loss in rules/RBP /Configurable UI screen definitions. Please update those references manually. Click yes to save.

To resolve this, do an OData Refresh. Do the refresh for similar types of changes, for example, if you add a new field to the job requisition template that impacts business rules.

From Admin Center→OData API Metadata Refresh and Export:

Use Manage Data to populate the Divisions field. This may be referred to as Divisions data or instances.

For this use case, create the following structure: three Divisions and five Departments:

Navigate to Admin Center→Manage Data.

Search on Division and from the second list notice that no records are found.

From Create New at the right side of the page, use typeahead to select Division.

Enter the following:

• Effective as of: 01/01/1900.
• Code: Operations.
• Name: Operations.
• Status: Active.

Save the Division data.

Create the other two Divisions in the same way: Corporate and Sales.

As you create the five Departments required for our customer, associate them to the three Divisions.

From Admin Center→Manage Data, choose Create New and select Department.

Enter the following:

• Effective as of: 01/01/1900.
• Code: Engineering.
• Name: Engineering.
• Status: Active.
• Division: Operations.

Save the Department data.

Create the other four Departments in the same way: Human Resources, Staffing, Finance, and Sales. Associate them with the Divisions listed.

The FO/GO type standard fields for Division, Department, and Location are not a replacement of the existing Division, Department, and Location non-FO/GO type standard fields on the Job Requisition and Offer. Both types of fields co-exist until one of them is explicitly disabled. In this part of the use case, add the GO field types for Division and Department to our job requisition template, and remove the non-GO field types for those fields. Additional steps will be performed later to use the GO versions of these field types.

There are six new standard FO/GO type fields available for the requisition, listed below.

Generic Objects:

• Legal Entity: legalEntity_obj
• Business Unit: businessUnit_obj
• Department: department_obj
• Division: division_obj
• Cost Center: costCenter_obj

Foundation Object: Location: location_obj

This is how the field id and object are defined for Division and Department on the JRDM:

There are two tags available in field-criteria:

• sourceFieldName
• destinationFieldValue

The sourceFieldName is the name of the association configured in MDF: cust_to_division plus ".internalId". For example, the sourceFieldName = cust_to_division.internalId.

The destinationFieldValue is the field ID of the parent field as defined on the JRDM. For example, the destinationFieldValue = division_obj.

Remember to remove the original, derived, Division and Department fields and permissions from the job requisition template and add the permissions for the new GO fields.

The following types of permissions for the job requisition are available:

• Template role permissions
• Object level permissions
• Target population

These permissions are executed in a specific sequence. At any point in time, if one of these permissions fail, the next set of permission are not executed.

Template role permissions are set, as always, to determine the read or write access that an operator has to a field on the job requisition. Valid requisition states include pre-approved, approved, and closed. If the required template role permissions are not defined, you will not see the field.

The example from the use case where the Recruiter can edit the Division and Department GO fields when the requisition is in the pre-approved status:

Remember to set read and write permissions for the new GO field types for all operators and all requisition statuses on the job requisition.

To use FO/GOs on a job requisition, you must first grant permission for each object. There are several permissions that can be granted to an object:

View/View Current – If you do not select this permission, the field label will be visible on the UI (requisition form), but the input field associated with it will not be visible. When the View Current permission is granted, clicking the business card next to the field will bring up a pop-up displaying information about the object.

Create – Granting the Create permission to an object displays the option to create a new object instance (data). Once the Create permission has been granted, a create icon is displayed next to the input field associated with the object. Click this icon to create a new instance (data) for this object.

Correct/Delete – Granting the Correct/Delete permission to an object displays an option to edit and manage an object. From the business card, click Edit to make the changes to the object instance from the same page, or click Manage to view the data on the Manage Data page. You can also go directly to the Manage Data page to edit the data.

Earlier in the use case, you set these permissions for the admin users from Role-Based Permissions.

Object level permissions also need to be set for any users who will create or edit job requisitions, so for our use case, that’s all hiring managers and members of the staffing department. This allows the users to see the field. Remember that permission to read or write is granted in the job requisition.

After you have defined permissions for the FO/GOs, the next step is to define the target population of users who will have access to the object. This is part of Role-Based Permissions, not specific to Recruiting. For the use case you don’t need to do this step.

Log in to SAP SuccessFactors HCM and navigate to Recruiting as a user who has permissions to create and edit job requisitions and FO/GO fields.

Create or open a requisition form.

Ensure that:

• You are able to populate the new Division and Department fields.
• The fields are correctly associated with each other (for example, if Operations is selected for Division, the only option for Department is Engineering).
• The user can choose the business card to access the Edit and Manage options.

Options from Manage Recruiting Settings control the visibility of fields on the Job Requisition Summary page, using Display Options and Filter Options.

These settings also control the visibility of the fields in the following scenarios:

• Manage Recruiting E-Mail Template
• Manage Offer Letter Template tokens

From Admin Center→Manage Recruiting Settings, select the following to enable the FO/GO fields:

Also make the following change to disable the standard fields:

The standard FO/GO fields can also be used as filters (career search) fields. Select the desired fields from Admin Center→Internal and External Career Search Settings, and clear the derived fields.

Result:

All six of the FO/GO fields defined on the job requisition template and offer template are readily available to be used as tokens; no configuration is necessary.

The primary use case for using FO/GOs is to allow for the reuse of data defined in MDF for Recruiting. Without EC enabled, the other modules, including the Employee Profile/People Profile, do not use FO/GO values, such as Division and Department. On a non-EC instance, these field values will still be derived from the User Data File (UDF)

Refer to the Implementation Guide: Implementing HR Master Data Sync for Foundation Object and Generic Object Fields in Recruiting.