Everything about rules happens in Studio. This page shows where.

​
1. The Policies page

Access → Policies in the sidebar. This is where your named rules live: conditions you give a name and reuse anywhere a rule is accepted; equality checks are pushed down to SQL.
Studio Policies page with one policy named own_orders

Access → Policies lists your named rules. Here one rule, own_rows, already exists.

Click New policy (top right) to make one.

​
2. The New policy sheet

New policy sheet with Name, Description and a Who passes builder

The New policy sheet: details, then Who passes.

The sheet has two parts:
  • Details: Name (letters, digits, dashes and underscores, like own_rows) and an optional Description.
  • Who passes: the condition builder. Checks on record fields are pushed down to SQL, so filtered lists stay paginated correctly. Secret keys always pass.
At the top, New here? Start from a worked example and adjust it. → Use example fills the sheet with a working rule so you can see how one looks.
Policy builder with Is signed in and Owns the record (field) user_id joined by AND

After Use example: signed-in users who own the record.

Create policy saves it. The button stays dimmed until you’ve added a name.

​
3. Add rules and groups

  • All of / Any of / None of at the top say how the rules below combine.
  • Each row is one check. The first menu chooses the kind of check; the next boxes take its values.
  • + Rule adds a check. + Group adds a nested set with its own All/Any/None.
  • The small ✕ at the end of a row removes it.
The rule type menu open in the builder

The kind-of-check menu: Is signed in, Has role, Has permission, Owns the record, Uses a secret key, Signed in with 2FA, Key has scope, Caller kind is, Compare values, Check a value, Nobody.

The next page explains each kind: Condition builder.

​
4. A table’s Access tab

Data → open a table → Access. The place you attach rules to a table’s five actions. A table with no API of its own says Not in the API: the table has no API of its own yet, so your app’s users can’t reach it. Only Studio and secret keys can. Define its columns to open it up.
Access tab saying Not in the API

A table that isn't in the API yet: Access has nothing to set until it has columns.

Once a table has columns, the Access tab shows Quick access set and a rule picker for See the list, Open one record, Add records, Edit records, Delete records. See Database access.

​
5. The rule picker on other pages

Buckets, realtime channels, routes and event subscriptions all use the same picker.
New bucket sheet with Access section and five rule pickers

A bucket's Access section: Public bucket, then Who may read, upload new objects, list, replace and delete.

​
6. The request inspector

Project → Activity, then a request. Each request records which rule decided and why: how you debug a refusal. See Debugging rules.

​
7. The API Explorer

Data → API Explorer sends a request as a real person (sign in with their email and password under Application-user authentication) so you can see what they can do. See API Explorer.

​
A good workflow

  1. Pick the closest quick set or built-in on the table.
  2. If you need more, build a custom condition and use Save as policy to give it a clear name.
  3. Test with the Explorer as two different people.
  4. Check Activity to confirm which rule decided.
  5. Reuse the named rule on other tables.

Condition builder

Each kind of check.

Named rules

Save and reuse.