Configuring the Application Template


After completing this lesson, you will be able to:

  • Update the job application template
  • Configure fields in the application template
  • Configure field permissions in the application template
  • Configure field overrides in the application template
  • Configure button permissions
  • Configure candidate display options in the application template

Multiple Applications

Learn about applying for open positions with job applications.

In today’s competitive candidate market, the application process needs to be simple, quick, and sometimes directed towards certain types of jobs.

Application for Sales Manager – Contractor

The CDM (Candidate Data Model) is essentially the candidate application.

  • From time to time, customers may want a requisition to be connected to a different application with changes to fields and questions.

  • One example is having an application that is focused towards contractors instead of employees, as shown in the figure, Application for Sales Manager – Contractor.

The CDM is tied to the job requisition template in the JRDM XML. One JRDM XML template is always connected with one CDM XML template

There can be multiple CDMs per instance. If a customer requires multiple candidate applications, then they will also require multiple job requisition templates, since each job requisition template is tied to one candidate application.

The CDM can be configured to control which fields display for internal versus external candidates, as well as the fields that display to the candidate based on the country where the job is located.

Each field in the CDM can be permissioned to be viewed by each recruiting role that is permissioned on the JRDM.

The CDM is also used to grant button permissions for use after the job requisition has been opened to each recruiting role. Standard buttons can be relabeled and are as follows: Forward, Save, and Cancel.

Application Export, Name Change, and Import

As a starting point for creating a new application template, export the current application.

Application Export, Name Change, and Import

To export, change the name of, and import the current application, proceed as follows:

  1. Log in to the customer site in Provisioning.

  2. In the Managing Recruiting section, locate the Edit Job Requisition Application Template.

  3. Export an existing CDM template to use as an example.

  4. Change the name of the template before importing it back into Provisioning.

    • Modify the <template-name> and <template-desc> lines in the XML to change the name and description of the new CDM.

    • For our example, change the name of the template to Contractor Details Template to make it easier to find.

    • Like the JRDM, the template-name is the unique identifier of the application, thus an updated template-name ensures you do not overwrite the existing CDM template.

  5. Import the updated CDM.

  • You may receive the following warning when importing your template: If this Application Template already exists in the system, continuing with the upload will replace the existing template with your changes. This will affect all job requisitions that reference this template. Press OK to continue.

    This is a reminder that if you did not rename your template, you will overwrite the existing one in the system, as shown in the figure, Overwrite Warning.

If you have completed the steps correctly, you can see your updated CDM in Provisioning.

CDM Fields

Before making any changes to an XML template, be sure to export the current XML version.

Always export two copies of the XML file. Mark one copy as original for that day and archive it. Then work with the second copy and you can date the file for that day.

This process of exporting two copies and archiving should be followed for every type of template: application, requisition, profile, data model, and offer approval. Following a standard process is especially important when more than one person is working with the files.

CDM fields are either standard or custom.

  • Standard CDM Fields

    • If the field is a standard field: custom="false".

  • Custom CDM Fields

    • If the field is a custom field: custom="true".

    • For custom fields, the field ID starts with cust.

CDM Field Definition

The attributes that define CDM fields are as follows (details of each field will be provided in later sections):

  • ID

  • Type

  • Required

  • Custom

  • Public

  • Read only

  • Anonymize

Type Attribute

The CDM field types available are as follows:

  • Bool

  • Date

  • Derived

  • Enum

  • Multiattachment

  • Number

  • Picklist

  • RichText

  • Text

Required Attribute

  • If a field is required: required="true"

  • If a field is not required: required="false"

Type and Required Attributes on Field Definition

Custom Attribute

If the field ID is anything other than what is listed in the standard field guide, then this attribute must be set to true.

It is best practice to use as many standard fields as possible since standard fields are automatically reportable.

Public Attribute

  • public="true"

    All candidates (internal and external) can view the field.

  • public="false"

    The field is not visible to candidates unless an override is set.

Read Only Attribute

  • Most candidate fields need to have this set to false. Otherwise, the candidate will not be able to write to this field.

  • This is generally a legacy attribute; read or write capability is now typically controlled through permissions, not through the Read Only attribute.

  • In new configurations, always set the Read Only attribute to false.

Anonymize Attribute

The Anonymize Attribute identifies whether a given field is considered personally identifying data and should be purged.

Sensitive Attribute

SAP SuccessFactors provides a Read Audit function that helps to determine who has accessed the sensitive personal data of candidates at your company. When Read Audit is enabled, sensitive fields are included in read audit reports if the candidate or someone else accesses sensitive personal data of the candidate. To configure a field as sensitive, ensure that both the sensitive and the anonymize attributes for the field are set to true.

Field Permissions in the Application

Once you have defined the required fields in the application template, you will have to permission the fields to the appropriate recruiting operator.

When using the single stage application environment, you will need to permission your recruiting operators with the "read" or "write" access in the application template for any field that they will need access to.

Field permissions are read and applied top to bottom in the order they appear in the XML template. This means that the latter permissions override the former if there’s a conflict. For example, you can define all read permissions for all operators first and the write permissions after all read permissions are set up. That way, if there are any conflicts between permissions, the greater permissions rule.

The only conditional control available for field permissioning is through multistage application, where applicant status can adjust field permissions. Currently, you can’t change field permission based on internal versus external candidate type, or country/region.

For multistage applications, all field permissions for recruiting operator roles except for resume, coverLetter, and statusId fields must be moved to the job requisition template. However, CoverLetter and resume fields are defined in the job requisition template for candidates and can also be defined by status. The multistage application configuration is covered in more detail in the upcoming lesson.

Field Override Configuration

Some fields should only be seen for jobs in specific countries or by internal and external candidates.

Field Override Section in CDM

  • To show or hide certain fields for jobs in certain countries or for a particular candidate type, use the Field Override configuration.

  • Field Override allows public=false fields to be visible to the different groups of candidates (internal and external or for jobs in different countries).

Override Section in CDM

  • The following override configuration makes fields viewable to internal candidates:

  • <field=attr attribute="public" value="true" applicant="internal"/>

  • The following override configuration makes fields viewable to external candidates:

  • <field=attr attribute="public" value="true" applicant="external"/>

  • The following override configuration makes fields viewable to external candidates for jobs posted in the US and Canada:

    Code snippet
    <field attr attribute="public" value="true" applicant="external"/>

The country abbreviations are dictated by the standard ISO list. These can be viewed on the International Organization for Standardization (ISO) website:

Application Button Permissions

The type of application buttons available are as follows:

  • Save

  • Remove From Consideration

  • Reopen for Consideration

  • Forward

Application Button Configuration

To configure application buttons permissions, you need to configure the following elements in the button permission XML (Application):

  • <description> The CDATA value is not displayed anywhere in the product.
  • <role-name> The CDATA value is used to store the valid role.

    You may list multiple <role-name> elements within the <button-permission> block.
  • <button-id> The CDATA value is used to store the valid button.

    You may list multiple <button-id>elements within the <button-permission> block.

Enablement of Button Permissions

The buttons you can enable permissions for are as follows:

  • Forward allows the role to forward the candidate to another requisition or to a user.

  • Close allows the role to remove the candidate from consideration.

  • Save allows the role to save changes to the application.

  • Cancel allows the role to cancel changes to the application.

Application Button XML

The figure, Application Button XML, shows two XML samples that enable application button permissions.

  • In sample 1, the recruiter is permissioned to forward, close, and reopen the application of the candidate.

  • In sample 2, all roles ("*") are permissioned to save and cancel changes to the application.

Candidate Display Options Field Permissioning

Permissions for the fields on the CDM are assigned the same way permissions are assigned in the requisition.

CDM Field Permissioning for Recruiting Operators

  • If permissions are not set for a CDM field, internals roles (such as recruiters and hiring managers) will not be able to read or write to that field on the candidate summary page.

Job Application Field Labels

After defining a standard field label in the Candidate Data Model, be sure to add the modification in a special area of Provisioning or Admin Center named Job Application Field Labels. If you do not have this option within Admin Center, be sure to enable Manage Job Application Field Labels permission. Any modifications made to this section will be directly reflected to the end user experience for the application.

Log in to track your progress & complete quizzes