2360774 - Encountering "You cannot run this report as you do not have any Recruiting Security fields enabled in Provisioning"

Encountering "You cannot run this report as you do not have any Recruiting Security fields enabled in Provisioning" error message when trying to run Table Report / Detailed Report /YouCalc tile / Dashboard of Recruiting V2 Secured Domain.

Unable to run / create Table Report, Detailed Report (ORD), tile of Recruiting V2 Secured domain.

SuccessFactors HXM Suite

Table or Detailed Report:

1. Create an Table or Detailed Report on Recruiting V2 Secured
2. Under "Requisitions Criteria"/"Requisition View" select Detailed Requistion Filters
3. Click on Preview button
4. This message appears: 'You cannot run this report as you do not have any Recruiting Security fields enabled in Provisioning. Please contact your SuccessFactors Administrator.'

Tile:

1. Create an Tile on Recruiting V2 Secured
2. Click on Requisitions
3. Under "Relationship View" select Detailed Requistion Filters
4. Click on Preview button
5. This message appears: 'You cannot run this report as you do not have any Recruiting Security fields enabled in Provisioning. Please contact your SuccessFactors Administrator.'

• Normal Recruiting V2 does NOT have a security layer around it. Any user who has Table/Detailed report create permission can essentially generate data on all Views available in Recruiting V2 sub domain schema. To overcome this limitation Recruiting V2 Secured was created which has it's own sub domain schema

• Recruiting V2 Secured provides the security layer as follows:

• Any user who has Table or Detailed report create permission for Recruiting V2 secured report can create Table or Detailed report in the following two ways:

          A. Relationship Views -- Based on operator type: Meaning a user can create Table/Detailed report only on the records on which he/she is the operator. For e.g: A user can create a Table/Detailed report based on operator Originator, the data generated in the report would contain only records on which the user is originator. And no other records are included in the report

          B. Detailed Requisition Rights -- Unlike Relationship views the layer of security is provided based on certain fields which are permissioned such as Department, Division & Location, meaning  Table/Detailed report can be created based on a particular Department. For e.g. Table/Detailed report can be created based on DepartmentA & LocationA, LocationB

• Which fields need to be enabled for permissioning is decided by Recruiting Security Field Setup setting. On what values of the field enabled from provisioning is decided from the Admin setting -> Manage Requisition Reports Privileges setting
• For e.g. Say Department field is enabled under provisioning for permissioning and UserA is given permissions to DepartmentA, DepartmentB under Admin> Manage Security > Manage Detailed Requisition Reporting Privileges, then UserA can create Table/Detailed report in which the records belonging to only Department A, B are Only generated in the Table/Detailed report. No other records are included in the report

Provisioning Changes:

1. Go To Provisioning > Managing Recruiting > Recruiting Security Field Set Up
2. Select Job Req ID
3. Click on Save

SF Instance Changes:

1. Log into Instance 
2. Admin Center > Manage Detailed Requisition Reporting Privileges > Search for the Username
3. Click on All under Job Req ID Permission column 
4. Check the left hand check box
5. Save Permission
6. Refresh the username and ensure the permission is saved successfully

This issue was related to a security gap in the handling of Detailed Requisition Rights when no security fields were defined in Provisioning.

Before b1608 Release:

Report would show all Requisitions when Detailed Requisition Rights was selected as the Requisition Pill option (if no security fields were defined in Provisioning)

As part of enabling and using the "Recruiting v2 Secured" type reports, whoever enabled this, should have also turned on the recruiting filters. 
This is the whole purpose of those types of reports. But the problem was that, pre-1608, there was no validation checking to ensure that the filters were set. 
If a client doesn't have the filter set, the reports still ran, but it just defaulted to allowing the user to run for all data since there was no filter restrictions set up.

After b1608 Release:

Report will show no Requisitions when Detailed Requisition Rights was selected as the Requisition Pill option (if no security fields were defined in Provisioning)

In the 1608 release we introduced a validation check to verify that the user does indeed have at least 1 filter set up. 
If a client has the "Recruiting v2 Secured" type report created and it is to use the "Detailed Requisition Filter" - but you don't have any filters set up, then you will get an error/warning that there are no filters.
To fix this error, you just need to have a least one filter option checked off in Provisioning. 
By enabling, they can now go to each of their report users and restrict their access by those filters. Once you enable a filter, it will default to "None" permissions. 
Meaning they cannot run the report for any data. So the customer will then need to go to Admin Center - > Detailed Requisition Reporting Privileges -> look up the employee and then change the filter settings from none to whatever they need.

What makes it secure?

Secure in this sense doesn't necessarily mean what you think of when you say "security". For the longest time, I thought "secure" meant the sensitive data - i.e. DOB, SSN, EEO, etc. But that is not at all what it is. Secure in the sense of these reports is just that you can set the filters to limit the report runner's access.

Table Detailed Report, Dashboard, Tile, YouCalc Tile, Recruiting V2 Secured, Detailed Requistion Filters, You cannot run this report as you do not have any Recruiting Security fields enabled in Provisioning , KBA , LOD-SF-ANA , Analytics & Reporting (Ad Hoc, YouCalc, ORD) , Problem