Roles and permissions (RBAC)

Tirify uses a role-based access control system (RBAC). 86 permissions cover every operation in the admin panel. The owner can create custom roles and give staff members access only to the sections they need.

---

System roles

Six built-in roles that cannot be deleted:

Role	Description
Owner	Store owner — full access to everything
Admin	Administrator — almost everything except deleting the store
Manager	Manager — catalog, orders, players, promo
Support	Support — tickets and player view only
Content Editor	Editor — storefront, pages, widgets
Viewer	Observer — can view everything, cannot change anything

---

Permission groups (20 groups)

Permissions are grouped by admin panel section:

Group	Key	Covers
Products	products:*	Product CRUD, categories, presets
Orders	orders:*	View, refunds, redeliver
Players	players:*	Player list, wallet, delivery
Servers	servers:*	Server CRUD, plugin secret
Payments	payments:*	Providers, transactions, balance
Promo	promo:*	Promo codes and creator codes
Storefront	storefront:*	Design, widgets, pages, SEO
Integrations	integrations:*	Telegram, Discord, webhooks
Team	team:*	Members, invites, roles
Audit	audit:*	Audit log, logs
Statistics	statistics:*	Charts, metrics
Settings	settings:*	General, domain, plugin
Support	support:*	Tickets
Wipes	wipe:*	Schedule, rules
Bonuses	bonus:*	Top-up bonuses
Analytics	analytics:*	GA4, Metrica
SEO	seo:*	Meta tags
Organization	org:*	Organizations, billing

Each group contains permissions:

• :read — view
• :create — create
• :update — edit
• :delete — delete

---

Custom roles

1. Admin panel → Team → Roles → "Create role"
2. Name (e.g. "Content Manager")
3. Permissions matrix — check the ones needed
4. Save

A custom role inherits only the checked permissions. No access by default.

---

Permissions matrix

In the admin panel the matrix looks like a table:

           read  create  update  delete
products    ☑      ☑       ☑      ☐
orders      ☑      ☐       ☐      ☐
players     ☑      ☑       ☑      ☑
...

A checked cell grants the permission for that operation. An empty cell denies it (the button is hidden, the API returns 403).

---

Inviting staff members

The process is described in Members and invites. In short: staff member's email + role selection → email with link → staff member sees only the permitted sections.

---

How permissions work

• A staff member only sees the admin panel sections their role has :read permission for
• Create / edit / delete buttons are hidden when the corresponding permission is absent
• The API automatically rejects operations without the required permission (error 403)

If a staff member needs more access, the owner can expand their custom role or assign a system role.

---

Next steps

• Members — inviting your team