SAP Knowledge Base Article - Public

2664743 - How to edit read/write permission for candidate application fields

Symptom

Recruiters can't update candidate application fields.

How to edit read/write permission for candidate application fields when using multi stage application?

Environment

B1805

Cause

Recruiters don't have write permission for candidate application fields

Resolution

First, check provisioning if you are using multi stage application.

multi stage.png

<application-status-config> should be configured in job requisition template.

The application-status-config element defines the applicant status set for requisitions created from this XML template. The applicant status set is used to manage the steps through which applicants are routed during the hiring process, and manages the interaction between statuses and feature permissions (and, in multi-stage application environments, it also manages the interaction between statuses and application field-permissions). When configuring multi-stage application, all statuses in the status set should be defined in the candidate permissions model, or else the candidate will be able to view all fields.

 

XML sample:

*Note this is just an example for reference, not a recommended set of configuration.

 xml.png

 

application-status-set Element and name Attribute

 <application-status-set name="Candidate Workflow"/>

Specify the applicant status set name to use on requisitions created with this Requisition XML template.

 

field-permission Element

Field permission elements should only be declared within the application-status-set element if the instance is set up with [Provisioning >Company Settings >Recruiting V2 Application >Enable Multi Stage Application checked]. If this setting is unchecked, the permissions will be read out of the Application XML instead. If this setting is checked, all field-permissions in the Application XML should be commented out or removed except for the write permissions to the statusId, resume, and application comments permissions fields. If contradicting field permissions are specified in both the Application XML and Requisition XML, the permissions may not be rendered correctly for recruiting users. When configuring multi-stage application, all statuses in the status set should be defined in the candidate permissions model, or else the candidate will be able to view all fields.

 

type Attribute

<field-permission type="read">

The type attribute of the field permission element determines what kind of permissions are applied in the permissions block. The type attribute must be set to one of the following types:
Read: the field can be read by internal and external users in the specified roles, only applicable to open requisitions
Write: the user may both read and write the fields, this is after the requisition is open

 

 description Element

 <description><![CDATA[Write Permissions]]></description>

 

role-name Element

<role-name><![CDATA[R]]></role-name>
<role-name><![CDATA[G]]></role-name>

The role-name element defines which operators are affected by the permission block. Each permission block supports multiple role elements. The role-name CDATA content must contain only valid roles and relational roles such as O, R, RM, GH, etc.

You can use the <field application-field-id="*"> to configure a field permission block for all fields.

 

 status Element

<status><![CDATA[Default]]></status>
<status><![CDATA[Interview]]></status>
<status><![CDATA[Hired]]></status>

In a multi-stage application environment, field permissions can be adjusted based on whether the applicant is in Interview, Offer, etc. There is no way to change field permissioning or hide/display fields based on application or requisition data.

 

field Element and application-field-id Attribute

<field application-field-id="recruiterPhoneScreenDate"/>
<field application-field-id="screeningNotes"/>

Specify all field IDs that should be affected by the permission block. The asterisk is also supported to indicate “all” fields.

 

required Element

<field application-field-id="baseSalary" required="true"/>

Certain fields may need to be made unrequired and available in most statuses, but then become required at a certain point in the status workflow. The required attribute can be added to the field application-field-id element to specify that the ordinarily non-required field should be required in that status.

 

feature-permission Elements

 <feature-permission type="interviewAssessment">

Feature permissions define operator access to certain special functionalities. An unlimited number of feature-permission elements can be included in the Requisition XML.

 

application-template-name Element and name Attribute

<application-template-name name="Candidate Detail Info Template"/>

The application template name element defines which Application XML template will be presented to candidates and recruiting users when managing applications on requisitions created from this Requisition XML template. After the Requisition XML is created, this should not be changed or it may cause errors on existing and/or new records.

 

candidate-email-permission Element and type Attribute

<candidate-email-permission type="candidateEmail">

By default all operators can access the Email button on the application record. If the client wishes to restrict certain operators from accessing the email button, this element can be added to the Requisition XML and only permissioned users with access to the Email button. This can only be declared once in the Requisition XML template and cannot be permissioned by status.

Keywords

KBA , LOD-SF-RCM-APP , Applicants and Job Applications , How To

Product

SAP SuccessFactors Recruiting all versions