Required permissions set to perform specific actions

General Concepts

Most SaaS are in essence a user interface built on top of a collection of APIs, performing actions commonly known as CRUD. The SaaS server processes the Create, Update and Delete commands, whereas the user interface or CLI Reads information from the server. Both the user interface and the server then perform a set of actions with data from CRUD.

SaaS permissioning allows or prevents you from calling certain CRUD APIs. Optable has simplified its permissioning to its purest expression.

<object>.view permissions allow you to read from the server (e.g. list audiences, get details of a specific audience)

<object>.edit permissions allow you to write to the server (e.g. create a role, update a role, delete a role)

Permissions Detail

These are the current permissions available within Optable.




List your DCN's analyses, and view analyses details (description, partner, audience, etc.) & reports


Create, edit, end, archive your DCN's analyses



List your DCN's matches, and view matches details (description, schedule, etc.)


Create, run or archive your DCN's matches



List your DCN's audiences, and view audience details (description, business rule, etc.)


Create, update or archive your DCN's audiences



List previous exports of an audience


Export your DCN's audiences to a set destination

Data Subject Requests


List your DCN's data subject requests to date (access, erase, unsuppress)


Make data subject requests (access, erase, unsuppress) within your DCN



List your DCN's accounts, and view account details (name, email, role, etc.)


Edit (name, role), deactivate, delete accounts within your DCN



List existing roles and get their associated permissions


Create, update or delete roles within your DCN

Creating a Role Without View Accesses

A service account or an engineer performing a task through the CLI don't necessarily require view permissions. For instance, exporting an audience to a set destination (optable-cli audience export <id> <destination id>) only requires exports.edit permission. It therefore makes sense to allow users to create roles without view permissions.

A user without view permissions will not be able to complete certain tasks through Optable's user interface. Optable currently enforces view permissions when creating a role through the UI, and strongly suggests you to be very careful when creating roles with missing view accesses, and to properly name and describe them to avoid errors and frustrations.

Permissions Relationships

When missing a permission on an object, you may end up unable to perform an action through the user interface that you reasonably thought was possible. Below is a list of relationships between permissions that you should keep in mind.

  • Clean rooms:

    • You need audiences.view and partnerships.view permissions to perform clean room operations such as a match or an analysis.

    • You need partnership.view to see active analyses.

  • Audiences:

  • Sources:

    • You need audiences.edit permission to create an audience automatically from a file upload.

  • Privacy:

    • You need partnerships.view permission to manage differential privacy, and see monthly privacy budget usage.

    • While you can list previous data subject requests (DSR) with dsr.view permission, and create DSR with dsr.edit permission, you need both permissions to perform DSR - Access request. Lacking dsr.edit will prevent you from making the access request, while lacking dsr.view will prevent you from getting the result.

  • Accounts:

    • You need roles.view permission to invite, create or update an account, as you need to assign a role.

Sensitive Permissions

Please bear in mind that certain permissions are very powerful and the best practice is to grant these to only a few authorized users in your organization. Below is a list of sensitive permissions:

  • roles.edit allows a user to modify their own role, and grant themselves full admin permissions.

  • accounts.edit allows a user to re-invite themselves to the DCN, using another email address, and assign an admin role to their new user. This can be done through the CLI even without roles.view permission.

  • dsr.view only lists historical DSR to date, without their detail. dsr.edit allows you to perform erasure and unsuppress requests. Giving both permissions to a user allows them to perform a series of access requests. This can be dangerous if the user is trying to learn information about a specific user for personal motives.

  • exports.edit permission is to be given with caution, as the user can export all the DCN raw data to their personal cloud storage for personal motives.

Last updated