Making a data table private or admin-only

Every table in your app has an access setting that decides who can see its rows. You can tighten it later, for example when a table that everyone could read should only be seen by you and your app's admins. Your existing data is kept when you do. There's one extra step to make it show up again, covered below.

How to change a table's access

Ask the builder in chat. For example:

Make the clients table admin-only.

Make the notes table private, so each user only sees their own notes.

When you tighten a table that everyone could read, the builder explains what will happen and asks you to confirm first. Some switches, like going from private to admin-only, don't ask, even though they also hide your existing rows until you do the step below. Either way, the change usually reaches your live app straight away. On some live apps the builder can't change access itself; if that happens, contact support.

The builder may also suggest a different setting. Admin-only is meant for data that only you and your admins manage.

To see each table's current setting, open the Dashboard tab, then Schema. Each table shows a label:

• Public: anyone can read it.
• User-scoped: each signed-in user sees only their own rows.
• Team-scoped: admin-only. You and your app's admins can read it; regular users can't read or change it directly.
• Lead capture: anyone can submit, only admins can read.
• Members only: only people with a certain role can read it.

You can also just ask the builder: What's the access setting on the clients table?

What happens to the rows already in the table

Your rows aren't deleted. Every row stays, with the same id it had before.

One thing can be lost. If the table started out private or admin-only, or tracked which user added each row, the switch can remove that record of who owned or wrote each row. The builder saves a restore point first, but if you'll need that information, export the table before you switch.

Admin-only tables belong to your app's team, so switching adds a team id field to the table. On rows that were already there, that field starts out empty. Until it's filled in, those rows won't show up in your app, not even for you.

Switching a table to private (each user sees their own rows) works the same way. Rows that were already there have no owner yet, so nobody sees them until each one is given its owner.

Make your existing rows show up again

Right after the switch, ask the builder:

Fill in the team id on every existing row of the clients table that's missing it, then tell me how many rows the app can see now.

For a table you made private, ask the builder to give each existing row its owner instead, and tell it how to work out who owns each one.

The builder saves a restore point before it changes rows, so you can undo it. Then open your app and check that the data is there. If the builder can't fill in the missing field, contact support and we'll help.

If your app has its own server code

Some apps have custom server code, often called endpoints, that the builder wrote for things like admin dashboards or scheduled jobs. After a table goes admin-only:

• Signed-in endpoints that read the table with system access (and a stated reason) can still read every row.
• Server code that writes to an admin-only table has to include your app's team id, or the write is refused.
• Public endpoints (ones that work without signing in) shouldn't read private or admin-only tables. If one does, ask the builder to make it require sign-in.

If you're not sure, ask the builder: Will any of my app's server code break if I make the clients table admin-only?

Keep private details out of public tables

Fields like email addresses or phone numbers shouldn't sit in a table everyone can read. Move them into a separate table where each user sees only their own rows, and keep the public table for what's fine to show.

A safe order to do this in

1. Move private fields out of any public table.
2. Switch one table.
3. Fill in the missing field on its existing rows (the team id, or the owner for a private table).
4. Check your app shows the data.
5. Repeat for the next table.

Your live app's users won't see a table's existing rows between steps 2 and 3, so do them back to back, at a quiet time if you can. Doing one table at a time makes it easy to spot a problem. Each message to the builder uses credits, like any other chat.

What to read next

• Roles and permissions in your app: control which users can see which pages
• Exporting your data: save a copy of a table before you make big changes