Map every user to one of the three roles. Then decide which transactions and tools they can touch by issuing invitations plus consent scopes.
Role definitions
Atlas keeps roles simple: Owner, Admin, Client. Owners typically run the brokerage or region. Admins are coordinators or staff. Clients are buyers, sellers, or vendors invited into specific transactions. Each role inherits capabilities—Owners can manage billing and tools, Admins manage transactions and files, Clients only see what they are invited to.
| Role | Capabilities |
|---|---|
| Owner | Manage billing, tools, workspaces, invite Admins/Clients |
| Admin | Create transactions, run MCP tools, invite Clients to specific deals |
| Client | Upload/download files and run approved tools within invited transactions |
Invitation flow
Owners and Admins invite users via email. Every invitation captures workspace_id, default role, and consent scopes. Clients cannot see anything until they accept and are added to a transaction.
- Owner invites Admins (workspace-level).
- Admins invite Clients (transaction-level).
- Clients confirm via secure link; consent scopes issued on acceptance.
Common decision checks
Access decisions follow a predictable set of questions. Use them in your support docs or automated tests.
| Question | Answer |
|---|---|
| Can user X upload File Y? | Yes if user is Owner/Admin of workspace OR Client on that transaction with upload scope. |
| Can user X view Transaction Z? | Only if user owns the workspace or is invited to transaction Z. |
| Can Client run Generate comps? | Only if transaction has that tool enabled and consent scopes remain active. |
Escalations & overrides
Sometimes a client needs temporary elevated access. Owners can issue time-bound overrides that expire automatically and are logged in the consent ledger. Admins can request overrides but cannot grant them.