Datastore-level permissions decide whether a security group can see or write to a table at all. Field permissions go one level deeper — they let you hide or read-only certain columns for certain groups while keeping the rest of the table accessible. This is one of the most useful tools in the platform's permission toolkit because it means one datastore can serve multiple roles with different visibility, without cloning data.
Why field permissions matter
A real-world example. HR keeps a Staff datastore that has columns for:
- Public info: name, email, photo, job title.
- Management info: department, manager, start date, role grade.
- Compensation: salary, bonus, benefits package.
- HR-only: performance ratings, disciplinary notes, exit interview notes.
Without field permissions you'd need three or four separate datastores, each holding the appropriate subset, plus glue code to keep them in sync. With field permissions, one datastore serves them all — HR sees everything, line managers see the management info, sales reps see only the public 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. Switch to the Field Permissions tab.
The matrix shows every field of the datastore down one axis and every security group across the other. Each cell has a dropdown with three options:
- Read — can see the field's value.
- Write — can set the value on new rows.
- Edit — can change the value on existing rows.
(In practice you'll often grant Read+Write+Edit together, or just Read, depending on the field's intended use.)
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.
That's a huge efficiency gain. A datastore with 20 fields and 10 groups has 200 possible combinations, but you'll usually have under 20 actual field-permission rows — covering only the exceptions.
Where field permissions take effect
Permissions are applied consistently across every surface the data is rendered on:
1. Auto-generated forms
Fields without read access don't appear in the New or Edit form. Fields with read-only access (read but not write) appear but are disabled. Fields with no access at all aren't even rendered into the page HTML.
2. Browse views and data lists
Restricted fields are stripped from the column list before render. A user who can read fields A, B, D sees columns A, B, D in their browse view; field C is silently omitted.
3. The API
API calls from a user without read access to a field get back the row with that field omitted from the response. Same rules — the missing field isn't error-flagged, it just isn't there.
4. Email templates and document templates
Merge tokens for restricted fields render as empty strings. So if you accidentally embed ##AMDATA_salary## in a template that's sent to non-HR recipients, they just see a blank space rather than the actual value.
Three real-world examples
Example 1: Salary field on a Staff table
Datastore-level default for HR: Read+Write+Edit. Override entries:
- Direct Managers group → Read only on the Salary field.
- All Other Staff → No Access on the Salary field.
Example 2: Internal Notes field on a Customer table
Datastore-level default: Read for All Users (everyone needs to see customer details). Override entries:
- Customer Success Team → Read+Write+Edit on Internal Notes.
- Everyone else → No Access on Internal Notes.
Example 3: Edit-only-by-status field on a Ticket table
The Status field on a Tickets table. Datastore-level default: Read for All Users. Override entries:
- Customer Service Team → Read+Write+Edit on Status.
- Everyone else (including the requester) → Read only.
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.