Row-level security in the Tadabase builder
Decide which records each user can see and change, everywhere: on your app's pages, through the API, and in front ends you build yourself.
On this page
Row-level security (RLS) decides which records each signed-in user can read, create, update and delete. Roles say who someone is; RLS says which rows they can touch. Because the rules are checked on our servers for every request, they hold however the data is reached: your app's pages, the API, or a front end you or your AI agent build yourself.
Where to find it #
Open the Data Builder, choose a table, and open its Security tab. Hover Data Builder in the left menu and choose Row Level Security Overview to see every table's settings in one place. If the Security tab says RLS isn't available on your plan, it starts on a higher plan.
When to use it #
Use RLS whenever two users with the same role must not see each other's data:
- A client portal where each client sees only their own projects, invoices and files.
- Case managers or sales reps who each see only their own caseload or deals.
- Franchises, branches or customers sharing one app, each seeing only their own records.
- Any app where you let people sign in to a front end you built yourself. There, RLS is the only thing between a user and every record in the table.
How it decides #
- Nothing is allowed until you allow it. Once RLS is on for a table, a user sees no records until a policy lets them. If your app suddenly shows empty tables after you turn RLS on, a policy is missing.
- Policies add access. Each policy says who it's for, what they may do (read, create, update, delete) and which records it covers.
- The highest priority wins. When several policies match a user, only those with the highest Priority are used; lower-priority ones are ignored. Give policies for the same people the same priority if they should add up.
- Writes are checked too. Creating or updating a record is allowed only if the record, with the new values, is one the user may change. A user can't edit a record into someone else's hands.
Turn it on for a table #
- Enable it On the table's Security tab, open Row Level Security and turn on Enable row level security.
- Choose where it applies The Default Behaviour setting decides where the rules are applied: App Level (your app's pages), API Level (the end-user API, which Vibe apps and your own front ends use), or Both. Choose Both unless you have a reason not to.
- Choose who sees everything Users with a role in Bypass Roles see every record. Keep this to admin roles.
- Add policies Add a policy for each kind of access (see the next section). Save.
Write a policy #
The policy wizard asks four questions:
| Question | Choices |
|---|---|
| Who can use this access? | Specific Roles, Specific Users (users matching conditions), Any Logged in Users, or Anyone (Public) (people who aren't signed in). |
| Which operations are allowed? | Any of Read, Create, Update, Delete. |
| Which records can they access? | All Records, Records connected to the logged in user, or your own conditions. On the Users table, Allow Only Me lets each user reach only their own user record. |
| Which fields should be shown or hidden? | All fields, or hide some (Restrict the following) or show only some (Only allow the following). Hidden fields can be shown as stars, dots, blurred or blank. |
Conditions can compare a field to the signed-in user: is logged in user, is not logged in user, is connected to logged in user, and is connected to any logged in user's roles, plus the usual is, contains, is blank, higher than and date checks.
Finish with a Name, a Description and a Priority.
Common patterns #
| You want | Policy |
|---|---|
| Each client sees only their own records | Who: the Client role. Operations: Read. Records: Client is connected to logged in user. (The table needs a connection to Users, such as a "Client" field.) |
| Staff see only records assigned to them, and can edit them | Who: the Staff role. Operations: Read, Update. Records: Assigned To is logged in user. |
| Managers see everything | Add the Manager role to Bypass Roles, or add a policy with All Records. |
| Users can read and update their own profile | On the Users table. Who: Any Logged in Users. Operations: Read, Update. Records: Allow Only Me. |
| A public list anyone can read | Who: Anyone (Public). Operations: Read. Records: your conditions, for example Published is Yes. |
Using RLS with the API and your own front end #
Your users can sign in through the API with their own email and password, from a Vibe app or a front end you build. Their requests then run as them, with your RLS rules applied. No API key or secret is involved, so this is safe to use from a browser or a mobile app.
- Turn on the master switch On the Users table, open Security > API and turn on Allow RLS Permission for API Access. Until it's on, the end-user API refuses every request, including sign-in.
- Optionally limit who can use it Under Who can use this API?, choose specific roles or users, any logged-in user, or anyone. Others can't sign in through the API.
- Turn on RLS for every table you'll use Each table must have RLS enabled with Default Behaviour set to API Level or Both. A table without it is refused, never exposed.
Test it as your users #
You see everything while building, so the builder can't tell you whether a rule works. Create a test user for each role, sign in to your app (or your front end) as each one, and check both directions: they see what they should, and they don't see what they shouldn't. Try opening another user's record directly; it should come back as not found.