In SmartRecruiters, controlling access to sensitive data and functionalities is crucial for ensuring that the correct users have access to the correct jobs, candidate data, and areas of the recruiting system. Access groups provide a flexible way to manage permissions for users with specific system roles.
The use of access groups with system roles provide customers with a vital tool for managing user permissions and ensuring data security. They allow administrators to define specific levels of access for different system roles within the organization.
When thinking of the overall permissions granted to a user, you will have to consider both the system role, and whether an access group is needed.
| Feature | System Role | Access Group |
| Definition | A predefined set of permissions or capabilities (examples: create a job, edit a candidate, access settings). | A dynamic layer of permissions applied to a system role, defined by specific org fields(examples: country, department). |
| Example |
|
|
| Control Level | System-level access and feature permission. | Filtered visibility and specified access. |
Note
Remember, default and custom system roles define system-level access to jobs, hiring team and analytics.
In many cases, recruiters don’t need access to all jobs, but just those that they are responsible for, such as line of business or business unit. Using access groups, a layered filter of permissions can be applied in addition to the system role that a user receives. Access groups can be used for default (except for Admin and Extended) and custom system roles defined in the system.
For example, a recruiting user can be assigned the default system role of Standard, which gives them the ability to create jobs, and access to hiring teams and certain analytic features). However, the Standard role, by default, does not grant permissions to all jobs. Without an access group assigned, this recruiter would only see jobs for which they are added to the applicable Hiring Team. If the access group is set to Sales jobs in France, the recruiter can see all jobs and applicants for the jobs where they’re on the Hiring Team, in addition to all other sales jobs located in France.
Example use case:
A company operates in the market under three different brands- A, B and C - in 2 different countries - Germany and France. Each brand has assigned recruitment teams by country who should only be able to access jobs in their own country and brand. To achieve this, 6 access groups would have to be created to match this criteria:
- Access group 1 - Company A, Germany
- Access group 2 - Company A, France
- Access group 3 - Company B, Germany
- Access group 4 - Company B, France
- Access group 5 - Company C, Germany
- Access group 6 - Company C, France
Let's now consider that, for each country, there's a head of recruitment activities that needs to have access to all jobs in that country regardless of brand or any other criteria. This would require 2 more access groups, one per country. Each access group would then need to be assigned by an admin to the correct user(s) via the user profile.
If a user is given multiple permissions on the same job(s), the highest permissions will be granted. For example:
- If User A has limited access to all jobs, and full access to Sales Jobs in France, the user will have access to all jobs under that access group and limited access to the remaining jobs.
- If User B has limited access to all jobs, and view only access to Sales Jobs in France, the user will still have limited access to all jobs.
