Plan-level differences
Advanced Permissions are available on every AI Table plan — only the number of custom roles you can create differs.| Entitlement | Free | Business | Enterprise |
|---|---|---|---|
| Custom roles in Advanced Permissions | 3 | 50 | 100 |
Overview
The Owner and Admins of an AI Table can turn Advanced Permissions on or off, and configure roles and members. By creating roles with different settings, admins can assign access and operation permissions on tables, dashboards, views, fields, and records independently — fine-grained permission management that gives you stronger data security guarantees. Common scenarios:- Salespeople can view and maintain only their own customer info — they can’t see other reps’ data.
- Leadership can see overall ops data and roll-up reports, but doesn’t edit individual records.
- Stat fields (amount, score, summed totals) are admin-only — regular members can’t see them.
- Project members only see the projects they’re on.
- Department leads see only their own department’s tables and dashboards.
- Regular collaborators can add or update records, but can’t change table structure.
Glossary
- Owner (default role): the highest-permission holder for an AI Table. The creator is the owner by default; if ownership is transferred, the new recipient becomes the owner.
- Admin (default role): the default management role under Advanced Permissions. Collaborators with the doc-level Manage permission automatically become admins. Admins can edit everything in the AI Table and configure Advanced Permissions, automation, and dashboards.
- Editor (default role): editors can view and modify data, including adding, editing, and deleting records. They cannot change table structure or configure Advanced Permissions, automation, or dashboards. Admins can adjust an editor’s effective permissions; the actual capabilities follow the role configuration.
- Viewer (default role): viewers can only view data. They cannot add, edit, or delete records, nor modify table structure, permission settings, automation, or dashboard configuration. Admins can adjust a viewer’s visibility; the actual visible scope follows the role configuration.
- Custom role: a role created by an admin. Each role is a permission group; the permissions configured for the role apply to every member in it.
- Member: the subject of permissions, not necessarily a single person — can be a specific person, a group, or a department.
- Table permission: access and operation permissions on a table in an AI Table.
- Dashboard permission: access and operation permissions on a dashboard in an AI Table.
- Record permission: view and edit permissions on each row in a table.
- Field permission: view and edit permissions on each column in a table.
- View permission: access and operation permissions on views in a table.
Doc permissions vs Advanced Permissions
Doc permissions
In the top-right of an AI Table, click Share to set sharing and collaboration for the current AI Table.
Sharing scope and collaborator permissions can be combined freely; admins also get more granular config options.
Three sharing scopes: collaborators only, public within organization, public on the internet.
Four collaborator permissions: Manage, Edit, View / Download, View only — assignable to individuals, groups, or departments.
Manage cannot be assigned to people outside the organization.
Advanced Permissions
The AI Table Owner or any collaborator with the Manage permission can turn on Advanced Permissions. Advanced Permissions complement doc permissions — they let you control access scope and operations more precisely. By creating different roles, you can decide exactly who can view or edit each table, and further control which records, fields (and the corresponding cells), views, dashboards, automations, and apps each member can reach.Doc permissions vs Advanced Permissions
When Advanced Permissions is on, a collaborator’s effective permissions are the result of combining Advanced Permissions with doc permissions. Within Advanced Permissions, if a member is in multiple roles, record permissions and field permissions are first unioned across roles; that result is then intersected with the member’s doc permissions to produce the effective scope. Examples:| AI Table Advanced Permissions | Doc permissions | Effective permissions |
|---|---|---|
| Alice can edit all records via Role 1 | Alice has Edit | Edit all records |
| Alice has View | View all records (read-only) | |
| Alice can edit her own customer records via Role 1; can view all customer data via Role 2 | Alice has Edit | View all customers, edit her own |
| Alice has View | View all customers (read-only) | |
| Alice can edit all project records via Role 1; can view stat fields via Role 2 | Alice has Edit | Edit all project records and view stat fields |
| Alice has View | View all project records and stat fields (read-only) | |
| Alice can view the Amount field via Role 1; can view the Customer Contact field via Role 2 | Alice has Edit | View Amount and Customer Contact fields |
| Alice has View | View Amount and Customer Contact fields | |
| Alice can edit all records via Role 1 | Alice has no doc permission | Alice can’t access the AI Table |
Advanced permission types
| Permission | Description |
|---|---|
| Table permission | Defines a role’s overall access and operations on a table. Full control: can change table structure, configure fields, and edit every record. Edit: can add, modify, and delete records, and view data — cannot change table structure or field config. View: can only view records — cannot add, modify, or delete. No access: no access at all; the table doesn’t appear in AI Table for this role. Note: table permission applies to the entire table and doesn’t change with views. View add/edit/delete is also covered at the table level. |
| Record permission | Controls whether collaborators can add, edit, view, or delete records, and lets you finely scope which records they can act on or see. You must set a table permission for the role first. When the table permission is Full control, the role gets all-record view + operation rights by default — no extra record-permission setup is needed. When the table permission is Edit: Add and delete record permissions Can add: allows record creation. Can delete: allows record deletion. Editable / deletable record scope All records: any record in the table. Records related to the member: only records the member is connected to, including: records the member created records where a person-type field includes the member (the table must have a person-type field) Specific records: scope by filter — for example, by Created by or Status, with multiple filters combined. Other record permissions: Can view: records outside the editable/deletable scope are read-only. No access: out-of-scope records are hidden. When the table permission is View: Only the visible-record scope is configurable. Visible record scope: All records: every record in the table. Records related to the member: only records connected to the member, including: records the member created records where a person-type field includes the member Specific records: scope by filter — multi-filter supported. Records that match the filter are shown; others aren’t. Other record permissions: Can view: out-of-scope records become read-only. No access: out-of-scope records are hidden. |
| View permission | Defines a role’s access and operations on the views of a table. Requires a table permission to be set first. Full control: view all views; add, modify, and delete views. View only: view contents only; no add / modify / delete. Visible view scope: choose all views or specific views. |
| Field permission | Controls whether collaborators can add, edit, or view a field’s cell content. Requires a table permission to be set first. All fields editable: the role can view, edit, and add records for every field. Specific field permissions: per-field scope. In specific-field mode, each field can be set to: Can view: read the cell content only. Can add: write only on record creation; can’t modify existing data. Can edit: view, add, and edit the field’s cell content. Note: field permissions can only be configured when the table permission is Full control or Edit. |
| Dashboard permission | Overall dashboard permission Full control: change dashboard structure, configure widgets, and edit content. View only: view dashboard content. No access: can’t see the dashboard. Dashboard data permission Controls how chart data is computed and rendered. When some data is restricted, the chart is hidden: if the collaborator can’t see all (or part of) the data the chart depends on, the chart isn’t displayed. Stats by viewer permission: “one dashboard, different views” — charts only count data the viewer can see. Stats by full data: “one dashboard, same view” — charts count every record in the table. |
| Automation permission | Controls a role’s ability to manage, edit, publish, and toggle automations. The role must have Manage on every table, and only members inside the organization can configure automations. |
Turning on Advanced Permissions
In the top-right of the AI Table, click Advanced Permissions to turn it on.⚠️ Once Advanced Permissions is on, the original Editor and Viewer defaults stop applying — collaborators temporarily lose access to the AI Table until they’re assigned a role.
Turning off Advanced Permissions
Click the toggle in the Advanced Permissions dialog to turn it off.⚠️ Once off, custom-role permissions stop applying, but the custom roles, members, and configurations are preserved. You can turn Advanced Permissions back on at any time and pick up where you left off.
Adding a custom role
In Advanced Permissions, click + Add role on the left.
After adding the role, configure its permissions on each table and dashboard. For example, give the Salesperson role access and operation permissions on the Monthly Sales table.
You can rename, duplicate, or delete custom roles.
Adding members to a custom role
In the top-right of the custom role, click + Add members. You can add specific people, groups, or departments — added members get every permission configured on the role.
Changing the role-wide access mode
By default, with Advanced Permissions on, only Admins and custom-role members can access the AI Table. Existing Editors / Viewers temporarily lose access until they’re assigned a role.
You can switch to All role members can access. In this mode, you set a default role that applies to members not assigned to any custom role. By default that role is Editor or Viewer per their doc permission, but you can pick any custom role.
After this, every member with doc permission but no custom role assignment gets the default role’s permissions intersected with their doc permission.
Preview (member’s effective permissions)
Quickly confirm a given member’s final access scope and operation rights under the current configuration. The system combines role permissions with doc permissions and shows you, in real time, what data they can see, what actions they can perform, and what’s restricted — so you can sanity-check after configuring.
