# Roles and permissions

Who can do what, and how to give people the narrowest role that lets them work.

Source: https://docs.omazy.ai/workspace/roles/

Permissions are granted per role, and a role is granted per member. The right
instinct is the narrowest role that lets someone do their job, revisited when
they change jobs.

## The shape of it

| Role | Roughly |
|---|---|
| **Owner** | Everything, including billing and deleting things that do not come back |
| **Manager** | Configure the agent, automations and channels. Not billing |
| **Agent** | Work conversations. Not configuration |

Most people are agents. Managers are the handful configuring things. Owners
should be rare, and there must always be at least one, which is why the platform
refuses to remove the last one.

## Give less than feels generous

Over-granting is the default failure because it is the frictionless one. Nobody
has ever been thanked for withholding a permission, and nobody notices the
incident that did not happen.

The practical test: if this person's laptop were compromised tonight, what could
be changed? If the answer includes billing or deleting conversations, they
probably did not need that role to do their actual job.

## The audit log is the record

Whatever people did, the audit log has it. It is the first thing worth reading
when something looks wrong, and it is considerably faster than asking six people
whether they changed the brief on Tuesday.

Read it before forming a theory. Most mysteries here are somebody being helpful
in a way nobody else knew about.

## When someone leaves

Remove the member rather than changing their password. Removing revokes access
everywhere at once, including any CLI or integration token scoped to them.
Changing a password leaves every existing session exactly where it was.