Policies

Policies control access to records in a Resource.

They answer questions like: Which customers can this user see? Can this person update invoices? Should this role see every field, or only a safe subset?

Policies are different from Roles and Permissions. Roles and Permissions describe what someone is allowed to do across the app. Policies describe which records and fields they can access inside one Resource.

Where Policies Live

Policies are configured from the Security area of a Resource.

Use them when access depends on the data itself. For example, a sales rep might be allowed to view Customers, but only the customer records assigned to them.

Use case	Policy example
Account ownership	Customers can only see records connected to their own account.
Team assignment	Sales reps can only update customers assigned to them.
Sensitive finance data	Support users can view invoices but cannot edit payment fields.
Education portals	Teachers can only see students enrolled in their classes.
Public data	Visitors can view published records without logging in.

Access Levels

Every Policy has an access level.

Access level	What it means
Protected	The policy applies to authenticated users from a selected authenticatable Resource.
Public	The policy can apply without a logged-in user.

Protected policies are the most common. They are used when a record belongs to a user, employee, student, customer, partner, or another kind of logged-in person.

Public policies are useful for published content, public directories, intake forms, and other experiences that should be available before login.

Scopes

Scopes define which actions the Policy grants.

Scope group	Actions	Example
Read	List records, view one record, count records, aggregate records.	A customer can view their own tickets.
Write	Create, update, validate, or bulk-create records.	A student can update their profile.
Delete	Delete or restore records.	A manager can archive tasks in their department.
All access	Grant every supported action.	System administrators can manage all customer records.

Use the narrowest scope that matches the job. A user who only needs to view invoices should not also receive update access.

Data Tasks and Required Scopes

When a workflow uses Data tasks, the Resource Policy must grant the matching scope for the Resource being used.

Data task	What it does	Required Policy scope
Create record	Creates one record.	Store
Create many records	Creates multiple records.	Store many
Find record	Loads one record.	Show
Search records	Lists or searches records.	Index
Count records	Counts matching records.	Count
Aggregate metrics	Calculates totals, averages, or grouped metrics.	Aggregate
Validate record	Checks record values against the Resource schema.	Validate
Update record	Changes an existing record.	Update
Update or create record	Updates a matching record or creates a new one.	Update or Store
Delete record	Deletes one record.	Destroy
Attach, detach, or sync relation	Changes a relationship on a record.	Update

If a workflow might create or update depending on what it finds, give it both Store and Update access, or use an All Access policy for trusted admin workflows.

Bulk delete workflows first search for the records that match the workflow criteria. Make sure the user can access the records being selected, and use normal delete flows when you need stricter per-record delete controls.

Filters

Filters decide when a Policy applies and which records it grants.

Filter	Evaluated against	Purpose
Authenticatable filter	The signed-in user's record.	Decide whether this Policy applies to this user.
Record filter	The Resource record being accessed.	Decide which records this user can access.

For example, a Customer policy might use the signed-in customer's record as the authenticatable, then only allow records where customer_id matches that user's account.

A Sales policy might apply only to users whose department is Sales, then allow customer records where the owner is the signed-in user.

Field Visibility

Policies can also control which fields are visible.

That means two people can access the same record but see different information.

User type	Visible fields
Customer	Invoice number, due date, total, payment status.
Support agent	Invoice number, status, customer name, notes.
Finance user	Invoice number, customer, total, payment status, refunds, internal adjustments.

Field visibility can be unconditional or conditional. Conditional visibility is useful when a field should only appear when a rule matches, such as showing approval notes only after a request has been reviewed.

How Policies Combine

Policies grant access. They do not subtract access from each other.

If more than one Policy matches, Diagonal combines what they grant:

Policy set	Result
One policy grants access to assigned records.	The user can access assigned records.
Another policy grants access to records in the user's region.	The user can access assigned records or regional records.
One matching policy allows all fields.	The user can see all fields for records that policy grants.
Multiple matching policies list specific fields.	The visible fields are combined.

Be careful with broad policies

If a matching Policy has no record filter, it can grant access to all records for the selected scope. Use clear filters for sensitive Resources.

Common Patterns

Pattern	How to model it
Users see their own records	Protected policy with a record filter matching the signed-in user's record.
Managers see team records	Protected policy with an authenticatable filter for managers and a record filter for their team.
Admins see everything	Protected policy for administrators with broad scopes and no record filter.
Public content	Public policy with read scopes and a record filter like published status.
Field-level privacy	Policy field visibility that hides sensitive fields from non-privileged users.

Policies Versus Page Security

Policies protect Resource data. Page and workflow security protects access to experiences and actions.

Use both together:

Layer	Controls
Page security	Who can open a page.
Workflow security	Who can run a workflow or workflow step.
Resource policies	Which records and fields a user can access.

For sensitive apps, do not rely on page visibility alone. Add Policies to the Resources that contain sensitive data.