Datastore-level permissions decide whether a security group can see a table at all. Field-level permissions go one level deeper — they let you hide or restrict specific columns within a table the user can otherwise read or write.
This is one of the highest-leverage features in the platform for modelling real-world access policies. It means one datastore can serve multiple roles, each seeing only the fields appropriate to their job, without having to clone the data into role-specific tables.
Why field permissions matter
A real-world example. An HR team keeps a Staff datastore with rows for every employee. The columns include:
- Name, email, phone (everyone needs).
- Job title, department, manager (most teams need).
- Salary, performance rating, disciplinary notes (only HR and direct manager need).
- Bank details, tax number, national insurance number (only payroll need).
Without field permissions, you'd need three or four separate datastores or a complex set of views. With field permissions, one datastore serves them all — HR sees everything, line managers see most, sales reps see only the name/email subset, customers see nothing.
How to configure them
Open the datastore in the Architect Panel and click the Permissions button. The dialog has tabs for datastore-level permissions and for field permissions. The Field Permissions tab lists every field of the datastore down one axis and every security group across the other.
For each combination, set one of three states:
- Read — the group can see the field's value.
- Write — the group can set the field's value when creating or editing rows.
- No access — the field doesn't appear at all for this group.
Defaults and inheritance
If a security group doesn't have an explicit field-permission row, it inherits the datastore-level permission for that field. So you only need to add field-permission rows where you want to differ from the datastore default.
Practical implication: don't configure field permissions for every field × every group. Configure them only for the exceptions. A typical datastore has 20 fields and 10 groups; that's 200 possible combinations, but you'll usually have under 20 actual field-permission rows because most fields inherit the default.
Where field permissions take effect
Permissions apply consistently across every place the data is rendered or accessed:
- Auto-generated forms: fields without read access don't appear; fields with read-only access are shown but disabled.
- Browse views: restricted fields are stripped from the column list before render.
- Custom Query Views: the platform applies the same restrictions to query results.
- The API: calls from a user without read access to a field get back the row with that field omitted.
- Email templates: merge tokens for restricted fields render as empty strings.
Three patterns that come up often
Pattern 1: Sensitive column visible to one group only
Salary on a Staff table: HR has Read+Write, Direct Managers have Read, everyone else has No Access. Three explicit field-permission rows; everyone else inherits the datastore default (typically Read on the rest of the columns).
Pattern 2: Field editable only by certain roles
Status field on a Tickets table: Customer Service can Read+Write (they update the status). All Users can Read (they see the current status). Customers (external) can Read (on their own tickets, via row-level security).
Pattern 3: Field hidden from everyone except admins
Internal Notes field on a Customers table: Customer Success Team has Read+Write. Everyone else has No Access. Admins see it on the auto-generated edit form; customers, sales reps, and the API don't even know the field exists for that row.
Note: Field permissions don't affect SQL queries written in Custom Query Views or in raw PHP. If you're hand-coding access, you're responsible for applying the same restrictions in your query. The platform applies field permissions at the auto-generated form and API layer; bypassing those layers bypasses the permission too.