How to Report on SAP SuccessFactors Recruiting

Navigating Report Stories in SAP SuccessFactors Recruiting Management can be a challenging task due to complex permissions and data access requirements within the solution, but it is essential to have a clear understanding of these factors to create effective Report Stories.

Report Stories Use Case: Recruiting Management Data Access

In this blog post, we aim to provide helpful guidance and clarification to make Recruiting Management data access easier for SAP SuccessFactors users. We will dive deep into the process of enabling Recruiting Operators (e.g., hiring managers, also referred to as HMs) who are also team managers to view information about job requisitions within Report Stories. This will also apply to instances where the HM is a member of their team.

Data Access for Recruiting Management in Report Stories

There are two possible options to grant data access for SAP SuccessFactors Recruiting Management data in Report Stories:

• Data access is determined by the role (operator type) granted in the Recruiting Management module. Typically, users will have visibility into job requisitions where they are assigned as Operators. (In this use case, we’ll consider the role of an HM.)

• Alternatively, the user can be granted the “Data access: Story” permission in Role-Based Permissions (RBP), under Recruiting Permissions. This permission lets the user access information from all job requisitions in the system.

Use Case: Creating a Report Story in SAP SuccessFactors

The goal is to create a Report Story for HMs, enabling them to view job requisitions where they are designated as an HM, as well as requisitions where a team member holds the HM position. However, they shouldn’t have access to all job requisitions in the system.

Prerequisites:

HMs must be able to access information regarding their team members (at least direct reports), defined by the target population set for their permission group(s).

Solution:

Let’s consider Aaron G. Johnson as an example. Aaron is a manager in his organization and has three direct reports:

By checking Recruiting Workbench, we can see that Aaron is the HM for two job requisitions:

In Stories Query Designer, we built a query to explore the data:

At this point, Aaron still lacks some necessary permissions, which limits his view to only the two job requisitions where he is an HM, but not data such as “HM First Name” and “HM Last Name” (which is himself):

To solve this, create a new permission group and a new permission role granting “Data access: User” permission to Aaron, with Target Population = All Direct Reports (and their reports All level(s) down) (include access to Granted User (Self)) (per the screenshots below):

When the new permission is granted, Aaron can still only view his job requisitions, but he is now able to view his name in the HM table:

Next, we grant “Data access: Story” permission in Recruiting Permissions for Aaron’s role as well. This modification allows him to view information from all job requisitions in the system. Per the screenshot below, he now has access to view 1,991 job requisitions:

You may notice that most job requisitions fall under HM First Name and HM Last Name = (Null). This occurs because the HM name is sourced from the user schema and not from the Recruiting Management schema (auto-join done on the Hiring Manager table). Consequently, Aaron can only view the First Name and Last Name values of users within his team, while other job requisitions display “(Null)” for HM name.

Our objective is to restrict Aaron’s access to specific job requestions, limiting him to viewing his requisitions and those from his team members (i.e., the two job requisitions that have Aaron as HM and two other job requisitions for which Diamaris Corniel—Aaron’s direct report [see org chart above]—is an HM). In Aaron’s team, no others are HMs or have current job requisitions.

To achieve the above results, change the join type between the Job Requisition table and the Hiring Manager table in our query, from a Left Outer Join to an Inner Join, meaning only common data from both tables is returned.

Aaron now only has access to four job requisitions. Two of these positions are where Aaron is the HM, while the other two are being overseen by one of his direct reports (Diamaris).

Conclusion—SAP SuccessFactors Recruiting Management Configurations

To sum up, it’s possible to use a bit of creativity to restrict SAP SuccessFactors Recruiting Management data that a user can see in stories. In the presented use case, this was achieved with a combination of permissions and a change of join type. Please note that this is a solution to a very specific example. In other Recruiting Management configurations and Report Stories, it may not apply as it is presented and may require additional adjustments. With this proposed solution, we can avoid the management of Recruiting Management data access in stories through the Recruiting Teams setup (which can be hard to maintain).

Get Started with Report Stories

Are you looking for ways to make the most out of your organization's recruiting management? Report Stories in SAP SuccessFactors Recruiting Management is a powerful tool to help you maximize the impact of your organization's recruiting management. This blog post aims to be a source of inspiration so you can take better advantage of your SAP SuccessFactors solution.

Download this SAP SuccessFactors Workforce Analytics Metric Report to learn how other companies use HR analytics to effectively identify and mitigate low-tenure termination challenges.

Effective People has helped companies in all industries and regions by deriving insights from data. As one of the select SuccessFactors partners with a dedicated Analytics team, our experts utilize their years of experience and skills to ensure that every report and dashboard is pertinent to the business and supports data-driven decision-making. Contact our Analytics team to find out how we can assist you on your HR transformation journey.