SAP Learning Journey

Configuring Job Requisition Field Permissions

Objectives
After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Configure field permissions on the job requisition

Field Permissions

The Field Permission section defines which roles have read or write permissions for the requisition fields.

Based on the status of the requisition, roles are defined as being able to read or write to a field.

Requisition Status and Field Permission

The requisition statuses are as follows:

  • Pre-Approved: While the job requisition is routed for approval, and before it has received approval from the last approver, the system status is pre-approved.

  • Approved: After the job requisition has received all the necessary approvals, the system status is approved.

  • Closed: The job requisition is filled or closed.

Field Permissions Parameters

The field permissions section includes the following fields:

  • type: This parameter defines the field type. You can choose between read or write.

  • <description>: This CDATA value is not displayed anywhere in the product.

  • <role-name>: This CDATA value is used to store the valid roles. You can list multiple <role-name> elements within the <field-permission> block.

  • <status>: The valid CDATA values are pre-approved, approved, or closed, for each of the three possible job requisition statuses.

  • <field refid="xxxx">: The refid is set to the data field. You can list multiple <field refid="xxxx"> elements.

The system uses the 'J' role to list all defined fields in one place.

Hint
It is best practice not to edit the default ‘J’ role sections on the XML template.
Note
You cannot use None as a permission; it is not supported in Recruiting. Use either Read or Write permissions.

Field Permission Parts

A set of field permissions consists of the following parts:

  • type (write | read): This parameter defines the field type.

  • <description>: The CDATA value is not displayed anywhere in the product.

  • <status>: The valid CDATA values are pre-approved, approved, and closed for each of the three possible job requisition statuses.

  • <field refid="xxxx">: The refid is set to the data field. You may list multiple <field refid="xxxx"> elements.

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

Read or Write Permissions

The figure, Read or Write Permissions, shows permissions in three different system statuses: pre-approved, approved, and closed.

J Permissions

When exporting an existing requisition, J permissions display.

J is a system role used only to display fields that are used for reporting. This is a way of seeing a list of all the field IDs, and to use them for assigning permissions.

Recruiting Roles

As with most types of forms used in the workplace, different users perform different tasks with them. For example, whereas recruiters might require write permission for form fields, approvers and hiring managers might only need to read fields, and some people might not see certain fields at all.

In this section, you learn about granting permission to fields in the job requisition, so only the roles with the right permissions can read or edit fields.

Requisition permissions are given to recruiting roles. Here are the roles used for requisitions:

  • O — Originator

  • G — Hiring Manager in Recruiting

  • R — Recruiter in Recruiting

  • T — Primary Coordinator in Recruiting

  • S — Sourcer in Recruiting

  • Q — Vice President (VP) of Human Resources (HR)

  • W — Second Recruiter

Role Definitions

Roles used for Requisitions

SAP SuccessFactors RolesSAP SuccessFactors

Label

Customer LabelUsage and

Comments

O (Originator)OriginatorOriginatorHas access to all candidates and job data for their requirements only. Posts jobs.
G (hiringManagerName)Hiring ManagerHiring ManagerHas access to all job requisitions assigned to them (read only), and all candidates sent by HR.
R (recruiterName)RecruiterHR LeaderHas the capability to run reports by SBU.
T (coordinatorName)CoordinatorRecruiterHas access to all job and candidate data, but does not have permission to originate a requirement.
S (sourcerName)SourcerSourcerHas access to candidate data only, and no access to requirement data.
Q (vpOfStaffingName)VP of StaffingVP of StaffingCan be any other necessary role.
W (secondRecruiterName)Second RecruiterBackup RecruiterCan be any other necessary role, but often used with a single ID. This allows all requisitions to be viewed in one place.

The following additional roles are available:

  • V for All Approvers

  • Derived Roles (GM, RM, and so on)

The roles are used to designate "read" and "write" permissions on the job requisition fields.

Roles are also used for workflow (route maps).

Requisition Statuses

The requisition statuses are as follows:

  • Pre-Approved

  • Approved

  • Closed

Field Permissions in Pre-Approved Status

Pre-Approved: While the requisition is being routed for approval, and before it has received the approval from the last approver, the system status is Pre-Approved. This means all the steps on the route map use the Pre-Approved status for permissions.

Field Permissions in Approved Status

Approved: After the requisition has received all the necessary approvals, and is complete, the requisition has an approved status. It is now possible to post the job.

Field Permissions in Closed Status

Closed: The requisition is filled or closed.

Roles are used to grant permission to "read" and "write" access to the job requisition fields for all three statuses.

V Permissions

V (for all approvers) permissions are used to add approvers and to add modifiers. V means anyone who gets the requisition.

Any permissions given to V, are applicable if the V permission is greater than an individual role permission. Following are examples of how the V permission is applied:

  • If V has read permission, and G has none, then G becomes able to read the field.

  • If V has no permission, and G has read permission, G is able to read the field.

V role permissions come first in the order of permissions, then provide the standard roles permissions. This means that later permissions will supersede the V role.

Configure Field Permissions

Business Example

The customer might prefer that some of the fields be available to a specific role only; for example, assign these fields to the recruiter.

In this exercise, you modify the permission for Location Information.

Information Required for Completion of This Exercise

These are the job requisition system statuses:

  • Pre-Approved Status: Only the Recruiter is able to edit the Location Information fields. The other roles, as defined in your template, should not have access to the Location Information fields. However, they should retain access to all other existing fields, as defined in your template.

  • Approved Status: The Recruiter is still able to edit all Location Information fields. The other roles, as defined in your template, can only read the Location Information fields.

  • Closed Status: When the requisition is closed, all Location Information fields become read-only for all roles.

Following are the Location Information field IDs:

  • country

Steps

  1. In an XML editor, open the latest version of the JRDM XML.

  2. Modify some of the existing permissions for Location Information fields based on the information provided above, and create new ones.

    For example, in the pre-approved status, currently everyone with permissions can write to the Location Information fields. Only the Recruiter should be able to write to these fields. The other roles should not see (or read) the Location Information fields. Other than modifying these specific fields, all roles should retain their existing permissions in the template.

    1. Make sure that these fields are included in the permissions for the Recruiter in pre-approved status.

    2. Under last permission section for pre-approved status create a new set of permissions.

    3. Remove the same fields from the permission set in the pre-approved status, so other roles do not have permissions to read or write Location Information fields.

    4. Remove the same fields from the permission set in the approved status, so other roles do not have permissions to read or write Location Information fields.

  3. Validate the updated JRDM against the DTD and correct any errors.

  4. Upload the updated JRDM to Provisioning.

  5. Create a new requisition and route it all the way through the approval process to verify the changes.

  6. Verify the permissions for the Location Information fields.

    1. After approval, open the requisition as the recruiter and verify that the recruiter can edit the fields. Open the requisition as the Hiring Manager and verify that the Hiring Manager can view these fields. Click Close Job Requisition and log in as the recruiter to identify how the permissions have changed.

  7. After it has been approved, open the requisition as the Recruiter and then as the Hiring Manager to ensure that the Recruiter can still edit those fields but others can only view them.

    1. After it is approved, open the requisition as the recruiter. Verify that the recruiter can edit these fields.

    2. Open the requisition as the Hiring Manager. Verify that the Hiring Manager can view these fields.

  8. Scroll to the bottom of the form and click Close Job Requisition.

  9. Log in as the recruiter and identify how the permissions have changed.

Log in to track your progress & complete quizzes