Team roles

Everyone in a Graine workspace has one of three roles. The role decides what they see in the dashboard, what they can change, and what any API key they create is allowed to do. The same rules are enforced by the dashboard, by every dashboard API route and by the platform APIs behind them, so a person's role is the same wherever they act.

Your own role is shown under your name at the bottom of the dashboard's sidebar, and in the workspace switcher for every workspace you belong to.

What each role can do

Every permission, and which roles hold it. The permission names are the ones a refusal reports (see What a refusal looks like).

The Team page in the dashboard shows this same table, generated from the same definition, with your own column marked.

What View only does not see

A View only seat does not see Billing, API keys, Integrations, Compliance, WhatsApp, Voice studio, the campaign builder, the playground or Deploy with code — those pages are left out of the navigation, and opening one directly shows "You don't have access to this page" with a way to find an admin. Pages a View only seat can open show every action it cannot take as unavailable, with the reason, rather than hiding it.

Inviting people and changing roles

Only Admins manage the team. From Team in the dashboard:

Three rules hold whatever you do:

• A role change takes effect on the person's next request — within about a minute — and never signs anyone out. Their screens simply stop offering what the new role does not allow.
• A workspace always keeps an admin. The last admin cannot be made a Member or View only, or be removed, until someone else is an admin. An invited admin who has not accepted yet counts, so you can hand over before they join.
• Every invitation, role change and removal is recorded in the workspace's access log on the Team page, with who did it and when. The log is hash-chained, so an edited or deleted entry is detectable.

The activity log

Admins only. The Activity log, under Account in the sidebar and linked from the Team page, lists who did what in the workspace and when: a campaign started or paused, an agent changed, a number assigned, a key revoked, a role changed. Each entry names the person, the role they held at the time, and whether it went through — an attempt their role refused is listed too, marked "Not allowed". Changes Graine makes on its own, such as pausing a campaign that ran out of credits, read "Graine (automatic)"; anything Graine support does read "Graine support".

Filter it by person, kind of change and dates, or show only refused attempts; export what you see as CSV; and use Verify integrity to check that no entry has been changed, removed or reordered since it was written.

Members and View only seats do not see the Activity log. Everyone who can see a campaign sees who started, paused or stopped it on the campaign itself, and an agent shows who last edited it.

API keys and roles

An API key can never do through the API what the person who made it cannot do in the dashboard.

A key a Member creates holds at most these scopes, and is recorded as made by that Member:

agents:read   agents:write   calls:read   calls:write
batches:write  webhooks:read  account:read

So a Member's key can read and edit agents, read and place calls, run batches, and read webhook and account settings — and nothing else. It never holds keys:write, so it cannot create or revoke other keys. Where an action is admin-only in the dashboard — deleting or archiving an agent, deleting a campaign — the API refuses it for a Member's key with a 403, even though the key holds agents:write or batches:write.

Keys an Admin creates behave exactly as before, with the scopes the Admin chooses. Keys created before roles existed are unchanged — an integration that is live today keeps working without any change. How scopes work in general is in Authentication.

What a refusal looks like

In the dashboard, an action your role does not allow is shown as unavailable with a one-line reason — for example "Only admins can delete agents — ask an admin", or "View-only access — ask an admin to change your role" — and a page your role cannot open answers "You don't have access to this page".

A dashboard API route refuses with 403 and a body that says which permission was missing and what your role is:

{
  "detail": "Only workspace admins can delete agents.",
  "code": "permission_denied",
  "permission": "agents.delete",
  "role": "member"
}

Branch on code and permission; show detail to a person. An unauthenticated request is a 401, not a 403.

For security reviewers

• Where it is enforced. Every dashboard API route declares the permission it needs in one table, and an automated check fails the build when a route is missing from it or does not check its permission. The platform APIs apply the same table to dashboard sessions and to API keys. The dashboard's own hiding and disabling of controls is a convenience, not the control.
• Where the role comes from. Admin is the identity provider's admin role. View only is a mark on the member's record that only Graine's servers can write — a browser cannot set it. The role is read from the live member record on each request, never from a snapshot taken at sign-in.
• Graine support. When Graine support works inside a workspace at your request, it does so as an Admin. It is never listed in your team, and what it does is recorded in your activity log as Graine support — as are changes Graine makes for you, such as a credit adjustment or a compliance review.
• Graine's own tools are separate. They are not a workspace role and are protected on their own.

See Security for the rest of the platform's access-control model.