You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/docs/roles-and-permissions/field-permissions.mdx
+16-14Lines changed: 16 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ tags: ['Field', 'Permissions']
5
5
keywords: ['Field permissions', 'NocoDB field permissions', 'NocoDB roles', 'NocoDB permissions', 'NocoDB field permissions overview']
6
6
---
7
7
8
-
<Callouttype="info">Field permissions are available in NocoDB cloud- Team plan onwards and Self hosted Enterprise plans</Callout>
8
+
<Callouttype="info">Available on NocoDB Cloud from the **Team** plan onwards, and in **Self-hosted Enterprise** editions.</Callout>
9
9
10
10
Field permissions in NocoDB allow you to control who can edit values in specific fields in a table. This feature is particularly useful for managing sensitive data or ensuring that only authorized users can modify certain information.
11
11
@@ -27,27 +27,29 @@ You can assign different levels of access to each field. The available options a
|**Editors & up**| Members with **Editor**, **Creator**, or **Owner** roles *(default)*|
29
29
|**Creators & up**| Members with **Creator** or **Owner** roles |
30
-
|**Specific users**|A custom list of selected members|
30
+
|**Specific users**|Selected members or teams |
31
31
|**Nobody**| No one can edit this field |
32
32
33
33
By default, users with **Editor** role and above can edit data in all fields in a table.
34
34
* Select **Creators & up** to prevent editors from editing values in this field.
35
35
* Select **Nobody** to disable editing values for all users in this field.
36
-
* Select **Specific users** to grant access only to selected members.
37
-
> Only members with **Editor**, **Creator**, or **Owner** roles are available for selection in the dropdown for specific user selection.
36
+
* Choose **Specific users** to allow only selected members or teams to edit this field.
37
+
38
+
<Callouttype="info">Only members and teams with **Editor**, **Creator**, or **Owner** roles can be selected for specific access configuration.</Callout>
- Field permissions do not affect the ability to view records in the table. Users with access can still view all records, but their ability to edit values in specific fields will be restricted based on the permissions set.
44
-
- Field permissions are applied at the field level, meaning they affect all records within that table for the specified field. Cannot be set for individual / selected records.
45
-
- Field permissions are independent of table permissions. You can set field permissions without enabling table permissions, and vice versa.
46
-
- Field permissions also restrict the ability to edit values via API calls and shared forms.
47
-
- Field permissions can be set for all field types except for the following field type, as these fields are calculated / system fields and cannot be edited directly.
- For **LinkToAnotherRecord** field type, only the source table LTAR field permission will suffice to control the ability to edit the field (add / remove links). The related table LTAR field permissions will not be accounted for. For example: Country [has-many] City, if the user has permission to edit the Country table, they will be able to add / remove links to City table records in the Country table, even if they do not have permission to edit the City table related LTAR field.
50
-
</Callout>
42
+
### **Additional Notes on Field Permissions**
43
+
44
+
* Field permissions **do not control field visibility** — users with access can still view all field data, but their ability to edit values in specific fields depends on the configured permissions.
45
+
* Permissions are applied at the **field level**, affecting all records in the table for that specific field. They cannot be configured for individual or selected records.
46
+
* Field permissions operate **independently** of table permissions. You can configure field permissions without enabling table permissions, and vice versa.
47
+
* Field permissions also apply to **API calls** and **shared forms**, restricting the ability to modify field values through these interfaces.
48
+
* Field permissions can be set for all field types except the following, as these are **calculated or system fields** and cannot be edited directly:
* For **Link to Another Record (LTAR)** fields, only the source table’s LTAR field permission determines editability (add/remove links). The related table’s LTAR permissions are not considered.
51
+
**Example:* If **Country** has many **Cities**, and a user has permission to edit the LTAR field in the **Country** table, they can add or remove links to **City** records from the **Country** table — even if they lack edit permission for the **City** table’s corresponding LTAR field.
Table permissions in NocoDB let you control who can create or delete records in each table. This feature helps teams enforce stricter access control while still allowing collaborative workflows.
8
+
Table permissions in NocoDB allow you to control who can create or delete records in each table. This feature helps maintain data integrity while supporting flexible and collaborative workflows.
9
9
10
-
<Callouttype="info">Table permissions are available in NocoDB cloud- Team plan onwards and Self hosted Enterprise plans</Callout>
10
+
<Callouttype="info">Available on NocoDB Cloud from the **Team** plan onwards, and in **Self-hosted Enterprise** editions.</Callout>
11
11
12
12
## Enabling Table Permissions
13
-
To configure permissions on a specific table:
13
+
14
+
To configure permissions for a specific table:
15
+
14
16
1. Click the `⋯` icon next to the table name in the sidebar.
|**Editors & up**| Members with **Editor**, **Creator**, or **Owner** roles *(default)*|
31
-
|**Creators & up**| Members with **Creator** or **Owner** roles |
32
-
|**Specific users**| A custom list of selected members |
33
-
|**Nobody**| No one can perform this action |
37
+
By default, members with the **Editor** role and above can create and delete records in a table.
34
38
35
-
By default, users with **Editor** role and above can create and delete records in a table.
36
-
* Select **Creators & up** to prevent editors from performing these actions.
37
-
* Select **Nobody** to disable record creation or deletion for all users.
38
-
* Select **Specific users** to grant access only to selected members.
39
+
* Choose **Creators & up** to restrict these actions to creators and owners.
40
+
* Choose **Nobody** to disable record creation or deletion entirely.
41
+
* Choose **Specific users or teams** to grant access only to selected members or teams.
39
42
40
-
> Only members with **Editor**, **Creator**, or **Owner** roles are available for selection in the dropdown for specific user selection.*
43
+
<Callouttype="info">Only members and teams with **Editor**, **Creator**, or **Owner** roles can be selected for specific access configuration.</Callout>
- Table permissions does not affect the ability to view records in the table. Users with access can still view all records, but their ability to create or delete records will be restricted based on the permissions set.
47
-
- Table permissions are applied at the table level, meaning they affect all records within that table. Cannot be set for individual / selected records.
48
-
- Table permissions are independent of field permissions. You can set table permissions without enabling field permissions, and vice versa.
49
-
- Table permissions also restrict the ability to
50
-
- create or delete records via API calls and
51
-
- create records using shared forms.
52
-
</Callout>
47
+
48
+
### Additional Notes on Table Permissions
49
+
50
+
* Table permissions **do not control record visibility** — users with access can still view all records. However, their ability to create or delete records depends on the configured permissions.
51
+
* Permissions are applied at the **table level** and affect all records within that table. They cannot be defined for individual records or specific subsets.
52
+
* Table permissions function **independently** of field permissions; each can be configured separately.
53
+
* Table permissions also apply to:
54
+
* Record creation or deletion via **APIs**, and
55
+
* Record creation through **shared forms**.
53
56
54
57
## Permissions Overview
55
58
56
-
Permissions overview provides a quick summary of the current table & field permissions in a consolidated tabular view.
59
+
The permissions overview provides a consolidated summary of table and field permissions across the base.
57
60
58
61
To access the permissions overview:
59
-
1. Go to base homepage (Click `Overview` in the sidebar).
62
+
63
+
1. Go to the base homepage (click **Overview** in the sidebar).
Subsequently, you can select the table for which you want to view the permissions overview. The overview will display field permissions in addition to table permissions, allowing you to see who can create or delete records in each table, as well as which fields are editable and by whom.
68
+
Select the table you want to review. The overview displays both table and field permissions, showing which members or teams can create or delete records and which fields are editable by whom.
0 commit comments