Roles and permissions

Everyone in your workspace has exactly one role, and that role decides what they are allowed to do. There are four roles you can assign — Owner, Admin, Agent and Viewer — and they build on each other. An Agent can do everything a Viewer can, an Admin everything an Agent can, and an Owner everything an Admin can plus one thing more.

The four roles

The role is stored per workspace, not per person. The same email address can be an Owner in one workspace and an Agent in another.

What each role can do

This is the complete list, taken from the permission rules the product enforces. A ✓ means the role is allowed; a dash means the action is refused with a permission error.

One line in that table surprises people: a Viewer and an Agent can see the billing screen, including the plan, the usage figures and the invoice list. They cannot start, change or cancel anything there. If billing figures should not be visible to a person at all, do not add them to the workspace.

Extra rules on top of the table

Four rules sit above the permission list and cannot be worked around from the dashboard:

• Only an Owner can add a new member as an Owner, or raise an existing member to Owner. An Admin who tries gets “Only an owner can grant the owner role.”
• The last Owner cannot be demoted or removed. The attempt is refused with “Cannot remove the last owner of the organization.” To hand the business over, first make the other person an Owner, then change or remove the original one.
• While a workspace has two or more Owners, an Admin can demote or remove one of them. Give the Admin role only to people you would trust with that.
• Platform Admin is not a role you can assign. It is an internal OMAI operator identity, and the product refuses to write it to a member record.

Which role to give a new person

• They will answer customer messages and nothing else → Agent. This is the shipped default on the invite form and the right answer most of the time.
• They will also maintain the price list, the FAQ, the assistant’s settings or the WhatsApp connection → Admin.
• They only need to look — reporting, bookkeeping, an outside adviser → Viewer.
• They are a business partner who should be able to close the account → Owner.

What each role actually sees

Permissions are enforced on our servers when an action runs, so a control that is out of sight is a courtesy and never the lock. On top of that, the dashboard tries not to advertise a dead end. A lower role therefore has a genuinely shorter menu: the two screens an Agent and a Viewer cannot use at all — Assistant Settings and Audit Log — are left out of the sidebar for them, and reaching either from a bookmark or an old link produces a short explanation rather than a failure. On Team, a role that cannot manage members gets a read-only roster with no invite form and no per-person controls; and even an Admin is not offered a role change or a removal on the row of someone who outranks them.

Where a refusal is shown inline — the invite form, or a role change the ranking rules do not allow — it is a plain sentence in your own language saying what was refused and who can do it instead. It does not print an internal permission name; if you ever see one, that is worth reporting to us.

The Platform Admin badge

If you ever see Platform Admin in a role list, it belongs to OMAI’s own operator access, which is separate from your workspace roles and is used for support and platform administration. It is never granted through the Team screen, and it carries none of the workspace permissions in the table above. What operators can reach, and how it is recorded, is described in Who can access your data.

Where role changes are recorded

Adding a member, changing a role and removing a member each write an entry to the audit log with who did it, when, and the old and new role. An Admin or an Owner can read it on Dashboard → Audit Log; see The audit log.

Common questions