Learn how to set up and manage Table-level permissions in SmartSuite. This guide covers the steps to configure permissions, explains available options, and provides practical use cases.
Plan Availability | Professional, Enterprise, Signature |
Permissions | Administrators and Solution Managers can view and change Table permission |
Overview of Table Permissions
Table permissions allow Solution Managers to customize access to specific tables within a solution. By default, tables inherit permissions from their parent solution, but you can override these settings to restrict or expand access for individual users or teams.
Key Points:
Inheritance: By default, tables inherit permissions from the solution.
Optimistic Access: Members or Teams with multiple permission levels receive the highest assigned level.
Overrides: Solution-level permissions are overridden, not supplemented.
Why Use Table Permissions?
Table permissions are valuable when:
You need to limit access to specific data within a broader solution.
You want certain teams or members to work on only one or two tables without seeing others.
You aim to safeguard internal processes or sensitive data from general access.
Available Table Permissions
Permission | Description |
Full Access | Members or Teams can create, edit, and delete all records. |
Editor | Can create and edit their own records but only view records from others. |
Contributor | Can create and edit their records; can edit others only if assigned in the "Assigned To" field and can view all other records |
Assignee | Can view and edit only records they’ve been assigned to. |
Assignee+ | Can create and edit their assigned records and new auto-assigned records. |
Commenter | Can view all content but cannot create or edit records. |
Viewer | Has read-only access to records without making changes. |
As with Solution-level permissions, Members with the Administrator role or who have been added as Solution Managers for the current solution always have access to all data and configuration options within the Table.
Quick Table Permission Details
Permission Title | Paid User? | Create Records | View Records | Edit Records | Delete Records | Mark as Favorite | Follow | Comment |
Full Access | ✅ | Y | Y | Y | Y | Y | Y | Y |
Contributor | ✅ | Y | Y | Assigned Content | N | Y | Y | Y |
Assignee | ✅ | N | Assigned Content | Assigned Content | N | Assigned Content | Assigned Content | Assigned Content |
Assignee + | ✅ | Y | Assigned Content | Assigned Content | N | Assigned Content | Assigned Content | Assigned Content |
Commenter | ✅ | N | Y | N | N | Y | Y | Y |
Viewer | ✅ | N | Y | N | N | Y | Y | N |
Configuring Table Permissions
Follow these steps to set up permissions for a Table:
Open the solution containing the table.
Click the table name and select the downward arrow.
From the dropdown menu, click Permissions.
In the Table Permissions dialog:
Select Override Solution Permissions.
Choose members or teams to add.
Assign appropriate access levels from the available options.
Click Add for each group or individual.
Click Save to apply the changes.
Note: Leaving "Override Solution Permissions" selected without specifying members or teams restricts access to Administrators and Solution Managers only.
Changing Table Permissions
To update existing Table permissions:
Open the Table Permissions dialog for the table.
Make the necessary changes:
Add Members or Teams: Select new members or teams and assign permissions.
Edit Access Levels: Click the current permission and choose a new level.
Remove Members or Teams: Hover over the row and click the X to delete.
Click Save to confirm updates.
Practical Scenarios and Use Cases
1. Department-Specific Restrictions
Scenario: HR needs exclusive access to sensitive employee data. Solution: Configure the HR table to allow only HR team members with "Full Access."
2. Controlled Contributor Access
Scenario: Sales team members should update only their own leads. Solution: Assign "Contributor" permissions to the Sales table for team members.
3. Assignee-Only Workflow
Scenario: Developers should only work on assigned tickets. Solution: Use "Assignee+" permissions for the Development table, ensuring new tickets are auto-assigned.