Adding JRDM Field Types

Components of a requisition include the following elements:

• Instructional text: Used as a header and provides instruction

• Field label: Displays purpose

• Type: Data type of the field

• Required: Mandatory

When designing the requisition template, there are a variety of field types available for use. In this section, you see examples of the available fields with their XML.

In the figure below, you see examples of the field type, ‘text’:

• ‘Internal Job Title’ on the Job Requisition form, is shown at number 1.

• ‘Replacement for whom’ on the Job Requisition form, is shown at number 2.

In the figure below, ‘you see the following field types:

• The field type, ‘textarea’ on the ‘Internal Job Description, on the Job Requisition form, is shown at 1.

• The field type, ‘date’, which indicates ‘Job Start Date’ on the Job Requisition form, is shown at 2.

In the figure below, you see the following field types:

• The field type, ‘number’, which indicates the ‘Number of Positions’ on the Job Requisition form, is shown at 1.

• The field type, ‘currency’, which indicates 'Salary Min’ and ‘Salary Max’ on the Job Requisition form, is shown at 2.

In the figure below, bool and instruction, you see the following field types:

• The field type, bool, which shows the Veterans: Check this box option, is shown at 1.

• The field type, instruction, which provides instruction as to how to fill out the Competencies field on the Job Requisition form, is shown at 2.

The figures shown below are examples of how picklists display. They are shown in the figure with their XML:

• The Travel requirements picklist on the Job Requisition form, is shown at 1.

• The Function (filter field) picklist on the Job Requisition form, is shown at 2.

Multi-select picklists allow users to select more than one option from a picklist. This is most used when a customer is looking to open a job requisition for a position in multiple locations.

Configuring picklists has the following requirements:

• The Recruiting V2 Application is enabled.

• The job requisition is configured with XML.

• Labels and picklists for mfields are configured in Provisioning.

  

To add multi-select picklists to the XML of a job requisition, navigate to Provisioning→Managing Recruiting→Internal and External Applicant Search Settings.

Multi-select picklists are configured in Provisioning in the same manner as filter fields. Use the XML code shown in the figure above.

Please note that the same settings can be enabled via Admin Center→Internal and External Career Search Settings.

Use the Standard Field Guides to ascertain the field ID and field types for standard fields.

There is a guide for each of the following template types:

• Job Requisition Template

• Candidate Profile

• Application Template

  

Guides are available on the SAP SuccessFactors HCM Cloud Partner Services portal.

In addition to declaring and granting permissions for the standard country field, we can use it as a "switch".

Fields can be configured to display based on country.

You may need to configure US-centric fields for Equal Employment Opportunity (EEO) that refers to reporting gender, ethnicity, race and veteran status.

Configuration can be set so that these fields are presented to candidates applying to jobs in the US, but not in other countries.

The Candidate Data Model (CDM) is configured to display these fields to candidates applying to jobs in the US only.

The country of the job, the public attribute, and the applicant type (internal/external) play a part in who can see which fields on an application.

The figure, CDM Overrides, shows an example where the override specifies the following:

• The two job countries affected are US (United States) and CA (Canada).

• The fields display because they are configured as public="true".

  Note

  These fields would be set to public="false" when initially defined in the CDM.

• The fields can only be seen if the applicant is external and applying for a job in the US or Canada.

Therefore, if the applicant is internal, this override does not affect them, so they will not see these two fields on their application (field refid="AddlEmplHist" orfield refid="contactEmpl").

• The figure, External Applicant and Requisition Country Override Definition, shows the fields that would be displayed for external applicants applying for a job in the US.

  

The standard country field is very important.

A client who has jobs in multiple countries benefits from two country fields: one for the job and one for the job search.

Which fields display on the application can be controlled by the job country.

Foundation objects are used to set up data that can be shared across the entire company, such as Location. Foundation objects are contained and configured in the Corporate Data Model. Eventually all foundation objects are expected to be converted to generic objects.

Generic objects are used to store information and settings related to processes that allow you to work with people in the company more efficiently. Information like Org Structure, Position Management, and so on is included. Generic objects are created using the Metadata Framework.

SAP SuccessFactors' robust extensibility framework enables customers to extend HR cloud functionality to create company-specific objects that support their unique business processes, without the need to code. Some of these database objects can be leveraged for use in other SAP SuccessFactors HCM solutions, so they do not need to be duplicated and the field values stay in sync.

With MDF, you can create and manage database object definitions, object relationships, and object hierarchy. The object is like a container that contains a list of fields. The fields are the attributes. Up to 200 custom fields are supported.

Effective Dating is an important concept for MDF objects and data. It is possible to create a job requisition with fields of type foundation object/generic object whose values are currently inactive but will become active in the future. For example, a Hiring Manager can start the hiring process for a new Location that will become active on a future date.

MDF replaces XML-based configuration that can only be viewed and edited by those with Provisioning Access. All the tools used to manage MDF objects are within Admin Center. MDF is tightly integrated with the rules engine so that simple business logic can be used to set values for fields on requisitions and offers, trigger messages, perform calculations, and so on.

Customers can run reports on objects created in the Metadata Framework. Customers can import and export data from third-party systems. Company-specific objects created with MDF come with out-of-the-box support for OData REST APIs so that customers can quickly create new user interfaces (UIs) or integrate them into their existing UIs.

More information about MDF can be found on SAP Help Portal: https://help.sap.com.

The standard foundation object/generic object type fields available for use in Recruiting are as follows:

The figure, Foundation Objects and Generic Objects on a Job Requisition, is an example of foundation objects and generic objects on a job requisition.

Additional information about the use of foundation objects/generic objects in Recruiting Management is as follows:

• Foundation objects/generic objects are recommended for new implementations.

• Currently, foundation object/generic object field types are supported on the Job Requisition, Offer Approval, Candidate Profile and Application.

• Some object/generic object fields can be configured to use the multi-select attribute. For objects that are defined as multi-select, the type ahead feature is available for end-users to easily find the object value they wish to insert into the field upon completion.

• The foundation object/generic object field types can be maintained by using Manage Templates.

• The standard foundation objects/generic objects can be used as filter fields.

• Field values are available as tokens to be used in offer letters and emails.

• Fields are reportable in Ad Hoc reporting.

• Foundation objects/generic objects are available to the Rules Engine to be used with simple business logic.

• Foundation objects/generic objects used in Recruiting can be used to send data to Employee Central and Onboarding.

• Versioning, effective dating, and the ability to import and export foundation object/generic object data are all supported.

From Provisioning→Company Settings, enable the following settings:

• Role-Based Permission

• Enable Generic Objects

• Employee Central Foundation Objects

• Enable Employee Central Foundation Objects

• Include Job Classification Foundation Object Translations

For the administrators who will work with generic objects, 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 generic objects on a job requisition. See additional details under Object Level Permissions.

  

The Division and Department generic objects exist in the system as soon as they are enabled. View these objects from Admin Center→Configure Object Definitions. From Search, select Object Definition. You can use typeahead in the second field to locate Division or Department.

Note that additional fields can be added, if required by the customer.

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. For example, a Division consists of several Departments, so you create an association of one Division to many Departments; this is a One to Many relationship. A Location can only have one geozone associated with it; this is a One to One association.

The types of associations include the following:

• Valid When Associations allow data for objects to be connected, but leaves 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.

In the right side of the page, from the Take Action list, select Make Correction.

Scroll down to Associations. Note that the values displayed in Associations are default values.

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.)

• Mutiplicity = One to Many Destination

• Object = Division

• Type = Valid When

Click the Details link.

Scroll down and, in the Label field, enter Division.

Save both the Details and the Object.

If you change an association, you will receive a cautionary message.

To resolve this issue, 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, and then, in the Refresh Metadata Cache, select Refresh.

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

For our use case, we will 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.

In the Create New field on the right side of the page, use typeahead to select Division.

In the appropriate fields, enter the following information:

• Effective as of: 01/01/1900

• Code: Operations

• Name: Operations

• Status: Active

Save.

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

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

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

In the appropriate fields, enter the following information:

• Effective as of: 01/01/1900

• Code: Engineering

• Name: Engineering

• Status: Active

• Division: Operations

Save.

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

The foundation object/generic object type standard fields for Division, Department, and Location are not replacements of the existing Division, Department, and Location non-foundation object/generic object 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 our use case, we will add the generic object field types for Division and Department to our job requisition XML template (JRDM), and remove the non-generic object field types for those fields. Additional steps will be performed later to use the generic object versions of these field types.

The XML attribute object-type has been introduced to help define foundation object/generic object field types in the job requisition template (JRDM).

There are new standard foundation object/generic object type fields available for the requisition as follows:

The foundation object includes the following:

• Location: location_obj

The generic objects includes the following:

• Legal Entity: legalEntity_obj

• Business Unit: businessUnit_obj

• Department: department_obj

• Division: division_obj

• Cost Center: costCenter_obj

The figure, Field ID and Object, show how the field id and object are defined for Division and Department on the JRDM.

Notice that another new XML attribute "field-criteria" has been introduced for the job requisition template. The field criteria is defined from the child field to the parent, as described earlier. For example, if Division is the parent field and Department is the child field, the field criteria must be included in the Department definition.

The tags available in field-criteria are as follows:

• 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 our example, the destinationFieldValue = division_obj. Remember to remove the original, derived, Division and Department fields and permissions from the JRDM, and add the permissions for the new generic object fields.

To use foundation objects/generic objects on a job requisition, you must first grant permission for each object. The following permissions can be granted to an object:

• View Current

• View History

• Create

• Insert

• Correct

• Delete

• Import

• Export

View Current: Lets users see the currently effective record of an MDF Foundation Object. It is Read only, editing requires Correct/Insert/Delete permission.

View History: Lets users open the History/timeline to view past and future effective-dated slices for the object. It is Read only permission. Typically is combined with other edit permissions.

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.

Insert: The user can add a new effective-dated time version to an existing instance of that foundation object.

Correct: Lets users edit fields in the selected effective-dated slice withouth creating a new slice or changing its start date. Ideal for fixing typos or data error, workflows/rules may apply.

Delete: Removes Data. For effective-dated objects, it deletes the selected slice, if it's the only/first slice, the whole instance may be removed.

Import: Allows using Import and Export Data functionality to mass create or update MDF Foundation Objects records via CSV.

Export: Allows downloading current data for that object to CSV from the same tool.

See additional examples of object level permissions in Implementing HR Master Data Sync for Foundation Object and Generic Object Fields in Recruiting Management.

In the figure below, you see how we have set the permissions for the admin users earlier 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. Update the Create Recruiting Forms Role created to allow the users to see the field. Remember that permission to read or write is granted in the JRDM.

The types of permissions for the job requisition are as follows:

• 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 figure, Edit Generic Object Fields, illustrates, from the use case, where the recruiter can edit the Division and Department generic object fields when the requisition is in the pre-approved status.

Remember to set read and write permissions for the new generic object field types for all operators and all requisition statuses on the JRDM.

Import the updated JRDM in Provisioning in the prescribed manner.

After you have defined permissions for the foundation objects/generic objects, 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 this use case, you can skip 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 foundation object/generic object 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 click the business card to access the Edit and Manage options.

A location stores information regarding all physical locations of a company. One Location can belong to one Location Group and Geo Zone (both fields are foundation object types of the fields). One Location can belong to many Legal Entities. Location is a foundation object field type, so it must be defined in Corporate Data Model XML and information is updated in Manage Organizations, Pay and Job Structure section in Admin Center.

To add Location Foundation Object type to a job requisition, complete the following steps:

• a. Upload the Corporate Data Model XML to Provisioning.

• b. Upload the Country-Specific Corporate Data Model XML to Provisioning.

• c. Grant permission to manage Location Foundation Object field type in Admin Center.

• d. Create the Location Foundation Object field type in Admin Center.

• e. Update and upload the job requisition template to Provisioning.

• f. Review the Location Foundation Object field type on the job requisition.

The Corporate Data Model controls some of the corporate data (for example, location or location group) and is divided into several main areas: Organization, Pay, and Job Structures. It enables user to define what fields are labelled in the UI and which ones are visible and required.

Additionally, the Corporate Data Model can contain country-specific information. For example, your Location object may contain different address formats depending on the country. The latest version of the .xml file can be found on help.sap.com.

To upload CDM to Provisioning, navigate to Provisioning→Succession Management→Import/Export Corporate Data Model XML.

The Country Specific Data Model can be used to configure fields used for specific countries for foundation objects. Full Business Address, that is part of Location configuration in Admin Center is also managed via Country Specific Corporate Data Model. The latest version of xml file can be found at help.sap.com.

To upload country-specific CDM to Provisioning, navigate to Provisioning→Succession Management→Import/Export Country Specific XML for Corporate Data Model XML.

For the administrators who will work with foundation objects, enable the following option: navigate to Admin Center→Manage Permission Roles→Administrator Permissionand then navigate to Manage Foundation Object Types. Enable permission to create, insert, correct, delete information for Location. Additional permission can be enabled.

Even though location is defined in XML the information has to be created in Admin Center. Navigate to Admin Center→Manage Organizations, Pay and Job Structure→Create New and select Location.

Complete, at the minimum, the following fields:

• Effective as of

• Code

• Status – keep Active

• Country

Note that once the Country field is completed, additional information in Business Address section appears, which is dependent on information stored in Country Specific Corporate Data Model.

For the purpose of this training use case, complete the City field. Remember, that fields such as Location Group or Timezone are foundation object type fields so these need to be created same way as the Location Foundation Object field to be able to be used for Location field. For the purpose of this training use case, it does not have to be completed.

The job requisition template has to be updated with Location Foundation Object type of the field. Similar to generic objects, there is an attributes location_obj available.

Fields can be set up as multiselect fields using the attribute "multiselect=true". If a field is set up as multiselect, job imports can be used; however, only one value can be imported for the location field.

Make sure that user has proper permission given in all three system statuses (pre-approved, approved, and closed) to edit this field on job requisition.

Create a new job requisition and check if the location field is available and data is properly updated.

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 , in the Generic Object / Foundation (GO/FO) field types area, select the following to enable the foundation object/generic object fields, as illustrated in the figure below.

To disable the standard fields, in the Job Requisition area, select the Disable Department, Division, and Location filter options on Job Requisition Tab checkbox.

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

The figure, Foundation Object/Generic Object Fields as Filters, illustrates the results of the changes.

Recruiting users with admin privileges can define custom Metadata Framework objects and use them with the standard generic and foundation objects. This functionality brings organization data directly onto the candidate profile. The information can be then used with Business Rules.

Main features include the following:

• Support for field criteria (that is, defining hierarchical relationships between different objects)

• Support for searching for candidate by custom/standard object values

• Supported in OData API

SAP SuccessFactors Recruiting customers can leverage on the master data, defined either specifically for Recruiting and/or in any other solution in SAP SuccessFactors. This functionality improves the reusability and consistency of data.