Configuring Scope Based Permissions
Scope-based access control lets you customize what users and groups can see and do within the platform, ensuring a more focused, efficient, and secure experience.
By assigning permissions based on specific scopes (such as modules or features), users only see the sections relevant to their role. This reduces clutter and confusion while safeguarding sensitive data by limiting access to only those who need it.
With this, you can streamline workflows, enhance security, and ensure each user has the right tools at their fingertips—without unnecessary distractions.
Overview of Scopes and Permissions
A scope represents a specific part of the platform, such as a module or feature. Permissions are granted based on these scopes:
- View permissions: Allow users to see content within the scope.
- Edit permissions: Allow users to modify or manage content within the scope.
If no permissions are assigned to a scope, the user or group won’t have access to it at all.
Example Use Case: Data Subject Requests (DSR)
Let’s take the Data Subject Requests (DSR) scope as an example to understand how scope based permissions work.
Users with both View and Edit permissions will have full access to the DSR module. They will be able to see all incoming requests and take necessary actions. This level of access is typically assigned to team members responsible for managing privacy requests, ensuring they can fully interact with the data subject requests.
In contrast, users who are assigned only View permission for the DSR scope will have read-only access. They can still view the DSR module and browse the incoming requests, but they will not be able to take any actions. This limited access is useful for roles that need visibility into privacy request statuses without requiring the ability to modify or act on them.
On the other hand, if a user is not granted either View or Edit permissions for the DSR scope, the entire module will be hidden from them. These users won’t even know the DSR module exists, as it won’t be visible in their interface. This is ideal for roles that do not need to interact with or view sensitive privacy request data, ensuring a cleaner and more focused user experience.
Configuring Permissions for Users and Groups
Permissions can be configured from the Users or Groups page. The process for assigning permissions is the same in both cases.

Step-by-Step Guide
- Go to the Users or Groups Page: Navigate to the Users or Groups page from the dashboard, depending on whether you are configuring permissions for an individual user or a group.
- Select the User or Group: Click on the specific user or group whose permissions you want to configure. This will open their detail page, where you can adjust permissions.
- Locate the Permissions Section: In the user or group details page, scroll down to the Permissions section. Here, you will see a list of scopes with their current View and Edit permission settings.
- Add a New Permission: To grant permissions for an additional scope, click the Add Permission button on the right side of the page. This will open the Add Permission modal, as shown below.
- Select the Scope and Permissions: In the Add Permission modal: - Select the scope from the dropdown list.
- Choose the permissions you want to assign—either View or Edit (or both).
- Save Permissions: Once you've configured the desired permissions, click Create to add them. The new permission will now be visible in the permissions table.
- Review and Save Changes: After reviewing all the permissions, click Save to apply your changes.
Permission Inheritance
Permissions set at the user level take precedence over group permissions. This means that if a user has specific permissions assigned to them individually, those will override any permissions inherited from a group they belong to.
For example, if a group has View permission for the Data Subject Requests (DSR) scope, but an individual user in that group has Edit permission for the same scope, the user will be able to both view and edit DSRs. Even though the group as a whole is limited to viewing, the user’s individual permissions allow them to take actions such as approving or rejecting requests.
This flexibility ensures you can fine-tune access, giving users specific permissions based on their unique responsibilities, while still leveraging group-level settings for broader access control.