Data permissions
Who can read and write each table: public, signed-in users, only their own rows, or admins. Checked on the server for every request.
Last updated September 17, 2026
On this page
Every table has two rules: who may read it and who may write to it. They are checked on the server for every request, whether it comes from a page, from a backend function or from the API. Hiding a button is presentation; a permission is the lock.
Read levels
| Read | Who sees the rows |
|---|---|
| Public | Anyone, signed in or not. For content the app curates: a menu, a catalogue, listings, a blog. |
| Signed-in users | Anyone with an account in your app. |
| Only their own rows | Each signed-in user sees only rows they created. Admins see all. The right choice for orders, bookings, journals, saved items, messages. |
| App admins only | Only users whose role is admin. Settings, pricing rules, audit trails, a moderation queue. |
Write levels
| Write | Who can create rows |
|---|---|
| Public | Anyone, including visitors who are not signed in. |
| Signed-in users | Anyone with an account. The default. |
| App admins only | Only admins. For content everyone reads and only staff edits, pair it with a wider read level. |
Editing and deleting
- Changing or deleting a row always needs a signed-in user.
- An ordinary user can only change or delete rows they created themselves. An admin can change or delete any row.
- A row created by an anonymous visitor has no owner, so it can never be edited from the app afterwards. That is fine for a contact form and wrong for anything a visitor must come back and revise, which needs accounts.
Common patterns
| What it is | Read | Write |
|---|---|---|
| Public content you author (menu, catalogue, blog) | Public | App admins only |
| Each customer's own orders or bookings | Only their own rows | Signed-in users |
| A contact or enquiry form | App admins only | Handled by intake forms |
| Staff-only settings | App admins only | App admins only |
| Team notes everyone can see and add to | Signed-in users | Signed-in users |
Changing permissions
Open the table under Database, change the Read and Write selectors, and press Save access. The change applies immediately to the running app. You can also ask the builder, which sets permissions when it defines a table and describes them back to you.
Checked by the security scan
The security scan reads every table's permissions alongside the code and flags a table that is more open than the app treats it.