Roles, Permissions & Users

This is what turns a single-admin app into something a whole team or customer base can use safely — who can see what, who can change what, and what a brand-new sign-up is allowed to do on day one.

1. Add a user profile collection

Role-based access needs a collection that represents "a person" — with name, email, and role fields. If your schema doesn't have one yet, the Schema Builder shows a one-click button for it (Add User Profile collection, or Seed User Profile if your schema is empty). This adds a ready-made collection with those fields already in place — you don't build this one by hand.

You can add your own extra fields to it too (age, department, phone number — anything about a person), the same way you'd add a field to any other collection. Note that name, email, and role themselves can't be deleted or renamed — the rest of the app depends on them.

2. Open Roles & Permissions

This page shows one card per role, and a permissions matrix per collection:

Column	Meaning
Full	Unrestricted access — view, create, update, and delete, all at once
View	Can see records in this collection
Create	Can add new records
Update	Can edit existing records
Delete	Can remove records

There's always an admin role, reserved and unrestricted — it can't be renamed, deleted, or have its permissions unchecked.

Click New Role to add another (support staff, sales, viewer — whatever fits your app), tick the boxes for what it can do in each collection, and click Save & Apply. Changes take effect immediately.

3. Set the default role for sign-ups

Next to each non-admin role, there's a Default on register option. Whichever role you pick here is the one automatically assigned to anyone who signs up through the app's own registration form — nobody chooses their own role, and nothing they submit can override this.

If your app has roles but no default is set, a yellow warning appears on both the Roles & Permissions page and the app dashboard. Don't ignore it: without a default, a new sign-up starts with no role at all, and once roles exist a person with no role can't do anything until you assign one by hand.

Starting from a template?

An app created from a marketplace template gets that template's roles and its default role, as long as the author had set one when they saved the template. The built-in starter templates don't include roles, so set them up yourself.

4. Manage individual users

The Users page lists everyone who has signed up. From here you can:

• Change anyone's role at any time, directly from the dropdown in their row.
• Add a user yourself — click Add User, enter their email, name, and role (plus any extra profile fields you've added). A temporary password is generated automatically and shown once, ready to copy and send to them.

Restricting people to their own records

Under View, Update and Delete there's an Own only checkbox on each row. Tick it and that role can only see, change or delete the records they created. A resident sees their own visitor requests, not everyone's.

• Own only on View also limits Update and Delete. You can't change what you can't see, so those two boxes show as ticked and locked.
• Full access is always unrestricted, so Own only doesn't apply when Full is ticked.
• It's enforced by the server, not just hidden in the app: people only ever receive the records they're allowed to see.

Records assigned to someone

"Created by" isn't always the right test: staff often create a record for someone else. When an Own only box is ticked, an Owner identifier dropdown appears under the collection name. Pick a field that points at a person, and "own" also includes every record assigned to them through it:

Pick this	When
A reference field straight to your user profile collection, e.g. assigned_to	The record points directly at a person
A path through another collection, e.g. resident.user	The record points at a resident record, and that has a user reference to the profile

A path can go up to two steps. Once it's set, a record belongs to whoever it leads to as well as to whoever created it. To hand a record to someone, just set that field on it.

Things to know:

• One identifier per role, per collection, and it has to be a single reference (not a multi-reference).
• Anyone who can edit a record can change who it's assigned to, because there are no per-field permissions.
• Records created by the server on your behalf (imports, webhooks) belong to the app's admin account, so an Own only role only sees them if they're assigned.
• Lookups and counts see only what that person sees. A "next invoice number" or a "must be unique" check over a collection can come out wrong for someone limited to their own records.
• The dropdown lists only fields that can lead to a person. If it says No person field available, add a reference to your user profile collection (or to a collection that has one) first, then reload the page.

When someone's access changes

Roles are enforced on the server the moment you click Save & Apply. Each person's device then catches up on its own: when the app opens, when it comes back online or to the foreground, and every few minutes while it's open. It isn't instant.

• If their access grew (View newly granted, or Own only turned off) the missing records are fetched.
• If it shrank (View removed, or Own only turned on) the records they can no longer see are removed from their device, including offline.
• Records taken away from them (reassigned to someone else) disappear the same way.
• Their own unsynced changes are never thrown away. If someone has edits waiting to sync in a collection they've lost access to, the server will now refuse them; the app keeps them and shows a warning pointing to Pending sync, so they can review or discard them.

Inviting people vs. open sign-up

In App Configuration, the Allow Registration toggle controls whether people can create their own account from the app's sign-up screen at all. Turn it off for an invite-only app, where every account is created by you from the Users page instead.