Tables and access rules
How your backend decides what visitors and members can read and write, why a new table starts locked, and how Willo proves the rules work.
On this page
Your backend keeps data in tables, much like spreadsheets: a bookings table with a row per booking and a column per detail. The important question for each table is not what it holds but who can see and change it. Access rules answer that.
Three kinds of caller
Every request to your backend comes from one of three places:
| Caller | Who it is | Typical access |
|---|---|---|
| Visitors | Anyone on your site who isn't signed in. | Read public things (published products, menu items); submit forms. |
| Members | People signed in to your site. | Their own rows: their profile, their orders, their bookings. |
| The backend itself | Your backend functions and Willo, working for you. | Everything. |
Isolation between businesses is automatic: no other Willo business can reach your data. Access rules are about the line between your visitors, your members and you.
New tables start locked
When Willo creates a table, access rules are switched on for it, and a table with no rules is invisible to visitors and members. That is the safe default: a forgotten rule means a feature that doesn't work yet, never data that leaks.
Willo then adds the narrowest rules the feature needs. Some common shapes:
- Contact form or waitlist: visitors may add a row; nobody can read the table from the site. You read submissions by asking Willo.
- Public catalogue: visitors may read rows marked as published; only you change them.
- Member data: each member can read and change only their own rows.
Columns that decide what someone may do, such as an "is admin" flag or a role, need extra care. A rule that lets members edit their own row would also let them edit those columns and promote themselves. Willo checks for this when it writes a rule and fences those columns off, or keeps them in a separate table members can't write.
Proving a rule, not just writing it
A rule that looks right can still leak. So after creating or changing a table that holds personal or private data, Willo tests it from the outside:
- It reads the private columns as a visitor, and expects to be refused or to get nothing back.
- For member data, it reads one member's rows as another member, and expects nothing.
- It checks the legitimate path still works: a member still sees their own rows.
Ask Willo to show you what it ran and what came back. "The rule is in place" describes what was written; a test result describes what your site can actually do.
What needs your confirmation
Adding a table, a column or an access rule runs straight away. These stop for you to confirm on a card first:
- writing, changing or deleting rows directly,
- deleting a table, removing or retyping a column, or removing or rewriting an access rule,
- changing table-level permissions for visitors or members,
- running SQL that Willo or your own AI agent wrote.
If you have chosen Always allow for one of these kinds of change in an earlier card, Willo doesn't ask again for that kind.
Reading your data
Chat is where you read your data. Ask: "show me the last 20 bookings", "how many people joined the waitlist this month?", "list everyone who joined the waitlist this week". Willo reads the data and answers. Reading is free and never changes anything.
Willo can also read your data the way a visitor or a particular member would see it, which is the quickest way to answer "can strangers see this?".
Related: Change your database safely, Add a table and show it on the site, Security model.