Loading the documentation…
A role grants its members access to Lake and Warehouse tables, and you choose who holds it. Use this page to change a role's table access and its members; to create a role or change its description, icon, permissions or status, see Roles and permissions.
Only the tables you changed are sent. Removals are processed before additions, and a large edit is processed in batches. Save Changes stays off until you change something, and reads Saving... while it saves; rows are disabled while the save runs.
Save Changes can succeed while a few tables keep their old access. When that happens, DataMind OS warns Some changes were not applied: "N of M table changes kept their previous access. Reopen Tables to review."
If you close the editor with pending edits, DataMind OS asks Unsaved Changes before closing: "You have N unsaved changes. If you leave now, your changes will be discarded." Choose Keep editing to go back, or Discard changes to lose them.
A table cannot be removed from a role while a Mind owned by that role uses it. The save fails and names the tables: Cannot remove role "<role>" from permission groups: table "<table>" is used in Minds: [<names>].. Change those Minds so they no longer use the tables, or leave the tables ticked.
The built-in Admin role's table permissions cannot be changed, and a save is refused with Cannot update table permissions for admin role; its row menu offers no Manage Tables, and its role panel has no Manage link. While the editor loads it shows Loading table permissions...; if the load fails, it shows Failed to load table permissions with a Retry button that reloads the page.
The footer shows how many changes are pending. A reset control next to the search drops your pending ticks; its tooltip reads Reset pending changes, or No pending changes when nothing is pending. Save changes stays off until something changes, and reads Saving... while it saves. Selected only narrows the list to the users the role already has, and Select all and Clear apply only to the list you can see.
Closing with pending changes asks Unsaved changes with the same "You have N unsaved changes. If you leave now, your changes will be discarded." body and the same Keep editing and Discard changes choices. If the save fails, the editor shows the reason and returns the list to its last saved state, so a refused save never looks successful.
When a search or filter hides everyone, the editor says No users match your criteria with "Try a different search or clear the selected-only filter."; when nobody can be assigned, it says No users available with "There are no users that can be assigned to this role." The platform's own admin account and its other seeded system accounts are left out of this list, so the search will not find them.
The role panel shows both lists without opening an editor.
The Manage and Edit actions appear only if your permissions allow you to update roles, and the tables editor itself needs Edit Role Table Permissions. Without it the editor is refused with Access denied..
Nothing has changed yet, or a save is running. The button turns on as soon as you tick or untick a table, and the members editor works the same way.
Yes, if you chose Discard changes. Both editors ask first when edits are pending: Unsaved Changes in the tables editor and Unsaved changes in the members editor. Keep editing returns you to the editor, and Discard changes drops the pending edits.
A Mind owned by this role uses that table. The save fails and names the tables; remove those tables from those Minds first, or leave the tables ticked, then save again.
The built-in Admin role always has full access, so its table permissions cannot be changed. The role menu offers no Manage Tables for it, and its panel has no Manage link; its members always have full table access. A save is refused with "Cannot update table permissions for admin role".
They set the user's BI access level through this role. BI Viewer can view and run queries and view dashboards and alerts; BI Editor can also create and edit queries and dashboards, see a query's source, and set schedules. A user's reporting account is provisioned from their roles: each role carries its own viewer and editor access and its own data source, so report access follows the role. A user whose reporting account is not there yet is skipped by reporting operations until an administrator resynchronises it; see Passwords, locks and limits for a user. Choose one next to each assigned user while you edit the role's members. Members of the built-in Admin role get no switch.
The platform's own admin account and its other seeded system accounts are left out of this list, so the search will not find them either.
Only on what you can see. Select all and Clear apply to the rows currently shown, after the search and Selected only filters. Selected only narrows the list itself: to the users the role already has in the members editor, and to the tables the role currently has in the tables editor.
In the members editor, a failed save returns the list to its last saved state and shows the reason, so a refused save never looks successful. In the tables editor, the error appears inside the editor and your ticks stay put.
The save went through, but some of the table changes kept their previous access. Reopen the tables editor to review the tables the message counts, then set those tables again.
Lake tables and Warehouse tables; the editor shows both columns. Table access is separate from permissions, and it decides which tables the role's members can use. See SQL dialect and data scope.
In the role panel: Tables lists the role's tables and opens one when you click it, and Assigned users lists its members. Both show a count badge, and longer lists get a search box.