Access in DataMind OS comes from three things: the roles a user holds, the permissions in those roles, and the tables those roles can use. Read this page when a user cannot see or change something, before you change anyone's roles.
A user can hold one or more roles. Each role gives its members two things:
| Part of a role | What it controls |
|---|---|
| Permissions | What members can open and change, such as viewing users or running workflows. |
| Table access | Which Lake and Warehouse tables members can use. |
A user gets every permission from all of their active roles, combined. If one role grants a permission and another does not, the user still has it. A role that is deactivated grants nothing to its members.
Permissions decide more than pages. Sidebar entries, buttons and menu items, such as Publish, Export, Share or Impersonate user, appear only when a permission allows them. Hidden controls are a convenience, not the protection: the platform checks every action again on the server.
Roles and users use the same permission editor. Permissions are grouped into categories, shown as tabs such as Users & Roles, Administration and Query Editor. Only categories that contain permissions appear, and if the set of categories changes, the editor starts again at the first one.
Each category has three tiers:
| Tier | What it contains | Can you select it? |
|---|---|---|
| High-Level | Broad presets that bundle related permissions. | Yes |
| Standard | Task-focused permission sets. | Yes |
| Granular | Individual low-level permissions. | No, they are shown for reference |
Selecting a permission works like this:
Turning a permission off also removes the permissions inside it, unless another permission you keep on still includes them. A branch that is only partly granted shows a partial state.
When the platform checks access, it expands each preset to the individual permissions inside it. If a permission is added to a preset later, every role that holds the preset grants it without you saving the role again.
Search permissions to jump to... finds a permission by name. You get up to eight results, each showing its category and how many permissions it covers. Use the arrow keys and Enter to pick a result, or Escape to close the list; selecting one moves the editor to the permission and highlights it briefly.
The footer has Cancel and Save changes. Cancel is disabled while a save is running, and Save changes stays off until you change something. Viewers see Close instead. While the editor loads, it shows Loading permissions; if it cannot load, it reads "Failed to load the permission catalog. Please try again."
The built-in Admin role holds every permission: its editor shows all of them as granted and locked, with no Save button.
Granular permissions are read-only. Grant them through a Standard or High-Level permission that contains them.
Each user has one of two permission modes. You switch the mode in the user's permissions editor.
| Setting | What it does | Default |
|---|---|---|
| Role-based | The user has the permissions of their assigned roles. You cannot edit them on the user. | On for new users and for users created by single sign-on |
| Custom | You set the permissions on this user. They replace the permissions of the user's roles. | Used only when you set it |
A Custom user has only the permissions you set on that user. Changes to the user's roles do not change them. To return to role permissions, switch the user back to Role-based.
To change the mode:
In Role-based mode, the Inherited line names the roles that supply the permissions. Switching back to Role-based and saving returns the user to their roles' permissions; nothing is stored on the user.
If you can view a user but cannot change them, or the user's permissions are inherited from roles, the editor is read-only and the button at the bottom reads Close. Everything else on the user's panel is described in Users.
To see who has a permission across the company, click the Audit button in the Users or Roles toolbar. It downloads an audit report as an Excel file.
A few things follow one person instead of their roles:
A refused action answers with "Access denied. Required permission(s):" followed by the permission or permissions you need. When one of several permissions is enough, they are joined by OR; when all are needed, by AND.
If your sign-in is missing or has expired, the answer reads "Authentication required". Sign in again and repeat the action.
For the messages in full, see Administration troubleshooting.
Table access decides which Lake and Warehouse tables a role's members can use. Administrators set it on each role with Manage Tables. For the steps, see Roles and permissions.
Table access is separate from permissions. A user can have a permission for the Editor and still see no tables. See SQL dialect and data scope.
To open the list of users, you need View Users. To open the list of roles, you need View Roles. Which Administration tabs each permission opens is listed in Administration.
Permissions are shown by their names, such as View Users, in the editor and in the audit workbook. Quote the name when you report an access problem.
Each area has its own permissions. See Who can do what in the Lake, Who can do what in the Warehouse and Who can do what with Minds. For the names of every preset, see Permission reference.
Both roles count. The user gets every permission from both active roles, combined. A role that is inactive grants nothing.
That user is probably on Custom permissions, which replace the permissions of their roles. Open the user's Permissions and switch the user to Role-based.
Granular permissions are read-only. Turn on the Standard or High-Level permission that contains it.
No. A preset is on only while every permission inside it is on. The other permissions in the preset stay on.
Part of the branch is granted. A permission shows a partial state while some, but not all, of the permissions inside it are on. Turn on the rest and it switches on by itself.
Opening the Editor and seeing tables are separate. The Editor is controlled by Query Editor permissions. The tables a user sees depend on the table access of their roles. Ask an administrator to check table access on each of the user's roles.
Every role assigned to the user is deactivated. Activate one of those roles, or assign the user an active role.
The sidebar and buttons show a permission change after the user reloads the page or signs in again. Ask the user to reload the page.