How access works: user, role, permission
Access in Sonta is a short chain: a user belongs to a role, and the role carries a set of permissions. You don't grant abilities one at a time — you give a person a role, and the role decides what they can do. Roles and permissions live inside one business and never cross to another.
Requirements: anyone can be a member; granting or changing access needs a role that can manage users and roles — the built-in Admins role has this by default.
Access in Sonta is a short chain: a user belongs to a role, and the role carries a set of permissions. Nobody is granted abilities one by one — you give a person a role, and the role decides what they can do. Understanding those three words and how they connect is all you need to reason about who can see and change what.
The three pieces
A user is a person who has been invited into a business and accepted — a member of it. A permission is a single, specific ability: create a collection, edit an entry, change an automation, view a collection without being able to change it. Permissions are fine-grained on purpose, so access can be exact rather than all-or-nothing. A role is a named bundle of permissions — the layer that keeps this manageable. Instead of handing out dozens of individual abilities per person, you group them into a role once — an Admin role, a Sales role — and then assign the role.
How they connect
The chain runs one way: a user is placed in a role, the role holds permissions, and the user can do exactly what those permissions allow — no more. Change the role's permissions and everyone in that role changes with it; move a user to a different role and their access changes at once. This is why roles exist: they let you reason about access by job, not by person. "What can the sales team do?" becomes a question about one role, not about five separate people. Every business starts with a built-in Admins role that can do everything, including manage the other roles — that is the role the founder lands in, and the one that grants access to everyone else.
Why it is built this way
Two reasons. First, exactness: because permissions are granular, you can let someone work a collection day to day without also letting them restructure it, or give a contractor sight of one area and nothing else. Second, scale: roles keep access from sprawling into a per-person tangle. When a new person joins, you do not reconstruct their abilities from memory — you place them in the role that matches their job and they inherit the right access at once. The same logic covers more than people: an agent acting through the connection works within a role's permissions too, so an AI assistant can be scoped exactly like a teammate.
Isolation between businesses
Roles and permissions live inside a single business. A person's role in one business says nothing about another — access does not leak across the boundary that separates one business from the next. Someone can be an admin in one and have no access at all to another, which is what makes it safe to run several operations, or several clients, under one roof.