User role examples

User roles are a predefined set of permissions that can be applied to a user or a group of users, so they will have the same access permissions. To discover more about configuring detailed access controls including user roles, see Detailed access control. Access can be provided to users by assigning them the same role (i.e., the same predefined set of permissions) for instructions on how to assign user roles to users, see Managing users

In this section we will examine examples of user roles with different types of access to the system, illustrating various access levels to the system, based on real-world scenarios.

High-level overview

There are three (3) main methods with which you can control user management, based on the actions a user can perform, the features they can access and the data they can see.

• Granted operations: focus on the actions a user can perform. This includes user management, label management, data set management, as well as the use of analyses and task runner actions.

• System feature availability: focused on features that a user can see. This provides access to full features, including Compensation assistant, Job evaluation, Pay equity analysis, Pay bands and Labels.

• Access controls:

  • Per-label access controls: limits access to data with labels. Provides access only to datasets, presets, Compensation assistant and benchmarking to which the label(s) that the user has access to are applied.

  • Per-record access controls: limits access to specific employees within a dataset. Provides access only to groups of employees within a dataset, but not to full datasets or analysis results.

  • Per-column access controls: limits access to hide specific columns within a dataset. Hides specific columns from datasets or analyses.

Minimum recommended profile permissions

For practitioner users (employees responsible for uploading & running pay gap analyses), beqom recommends that the following minimum permissions described are always enabled:

Granted operations:

• Upload new datasets

• Run analyses

• Delete datasets

Minimum granted operations

System feature availability:

• Dataset and analysis overview

Minimum system feature availability

Access controls:

• Access to all datasets

Minimum label access controls

• Access to all records

Minimum record access controls

• Access to all columns

Minimum column access controls

Scenario 1: the admin user

The admin user is a user who most likely needs access to all data and to user management. This user is the application admin or the central reward manager. They serve as the admin user within the system, have comprehensive access to all datasets and features.

This role has the responsibility of creating and managing user accounts.

For this role, beqom recommends that you grant the following permissions:

Admin user permission set

Scenario 2: the local rewards user

The local rewards user is a role with limited access to local data with labels.

In this scenario, you are a global organization enrolling in pay equity analysis across all countries. As the global manager, you aim to limit the access of each local HR team to their respective country's dataset only, ensuring they can't see data from other countries. The settings below show how this is done for the local HR for both Germany and Sweden, who should only see data for the German and/or Swedish population.

In this situation, there two possibilities for you to manage the visibility of data.

Option 1: OR logic

OR is an inclusive logical operator. When it is used, the user then has access to all the defined conditions. In the following example, the user will have access to the items that have either of the Germany and Sweden labels:

OR logic applied to labels

Option 2: AND logic

AND is a restrictive logical operator. When it is used, the elements that the user sees must match all of the defined criteria.

A common use case for this might be a combination of scope of role (e.g. country) and state of the dataset or analysis (such as "draft" vs "final"), or the year the data or analysis relates to (for example, 2025). In this case, the AND logic allows you to ensure users only see the final dataset and analysis for their country scope. Access is restricted to datasets containing both required labels. If a dataset has only one of the two labels, it will not appear in the user's data overview.

In the illustration below, the user will have access only to the elements that contain BOTH the Germany and Final labels.

AND logic applied to labels

Scenario 3: the local HRBP or manager with limited access to a subset of data

This type of user usually has limited access to a subset of the data.

In this scenario, you want your HRBPs to have access to the data about the employees in their specific department. The settings below illustrate how to do this for an HRBP or Manager who is only responsible for the Finance & HR department.

In this case, the access control settings should be defined as follows:

Local HRBP permission set

This is an note/information message.

This logic remains functional only if newly uploaded datasets maintain a consistent schema. Specifically, column headers and job family names must match the original format exactly.

This is an note/information message.

Users with restricted access (such as those limited to a specific department within a country set) cannot perform new analyses. Because a full dataset is required to properly configure and train the regression model, these users are restricted to the Analysis Overview to review existing outputs and insights. The common use case is that customers use this to involve local HRBPs to review raise suggestions, by overriding the commenting on the individual employees and potentially overwriting the suggested raise, since they have additional local knowledge for their scope of employees.

Scenario 4: the local HRBP or manager with limited access to specific columns

In this scenario, local managers have visibility into the full dataset with the exception of certain sensitive rating columns (such as Talent or Performance). Access to these specific fields can be restricted exclusively to the Rewards team.

In this situation, the access control settings would like this:

Column-based access control

This is an note/information message.

This access grant method is highly sensitive to schema changes. If you rename a column in your upload (for instance, changing "Performance Rating" to "Performance Evaluation"), you must update the corresponding field in the permissions settings.

Scenario 5: the recruiter

In this section, we will examine the use case of recruiter with limited access to the Compensation Assistant.

In this scenario, you want your people in recruitment to have access to the Compensation Assistant so that they can get fair salary suggestions for new employees and see how that salary suggestion compares to comparison groups and external benchmarking data, without them being able to see details for individual employees. You have attached the “Compensation” label to all data sets that this user should have access to.

The relevant access control settings would look as follows.

This is a tip message.

In this particular situation all settings under Granted operations can be disabled.

Recruiter permission set

General recommendations regarding the Compensation Assistant

For large organizations using the Compensation Assistant, consider the following:

• Make sure that the permission Grant access to all compensation assistant presets is enabled if you want your recruiters to be able to select from centrally defined presets. A common scenario is a "New hire" preset that automatically includes preselected employee and comparison groups. In this case, you might want to grant the Grant access to all compensation assistant presets permission, under Per-label access controls.

• For organizations with an established global job architecture and pay philosophy, the most seamless way to empower recruiters is by preconfiguring the underlying compensation module used for predicted compensation as follows:

  • Define your established compensation model as the default model, using the Set as default option, admins can ensure that the correct compensation model is automatically used when running the compensation assistant. Please note that the system only supports one default compensation model.

  • Disable the permission Compensation assistant: Set reference analysis per session, under System feature availability, to lock the underlying model used for compensation predictions.

  • You can account for regional pay variations by incorporating country or location as objective factors within your compensation model, as illustrated in the following figure:

Compensation model with location factored in

This is an note/information message.

While you can select any country, individual pay data remains strictly confidential. The compensation assistant only displays aggregated data, such as pay ranges, averages, and medians based on current employee figures.

• t is also possible to use custom labels, such as Compensation assistant - Germany, to guide recruiters toward the correct model when no default model has been set.