Adding JRDM Field Types

Objectives

After completing this lesson, you will be able to:

  • Add standard and custom fields
  • Configure the country derived field for the application
  • Use foundation object (FO) and generic object (GO) fields in a job requisition template

Requisition Template and Fields

Learn about creating job requisition fields for job postings.

The requisition template holds information that assists in the hiring process. It also displays vital position data to managers, staffing personnel, and to candidates. The requisition fields are the building blocks of a requisition template. They are either standard or custom fields.

Standard Requisition Fields

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

JRDM Field Definitions

An important part of a recruiting implementation is the proper configuration of recruiting forms for your customer in their instance.

Discussing the available options with your client is important to help them to make design decisions and to complete their configuration workbooks.

In this section, you identify the field types available for use when designing the requisition template. You leverage examples to help you understand and advise on what field types to utilize in the requisition.

Parts of the field definition include the following elements:

  • id: This parameter identifies the data field.

  • required: This parameter specifies whether or not the field type requires a value.

  • type: This parameter defines the field type.

  • custom: This parameter specifics whether or not the field type is standard or custom.

Valid Field Types

The table, Valid Field Types: Field and Data, lists the field types you can use in the JRDM.

Valid Field Types: Field and Data

Field TypeData Type
texta single line of text (String — 100 char)
textareamultiple lines of text (String — 256 char)
picklistmapped to picklist ID (handled in Admin CenterPicklist Management)
datea date (typed). The calendar widget is supported
booltrue or false (shown as a checkbox)
numbera numerical value (typed)
currencynumerical amounts in the selected currency
percenta percent value (typed). For example, "50" for 50%
enuman enumerated type (shown as a pull-down list)
derivedthe system is deriving something based on data found in places outside of the XML
  • For example, the options the user has to select for country are "derived" from a value found in Admin.

  • Prior to the November 2010 release several derived fields were enum fields.

instructiona type to add instructional text
operatorrestricted to the assigned Recruiting Roles

Field Type Examples

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.

The ‘Text’ Field

In the figure, The ‘Text’ Field, 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.

‘Textarea’ and ‘Date’ Fields

In the figure, ‘Textarea’ and ‘Date’ Fields, 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.

‘Number’ and ‘Currency’ Fields

In the figure, ‘Number’ and ‘Currency’ Fields, 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.

Field Types: bool and instruction

In the figure, Field Types 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.

Travel Requirements and Function Picklist

The figure, Travel requirements and Function Picklists, shows examples of these picklists.

The following picklists 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

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.

Multi-Select Picklists

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.

Note
When making selections in an mfield, a primary value is specified. The primary value is used in integrations because most other systems cannot receive multiple values in a single field.

To add multi-select picklists to the XML of a job requisition, navigate to ProvisioningManaging RecruitingInternal 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, Multi-Select Picklists.

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

Standard Field Guides

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.

Enum Field Type

For the enum field type, values are listed in the XML template, rather than in the picklist data file.

Enum fields are expected to have two or more values.

Note
In specific templates, there are some exceptions to the expectation that enum fields require two or more values. With enums, you are notified with a warning, as opposed to receiving an error message in Provisioning.

Derived Field Type

For fields where the behavior is determined by the system, the type is "derived". These fields are declared and configured in the JRDM XML for visibility only. Adding a picklist to these fields, for example, does not change their behavior.

Notice that in the JRDM, the fields Division, Department, and Location are defined as enum.

The Division, Department, and Location fields are populated from the Employee directory. There is no need to configure enum fields for these fields.

Two more examples: For the standard fields "country" and "stateProvince", the values are derived from Admin CenterSet up Job Board Options.

Standard and Custom Fields Steps

To construct fields on a JDRM, proceed as follows:

  1. Using an XML editor, open the JRDM XML provided in the course files.
  2. Ensure that the job-req-template.dtd is in the same folder on your local drive as the open JRDM XML, which is useful for validating XML changes against the DTD later.
  3. Scroll to the end of the JRDM and verify that StatusSet1 is set as the application status set in the JRDM template.
  4. In the JRDM, locate specific field IDs and update their corresponding field labels. Use the information provided in the table to locate the field definition IDs and update their labels.

    Field IDs and Labels

    <field definition id><field label>
    id="numberOpenings"Openings to Fill
    id="jobStartDate"Job Start Date

    After you update the id="numberOpenings" and id="jobStartDate" fields with their corresponding field labels, save the JRDM template as a new version and upload it in Provisioning.

    1. Locate the id="numberOpenings" field and update the corresponding field label to Openings to Fill.
    2. Locate the id="jobStartDate" field and update the corresponding field label to Job Start Date.
    3. Save the JRDM template as a new version: FileSave.
    4. Upload the JRDM template in Provisioning.
  5. In Provisioning, update the field labels. To do so, navigate to ProvisioningManaging RecruitingJob Requisition System Field Labels. Update the Number of Openings option to Openings to Fill, and the Job Start Date option to Anticipated Start Date.
    1. To update the field labels, navigate to ProvisioningManaging RecruitingJob Requisition System Field Labels.
    2. Update the Number of Openings option to Openings to Fill.
    3. Update the Job Start Date option to Anticipated Start Date.
  6. Test the field changes by using the information in the table to complete this step.

    Fields and Values

    FieldValue
    Internal Job TitleSales Manager
    Hiring ManagerIan Iverson
    RecruiterPaula Price
    1. Log in as a user with permission to create requisitions.
    2. Navigate to HomeRecruiting.
    3. Click the Create New button.
    4. Select the option, Create New Job Requisition from blank template.
    5. Enter the information from the table, Entry Information.
    6. Select Next.
    7. Verify that the label changes for the two fields are seen in your requisition (Openings to Fill and Anticipated Start Date).
    8. Delete the requisition by clicking the red X at the top of the page.
Note
Multiple positions can be included on one job requisition. For example, if a company needs to hire 5 people for their call center, enter "5" in the "Openings to Fill" (numberOpenings) field. As candidates are hired, the remaining number to be hired is reflected on the requisition.

Standard Country Field Definition in the Requisition

The standard country field definition in the Job Requisition Data Model includes the following:

  • For companies hiring in multiple countries, there will likely be two country-related fields in the JRDM.

  • The standard country field tells the system where the job is to be located and drives candidate application fields by country. For example, US questions on EEO status and UK questions on Right to Work. 

  • The standard country field is not a picklist. The list is ‘derived’ from Job Board options in Admin Center.

  • Since there are typically two different country fields on the requisition (standard and custom for job searches), the standard field label can be something other than Country, for example, System Country or Country of Job.

Country Selection in Admin Center

To select countries in Admin Center, follow this process:

  1. To limit the list of countries selectable in the requisition, select the desired countries in Admin CenterManaging RecruitingSetup Job Board OptionsCountry and State/Province Values Setup.

  2. Click the Custom Select radio button.

  3. Search for the countries.

  4. Click the Add to list button.

  5. Click Save.

Country Field Functionalities

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.

Example

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.

Note
The country trigger comes from the job requisition (the country where the job is located), not from the applicant (or the country where the applicant resides).

CDM Overrides

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.

CDM Overrides

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

EEO Fields and Personal Fields Examples

  • EEO fields for external US applicants

    The figure, EEO Fields – Jobs Posted in US, and the figure, Personal Fields – Jobs Posted in UK, show the XML code that is used to determine which fields would display for a US candidate versus a UK candidate.

  • Personal fields for external UK applicants

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

CDM Overrides Summary

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 (FO), Generic Objects (GO), and Metadata Framework (MDF)

To enable process efficiency, Recruiting Management provides the capability to reuse the data defined in other solutions by using foundation objects and generic objects, also called HR Master Data objects.

Foundation Objects

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

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.

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.

Note
Role-based permissions (RBP) are required to use MDF.

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

Master Data and MDF

The advantages of the HR Suite include the following:

  • Ensures unified maintenance of data libraries

  • Provides seamless transmission of field values between products

  • Avoids the need for duplication of data, which improves accuracy and data is synchronized across all modules

Employee Central is not required to use Master Data. However, additional functionality is available for customers who have enabled Employee Central. For example, in an Employee Central environment, customers can reference the foundation objects/generic objects that have been defined in the People Profile. In a non-Employee Central environment, values for fields such as Location, Division, and Department are still derived from the user data file.

Standard Foundation Object/Generic Object Type Fields

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

Object NameTypeField Id
Legal EntityGOlegalEntity_obj
Business UnitGObusinessUnit_obj
DepartmentGOdepartment_obj
DivisionGOdivision_obj
Cost CenterGOcostcenter_obj
LocationFOlocation_obj

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: Foundation Objects/Generic Objects in Recruiting Management

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, and Candidate Profile.

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

  • Foundation object/generic object field types are currently not supported for mobile applications or microsites.

Use Case

In this use case, you will learn how to configure and use the generic objects (Division and Department) and the Foundation Object (Location) on the job requisition.

Division and Department objects exist in the system and are available when MDF is enabled. The relationship between the two needs to be defined from Admin CenterConfigure Object Definitions.

The specific Division and Department data required by the customer are created from Admin CenterManage Data. The following table lists the data that you’ll create:

DIVISIONDEPARTMENT
OperationsEngineering
CorporateHuman Resources
CorporateStaffing
CorporateFinance
SalesSales

Process Overview: FO and GO Fields in a Job Requisition

The process steps to use foundation object/generic object fields in a job requisition are as follows:

  1. Enable Generic Objects.

  2. Enable Role-Based Permissions.

  3. View Object Definitions.

  4. Associate the Division and Department Objects.

  5. Perform an OData Refresh.

  6. Create Divisions Data.

  7. Create Department Data.

  8. Configure foundation object/generic object fields on the job requisition template.

    1. Define Field ID and Object fields.

    2. Define Tags in Field Criteria.

    3. Define template role permissions on the XML template.

    4. Import the updated JRDM in Provisioning.

  9. Define Object Level Permissions in Role-Based Permissions.

  10. Define the Target Population.

  11. Test by populating the foundation objects/generic objects on a job requisition.

  12. Add a Location field to a job requisition.

    1. Upload Corporate Data Model XML to Provisioning.

    2. Upload Country Specific Corporate Data Model XML to Provisioning.

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

    4. Create Location Foundation Object field type in Admin Center.

    5. Update and upload job requisition template to Provisioning.

    6. Review the Location field on the job requisition.

  13. Set the visibility of foundation object/generic object fields in Recruiting Management.

  14. Enable internal and external career search settings.

FO and GO Fields in the Job Requisition

The detailed process steps to use foundation object/generic object fields in a job requisition are listed in this section.

1. Enable Generic Objects

From ProvisioningCompany 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

Note
The foundation object fields listed must be enabled even if you are going to use generic objects only in your environment.

2. Enable Role-Based Permissions

For the administrators who will work with generic objects, enable the following options from Admin CenterManage Permission RolesAdministrator 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.

3. View Object Definitions

The Division and Department generic objects exist in the system as soon as they are enabled. View these objects from Admin CenterConfigure 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.

4. Associate the Division and Department Objects

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.

5. Perform an OData Refresh

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 CenterOData API Metadata Refresh and Export, and then, in the Refresh Metadata Cache, select Refresh.

6. Create Divisions Data

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.

DIVISIONDEPARTMENT
OperationsEngineering
CorporateHuman Resources
CorporateStaffing
CorporateFinance
SalesSales

Navigate to Admin CenterManage 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.

7. Create Department Data

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

From Admin CenterManage 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.

8. Configure the Job Requisition Template

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

8a. Define Field ID and Object

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.

8b. Define Tags in Field-Criteria

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.

Note

If you receive an error when validating, ensure that you are using the latest DTD file for the requisition template. The latest versions of Employee Central XML and DTD files are available in the SAP Software Download Center. Please reference the SAP KBA here for more detailed information: https://launchpad.support.sap.com/#/notes/3113004.

8c. Define Template Role Permissions on the XML Template

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.

9. Define Object Level Permissions in Role-Based Permissions

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/View Current

  • Create

  • Correct/Delete

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.

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, Permissions for Admin Users, we 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.

10. Define the Target Population

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.

11. Test by Populating the Foundation Objects/Generic Objects on a Job Requisition

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.

12. Add a Foundation Object Field Type Location to a Job Requisition

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.

12a. Upload the Corporate Data Model XML to Provisioning

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 ProvisioningSuccession ManagementImport/Export Corporate Data Model XML.

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

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 ProvisioningSuccession ManagementImport/Export Country Specific XML for Corporate Data Model XML.

12c. Grant permission to manage the Location Foundation Object Field type in Admin Center

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

12d. Create the Location Foundation Object Field type in Admin Center

Even though location is defined in XML the information has to be created in Admin Center. Navigate to Admin CenterManage Organizations, Pay and Job StructureCreate 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.

12e. Update and Upload the Job Requisition Template to Provisioning

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.

12f. Review the Location Field on the Job Requisition

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

13. Set the Visibility of Foundation Object/Generic Object Fields in Recruiting Management

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 CenterManage 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, Enable Foundation Object/Generic Object Field Types.

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

14. Enable Internal and External Career Search Settings

The standard foundation object/generic object fields can also be used as filter (career search) fields. Select the desired fields from Admin CenterInternal 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.

Foundation Object/Generic Object Fields on a Candidate Profile

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.

Note
No changes to sm-mapping configuration are needed.

FO and GO Labels, Tokens, and Integration

Additional information that is important for understanding foundation objects/generic objects include foundation object/generic object labels, tokens, and integration.

Foundation Objects/Generic Object Labels

To learn how the labels for foundation object/generic object fields are derived, refer to the Implementation Guide: Implementing HR Master Data Sync for Foundation Object and Generic Object Fields in Recruiting Management. Inform your customers that any label changes are platform-wide and will not just impact Recruiting Management.

Tokens

All the foundation object/generic object fields defined on the job requisition template and offer template are available to be used as tokens; no configuration is necessary. In the case of foundation objects/generic objects in Employee Central and non-Employee Central instances, the primary use case for using foundation objects/generic objects is to allow for the reuse of data defined in MDF for Recruiting. Without Employee Central enabled, the other modules, including the Employee Profile/People Profile, do not use foundation object/generic object values, such as Division and Department. On a non-Employee Central instance, these field values will still be derived from the user data file.

Integration

Refer to the Implementation Guide for additional information on all integrations: Implementing HR Master Data Sync for Foundation Object and Generic Object Fields in Recruiting Management. Some considerations for integrations include the following:

  • For Recruiting Marketing integration, the foundation object/generic object field types can be mapped to STRING type fields. The field mapping page, Admin CenterSetup Recruiting Marketing Job Field Mapping Configuration, supports mapping foundation object/generic object fields.

  • The Employee Central Integration has also been enhanced to support mapping for foundation object/generic object fields.

  • For Onboarding integration, it is required to use Business Rules.

  • For Position Management integration, it is now possible to map foundation object/generic object fields on the Position Object to the fields on the requisition.

  • It is possible to migrate data from older picklist values to the foundation object/generic object field types using Business Rules.

FO and GO Fields in Offer Approvals

In the Offer Detail Template, a field of type foundation object/generic object can only be defined if the field is derived from the job requisition, that is, a field with the attribute template-type="job-req".

Field Permissions

It is not possible to give write permission to the standard generic object fields. The standard Location Foundation Object field will have write permission.

Custom fields derived from the job requisition can have write permission if they are marked as Custom Reportable Fields in Provisioning from the page Configure Reportable Custom Fields.

Standalone Offer Fields (fields that are not derived from the job requisition or application) can have write permission if defined in the template.

Use available resources when working with foundation objects/generic objects and MDF:

  • For detailed information on HR Master Data for foundation objects/generic objects, refer to Implementing HR Master Data Sync for Foundation Object and Generic Object Fields in Recruiting Management.

  • For information on foundation objects, see Introduction to Foundation Objects.

  • For information on generic objects, see Generic Object Definition.

  • For information on the Metadata Framework, see Metadata Framework Implementation Guide.

Log in to track your progress & complete quizzes