People & sharing
Members, invitations, roles, seats, and per-resource audiences.
People
The People page has three tabs: Members, Invitations, and Roles. An invite pairs an email with a built-in role (owner, admin, or member); acceptance is a public link that lands in the org. Membership itself runs on Better Auth organizations — the browser calls it directly, and there is no Assivy members REST endpoint.
Inside a workspace, Add member puts someone who is already in the account straight in, with a role, skipping the email round-trip. Anyone new must be invited, guests can't be added this way, and only an owner can add another owner. The account itself has no Add member — invite there.
A member can hold several roles at once, built-in and custom; Edit member roles is a checklist, and the grants add up.
Roles
Four roles are built into the code and can't be changed or deleted: owner, admin, member, and guest. Guest is the role of chat visitors — anonymous widget traffic and people arriving over the SSO embed bridge — and is kept minimal on purpose.
| Resource | Owner | Admin | Member | Guest |
|---|---|---|---|---|
agent, source | all | all | read | read |
folder, entity, datasource, tool, skill, widget | all | all | read | — |
setting | read, update | read, update | read | — |
job | read, update, delete | read, update, delete | read | — |
workspace | all | read | read | — |
integration, modelProvider, evaluation | all | all | — | — |
trace (traces, metrics, logs, dashboard) | read, delete | read, delete | — | — |
billing | read, update | — | — | — |
"All" is create, read, update, delete. Members can browse and use the
workspace but change none of it. agent:read also covers org-wide appearance
and reading agent memory; agent:update covers writing them.
Custom roles are per-org { resource: actions[] } grants built from the same
catalog, at Settings → Roles (also the People page's third tab). A name is 1–48
lowercase letters, digits, - or _, and freezes at creation. Two rules keep
the graph sane: you can only grant permissions you hold yourself, and edits
reach holders the next time they sign in. Deleting a role orphans its holders
— the member row keeps the name, but the next sign-in resolves it to nothing.
Seats
The plan caps the people in an account. A seat is one person with a membership in the account or any of its workspaces, counted once however many they belong to. It's checked when an invitation is sent — a pending invitation holds a seat, so accepting can never overfill the plan — and when someone is added directly. Someone who already holds a seat takes no new one, and guests never take a seat.
Sharing
Every resource carries an audience deciding who may use it: who can chat with an agent, or which attached capabilities (tools, skills, apps, MCP servers) a chat receives. The editor's Who can use it picker offers four levels:
| Level | Stored as | Who |
|---|---|---|
| Only me | private | nobody else |
| Internal | protected, nobody listed | anyone signed in to the org |
| Chosen people | protected with roles or people | signed-in people, by role slug or by name |
| Everyone | public | anyone, anonymous visitors included |
A capability also offers Same as the agent (null), its default.
Audiences name role slugs, so custom roles work. Signed-in owners and admins
pass every level.
The rules that matter:
- Inheriting means allowed. A capability left on Same as the agent goes to everyone who may chat with the agent — anonymous visitors too, when the agent is published to them.
- Restricting excludes visitors. A capability with its own level below Everyone never reaches anonymous visitors, and the picker warns when its agent is published on a widget or page.
- Folders are the exception. Absent sharing on a folder means not shared, not inherit.
There's no sharing page: the audience editor embeds in the agent editor and
every capability dialog, and sharing rides each resource's own create/update
body (null clears a capability back to inherit).
Impersonation
Owners of the platform organization configured on the deployment get a Tenants page listing every tenant organization. From there they can sign in as any member — or straight in as a tenant's owner — to inspect its data. Sessions last 30 minutes, are recorded against the operator's account, and can be ended from the banner at any time. Without a configured platform organization the feature is off and the page never shows.