Why
- One definition. “Team member” is defined in one place, not copied onto twelve tables.
- Readable. A table that says
team_memberexplains itself. - Safer to change. You can see and test the rule on its own.
- Shareable. Teammates and reviewers read a small named object.
In Studio
Access → Policies → New policy: a Name (such asown_rows), a Description, and Who passes (the condition builder). Save.
To save a custom rule you already built inline: in the rule picker open Custom condition, build it, and use Save as policy.
Use it anywhere: in a rule picker, This environment lists your named rules.
Edit a rule on the Policies page: open it, change the condition, and save.
Naming
- Name by meaning, not mechanism:
team_member,own_rows,staff_with_2fa, notrule1. - Don’t shadow the built-ins:
public,authenticated,owner,mfa,service,deny. - Keep the description short and state the intent (“Callers in the record’s organization”).
Changing a rule that’s in use
Every place that names it picks up the new definition. That is powerful and risky:- Copy it first: create
team_member_v2and point one low-risk table at it. - Test as different users.
- Move other uses over, then retire the old one.
Removing a rule
A rule that’s still referenced will make the tables that use it refuse requests (an unknown name is an error). Replace references first, then remove it.Across environments
Named rules belong to an environment. When you promotedevelopment to production, include policies so the names resolve. A table promoted without its rule would reference a name that doesn’t exist.
Combine named rules
Named rules can appear in lists and, by name, anywhere a rule is accepted: Choose All of: the named ruleteam_member; Users with role editor in the rule picker.
A named rule’s condition can’t refer to another named rule by name; compose them in the place of use, with a list.
Rule references
All forms.
Recipes
Ready-made rules.