Build custom roles by ticking exactly the permissions each type of staff member needs.
A role in Xobito is a named bundle of permissions. Every staff member has one role. There is no built-in hierarchy — two roles can’t “inherit” from each other. You build each role independently by ticking the permissions it should include.
The workspace owner (the user with the is_admin flag) bypasses the role system entirely — they have every permission, always. Roles only matter for other staff.
Workspaces ship with exactly one auto-created role:
Role
Permissions
Agent
tenant.chat.view only
That’s the minimum — an Agent can open the Live Chat inbox. Anything else needs to be added by ticking more permissions, or by creating additional roles.
There is no pre-seeded “Admin” role. To give someone admin-like access, create a role and tick every permission. Don’t use the is_admin flag on regular staff — that flag is reserved for the workspace owner.
Edit — ticking or unticking any permission applies immediately to every staff member with the role.
Delete — only possible if no staff member currently has that role. Reassign those staff first.
Revoking a permission takes effect on the affected user’s next page load. If they’re mid-task when you change the role, that specific action may fail partway through. Communicate major changes.
Xobito has one special behaviour to keep in mind. Any user with the is_admin flag on their account (by default, just the workspace owner) passes every permission check, no matter which role they hold.
You do not need to build an “Everything” role for the workspace owner — they already have access.
Do not set is_admin on regular staff. It’s the equivalent of giving them root access.
There are 77 tenant-scoped permissions in total, grouped by resource. Tick the ones a role should have.
Permission names use the format tenant.{resource}.{action}. All of them apply to the current workspace only — a permission granted here never leaks to any other workspace.
Xobito doesn’t ship any of these — they’re just patterns you can build yourself.
Agent (default)
Just tenant.chat.view. Lets the teammate answer conversations and nothing else.
Senior agent
Agent, plus tenant.contact.view, tenant.contact.edit, tenant.canned_reply.view, tenant.template.view. Can look up a contact, use canned replies, and see templates.
Marketer
Contact view/create/edit/bulk_import, templates view/create/edit/load_template, campaigns view/create/edit/show_campaign/bulk_campaigns.send, groups all four, statuses/sources all four, custom fields view.
Manager (near-admin)
Everything except: tenant.staff.delete, tenant.role.delete, tenant.whatsmark_settings.edit, tenant.system_settings.edit, tenant.connect_account.disconnect, tenant.activity_log.delete. Keeps the dangerous things for the workspace owner.
Read-only auditor
Every *.view permission, plus tenant.activity_log.view. Can see everything, can’t change anything.
A handful of permissions are essentially “keys to the kingdom” because they let the holder grant themselves more access. Give them only to your most trusted teammates:
tenant.role.create, tenant.role.edit — can invent a role with any permission set
tenant.staff.create, tenant.staff.edit — can reassign roles for any user
tenant.connect_account.disconnect — can sever your Meta Business connection
tenant.whatsmark_settings.edit, tenant.system_settings.edit — can change core workspace behaviour
tenant.activity_log.delete — can erase the audit trail
