How to edit read/write permission for candidate application fields when using multi stage application?
"Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental."
SAP SuccessFactors Recruiting Management
Recruiters or candidates don't have write permission to candidate application fields.
First, check provisioning if you are using multi stage application.
The tag <application-status-config> should be configured in job requisition template as shown below.
The application-status-config element defines the applicant status set for requisitions created from this Job Requisition 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.
*Note this is just an example for reference, not a recommended set of configuration.
Here we will cover the different tags within the application-status-config:
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 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.
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
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.
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.
Specify all field IDs that should be affected by the permission block. The asterisk is also supported to indicate “all” fields.
<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 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
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.
Once you understand all the available elements if you don't have access to provisioning, you can and or edit the read/write permission for any field using manage teampltes:
Go to: Admin Center > Manage Templates > Recruiting Management > Job Requisiton > Select the desired template
After selecting the desired template click in General Settings on the rigth column > then select Application Status configuration > "Field Permissions Defined.Click to modify"
A new window will open with all defined permission blocks. Here you can either change an existing block or create your own. When creating a new one you can define which fields will be added and the type of permission (read or write) for specific job requisition statuses. You can also select specific roles like a recruiter, candidate, etc, to read/write on the selected fields.
2753429 - Permission Issue with Operator in Multi-Stage Environment - Recruiting Management
Edit Field Permissions; Edit/Write Field Permissions; Field Permission; , KBA , LOD-SF-RCM-APP , Applicants and Job Applications , How To