Product | SuccessFactors integration |
Expert(s) | Brad Edwards, John Yamashiro (Enterprise EPD team) |
Slack channel | |
This article was last verified on | 03/12/2024 |
🔍 Articles in This Section
Please use the following list to see additional internal articles regarding the SuccessFactors integration:
- (Internal) SuccessFactors integration: Overview
- (Internal) SuccessFactors integration: Customer eligibility and setup
- (Internal) SuccessFactors integration: User permissions (đź“Ťyou are here)
- (Internal) SuccessFactors integration: Available features and FAQs
- (Internal) SuccessFactors integration: Expected real-time webhooks
Note: Limitations in the SuccessFactors API prevent us from properly handling permissions for search, the detailed candidate view in PA and the PA debugger. In the future, this would also impact Talent Pipeline. This would cause unauthorized users to be able to see data they could not see in SuccessFactors itself.
For example:
- In Search, Bob would be able to see Alice’s work and location, among other fields. However, in SuccessFactors, they do not have permissions to see those fields for Alice
- In PA detail view, Charlie would be able to see details about Bob’s application, including the the application timeline. In SuccessFactors, Charlie doesn’t have access to the application timeline.
How does Gem handle SuccessFactors permissions?
We greatly simplify the SuccessFactors permission model for our purposes. Gem users are only able to view jobs on which they are an “operator”. They are also only able to view applications associated with jobs they are an “operator” on. This is good enough for PA and PA debugger but we may need to confirm if this looser permission model is okay for something like Talent Pipeline.
Why can’t we mirror exact SuccessFactors permissions?
The endpoints related to user permissions were meant to be used per user, per entity rather than through a bulk sync strategy like we are planning to do. To fully map out a user’s permissions, we would need to make a request for every (user * (application + candidate + job)). For a large enterprise customer, this could easily result in 10’s of millions of requests.
The only thing we can get with certainty is whether or not a user is aware of a job. SuccessFactors uses field-level permissions to determine what data within an entity a user can see. These permissions allow for arbitrary expressions for every field of data (e.g. users in France can see the first name of candidates within this specific job). We cannot get those permissions without making requests for every user and entity pair. For more details on the data model, see the appendix.
How do other ATSes deal w/ permissions?
Other ATSes are able to rely on the deep sync data for user permissions because there is a way to batch sync them. They also have simpler permission models that don’t seem to include field level permissions or arbitrary expressions. For Greenhouse, Lever, Workday and SmartRecruiters we can also rely on the fact that a user having access to a job means they can see applications for that job.
Appendix
SuccessFactor’s permission system uses “operators”, teams, and groups in “configuration templates” to determine what users can do. They also have role-based permissions, but they appear to be an entirely separate system. (source)
Recruiting Operators
Recruiting operators appears to refer to both a predefined set of roles a user can take on and a user who has taken on one of those roles. The set of roles includes sourcer, recruiter, coordinator, or manager and are associated with a specific job. Recruiting operators are used in configuration templates to determine what users in each role can see and do. While a user in one of these roles are aware that the job exists, they may or may not be able to see any other details about it.
We are able to batch sync what a user’s operator role is since it can be read from the job requisition object. However, we don’t know what field permissions are associated with each role.
Sources:
Recruiting Teams
This refers to a group of users in the same role. The group has the same permissions as the role they are associated with. For example, a user that is in the hiring manager team has the same permissions as an individual hiring manager.
We are able to batch sync the members of a team assigned to a given job requisition object. However, I couldn’t find a way to get the teams directly and like with individual operators, we don’t know what field permissions are associated with each team beyond being able to see that the job exists.
Sources:
Recruiting Groups
Recruiting groups are used to limit who is allowed to be picked as an operator for a job. They can also be used to automatically add users to a job via XML configuration. (source)
For our use cases, I don’t think it matters if we know that someone is able to be a primary operator or that they will automatically get added to a recruiting team. We only care if they are an operator or part of a recruiting team, which is provided to us by the job requisition API.
Additionally, there is something called “dynamic recruiting groups” which is used to define which users can edit which fields on a candidate in the candidate profile template. The group is created via a set of rules to determine which users belong in the group.
We are able to batch sync which users belong to what dynamic groups (/DynamicGroupDefinition $expand groups). However, aren’t able to see which fields they have access to.
Role based permissions
Role based permissions define what users in different roles can see or do. From what I can tell, these “roles” are not the same as the operator roles, recruiting teams and recruiting groups above. This doesn’t seem to be as relevant for our current purposes of determining whether or not a user has access to a job, application or candidate and what they can see or do on those objects. It appears to be more about administration (e.g. “Allows users to insert job application permissions on applications.” (source)) rather than product usage.
Here is the Role Based Permissions API.