Roles

When you invite someone into your workspace or one of its scenes, you give them a role: viewer, member, admin or owner. The role decides what they can do there. What they can see is up to the scene's layers.

Owners can do everything admins can. Only an owner can make someone an owner, take that role away, or delete the workspace.

Most people are members or viewers. Make someone a member when they build or change the scene, and a viewer when they use it: the front desk, a branch manager reading the numbers, a client you report to. Their jobs are paid from the workspace's allowance, like everyone's.

A viewer's job can't change the scene or your records

A viewer asks the agent what they need to know: which members haven't paid this month, what a supplier replied yesterday, how today compares to last week. The agent reads through the accounts the team shares, the same way it would for you, so a viewer can learn anything those accounts can read, including what no cell shows. An account someone connected as themselves, like their own inbox, stays in their Private layer and out of other people's jobs.

The agent can't add or edit a cell for a viewer, update a record in your ERP or CRM, or start a schedule. When a viewer asks for a change, it tells them it can't, and a member can make it. A cell's buttons follow the same rule: a viewer can press one, and it runs with a viewer's access.

A viewer's messages wait for a member

A viewer's job can draft an email, a chat message, a text or a calendar invite, and the draft waits in the job. The scene's members are notified, and any one of them can approve it, with the recipients and the exact text in front of them, or reject it. This holds even in a scene that lets members' messages go out without asking.

A member's job asks them before it writes to your systems

Members change cells, connect accounts and set up schedules without waiting for anyone. When a member's job is about to send an email or change a record in your ERP, it shows them the exact change first, and they approve it themselves. A scene can let routine writes go without asking; approvals covers how.

Admins decide who is in the workspace

They invite and remove people and change their roles, up to admin. A workspace always keeps at least one owner, so the last one can't be removed.

A role in the workspace carries into its scenes

Someone with a role in the workspace holds it in every scene open to the whole workspace, and the accounts the team shares are available in all of them. The workspace's owners and admins reach every scene in it, including the ones kept to their own members.

A role given in one scene can raise someone there and never lowers them: a viewer of the workspace can be a member of the one scene they run, while a workspace admin stays an admin in every scene.

Someone you invite into a single scene, and not the workspace, sees that scene only. Their jobs use the accounts linked to that scene, never the rest of the workspace's.

Your own roles decide what someone sees

Some scenes have more than one audience: a supplier who should see their own orders, a crew that works one part of the scene. For those, the scene's blueprint names a role, like Supplier, and lists the layers it can read.

A named role changes what someone sees and nothing else. What they can do still comes from the four roles above, so a supplier you invite as a viewer reads the supplier layer and changes nothing in it.

What's next

• Layers: who sees what, by where it sits.
• Approvals: how writes wait for a person.
• Identity: how a job borrows the access of whoever started it.

Updated 2026-10-16