Tell us what you think

We want to create the best possible experience for our learners. Your feedback helps us to improve the experience for everyone.

Configuring Job Requisition Field Permissions

Objective

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.

Code block for field permission with their attributes is displayed. The system status is highlighted as pre-approved.

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.

Code block for field permission with their attributes.

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 Roles	SAP SuccessFactors Label	Customer Label	Usage and Comments
O (Originator)	Originator	Originator	Has access to all candidates and job data for their requirements only. Posts jobs.
G (hiringManagerName)	Hiring Manager	Hiring Manager	Has access to all job requisitions assigned to them (read only), and all candidates sent by HR.
R (recruiterName)	Recruiter	HR Leader	Has the capability to run reports by SBU.
T (coordinatorName)	Coordinator	Recruiter	Has access to all job and candidate data, but does not have permission to originate a requirement.
S (sourcerName)	Sourcer	Sourcer	Has access to candidate data only, and no access to requirement data.
Q (vpOfStaffingName)	VP of Staffing	VP of Staffing	Can be any other necessary role.
W (secondRecruiterName)	Second Recruiter	Backup Recruiter	Can 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 Job Requisition Field Permissions

Business Example

The configuration of field permissions allow customers to control which operators receive permissions to the fields defined in the job requisition template during the creation and review of the requisition.

In this exercise, you will create a field permission for the custom field you defined in the previous 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.

For consistency, we will follow the existing field permission structure of the job requisition template.

Task 1: Edit Field Permission in JRDM

Steps

In an XML editor, open the latest version of the Hourly Job Requisition JRDM XML .
Locate the field permission section of the job requisition template.
Provide the write permission the new custom field cust_businessReason to the Originator, Recruiter and Hiring Manager operators in the Pre-Approved status only.
1. To find the appropriate permission blocks that need to be modified, review how the field permission blocks have been created. Since we will need to permission a new field to the Originator, Recruiter and Hiring Manager operators, we will be looking for the permission blocks assigned to the O, R and G roles.
2. Insert a new permission line: <field refid="cust_businessReason"> below the cust_replforwhom field permission in the write permission blocks belonging to the O,R and G roles in the Pre-Approved status.
Validate the updated JRDM against the DTD and correct any errors.
Save your updated JRDM as a new version.
Upload the updated JRDM to Provisioning.

Task 2: Create a Requisition to Test the Custom Field

Steps

Test your changes by logging into your instance and navigating to Recruiting.
Within the Job Requisition tab, choose Create New to create a new job requisition.
Select the Hourly Job Requisition template.
Select the option to Create a New Requisition from a Blank Template.
Name your test requisition and change the Recruiter to HR Coordinator (When logging in as the admin, you are the HR Coordinator. When you are the Recruiter of the job requisition, you can quickly see the changes you have made to the job requisition template).
Select Next .
Verify the changes you have made to the Hourly Job Requisition template.
- The field label for Number of Openings has changed.
- The field label for Job Start Date has changed.
- The new custom field for business reason appears below Replacement for Whom.

Next lesson