Staff, Roles and Access in IZI
Staff, Roles and Access in IZI
Section titled “Staff, Roles and Access in IZI”The IZI role system is a set of permissions attached to two levels: the organization (the entire network) and the club (a specific location). A role is not a job title — it is an access profile. The same staff member can have different roles at different clubs within one network. The key fact: a cashier’s basic access and the right to edit tariffs are two separate permissions, and that separation is intentional. Below is how the system works, what each permission covers, and how to avoid giving anyone more access than they need.
Hierarchy: Organization → Club → Roles
Section titled “Hierarchy: Organization → Club → Roles”Access in IZI is structured across two levels, and understanding this hierarchy is the foundation of correct configuration.
Organization level covers the entire network: user and role management, integrations (payment gateways, cash desk providers), player groups, campaigns, automations, transaction tags, and the audit log. Organization-level permissions start with org.*.
Club level covers day-to-day operations at a specific location: the hall, cash shifts, sessions, bar orders, analytics, warehouse, tariffs, and equipment. Club-level permissions start with club.*.
A role contains permissions from both levels simultaneously. When you add a staff member, you specify which clubs they have access to and with which role. One staff member — different roles at different clubs.
The organization owner is a special position. Only the owner has access to organization settings (org.settings). No custom role, even with Full Access, can open these settings — this is a system-level hard constraint.
The Full Access flag in a role grants all organization and club permissions at once, without manual selection. Two operations are available only to roles with this flag: managing users and roles, and creating new clubs. Regular roles cannot access these functions even if every other permission is manually selected.
Built-in Role: Administrator
Section titled “Built-in Role: Administrator”IZI ships with one built-in staff role: Administrator (ADMINISTRATOR). It provides base club-level rights and is the only preset role you assign to staff.
| Role | What it is | Can do | Cannot do |
|---|---|---|---|
| Administrator (ADMINISTRATOR) | The single built-in staff role | Full access to all club and organization functions | Change organization settings — owner only |
| IZI Technical Support | System role, auto-added by IZI | IZI service access | Assign to staff; managed by IZI, not by you |
For anything beyond the Administrator profile, you create custom roles. IZI has no built-in “Cashier” or “Manager” role — those are examples of custom roles you define yourself with exactly the permissions each position requires.
Custom Roles — What They Are and Why You Need Them
Section titled “Custom Roles — What They Are and Why You Need Them”A custom role is created by the owner in Organization → Roles → Add. You choose the name, pick the exact permissions from the checklist, and save. The role is immediately available for assignment.
Most clubs create several custom roles to match their actual staffing. A typical set:
| Custom role name | Permission set | What it covers |
|---|---|---|
| Cashier | club.base | Hall, sessions, payments, bar, player profiles, cash shift |
| Senior admin | club.base + financial ops | Above plus refunds, cash collection, balance adjustments |
| Club manager | club.base + analytics | Above plus KPI reports, revenue, shift analytics |
| Content manager | club.catalog | Editing tariffs, products, schedules, discounts |
| Analyst | club.analytics.* | Analytics view only, no hall or cash desk access |
These names are examples — you can call a role anything you want. “Cashier” and “Manager” above are custom roles with those names, not preset system roles.
The built-in Administrator role has fullAccess: true. Assign it deliberately — such a user can see and modify everything, including other staff roles.
Custom Roles — Scenarios
Section titled “Custom Roles — Scenarios”A custom role is the right tool whenever the Administrator profile gives more access than a position actually needs. A few examples:
Coach or instructor. Works with players — creates profiles, views session history, assigns groups. No need for the cash desk or revenue analytics. Role: club.base without financial operations and analytics.
Bar manager. Manages the bar product catalog — creates, edits, sets prices. No need for tariffs or gaming sessions. Role: club.catalog scoped to product categories.
Event curator. Sets up campaigns and player groups for tournaments. Works at organization level. Role: org.campaigns + org.playerGroups without operational club access.
Financial analyst. Views revenue reports, shift analytics, bar analytics — does not work in the hall. Role: club.analytics.kpi + club.analytics.daily + club.analytics.bar + club.analytics.shifts.
Technical staff. Manages equipment — adds and configures computers, zones, screens. Role: club.equipment + club.screensavers + club.iziBoot.config.
The rule is simple: if a position requires access to one function, create a role with only that function. Excess permissions are a source of accidental changes and audit complexity.
Permissions: Granularity of Control
Section titled “Permissions: Granularity of Control”Here is the full permission map by group — the building blocks of any role:
Club administration (club.base) — baseline for operational work:
- Hall, orders, bar orders, clients and groups
- Creating and ending sessions
- Accepting payments, topping up balances
- Opening and closing the cash shift
- Viewing devices and zones
Club settings — managing the club’s structure (requires club.catalog):
- Creating and editing tariffs, tariff groups, discounts
- Managing bar products and categories
- Work schedules
- Equipment (devices, zones, screens)
Analytics (club.analytics.*) — each section is a separate permission:
club.analytics.kpi— key metrics (revenue, ARPU, utilization)club.analytics.daily— daily dynamicsclub.analytics.bar— bar analyticsclub.analytics.tariff— tariff analyticsclub.analytics.sessions— sessionsclub.analytics.clients— client baseclub.analytics.shifts— shift reportsclub.analytics.bonus— bonus programclub.analytics.topupBonus— top-up bonusesclub.analytics.suspicious— suspicious operationsclub.analytics.promo_codes— promo codesclub.analytics.pricing_simulator— pricing simulator
Financial operations — each operation is a separate toggle:
- Credit gaming balance
- Debit gaming balance
- Credit bonus balance
- Debit bonus balance
- Refund (
club.finance.op.refund) - Cash collection (
club.finance.op.cashCollection) - Account transfer (
club.finance.op.accountTransfer) - Cash desk management (
club.finance.cashboxes)
Cancel and restore tariff — separate permissions:
club.orders.cancelTariff— cancel an active tariffclub.orders.restoreTariff— restore a cancelled tariff
Organization-level permissions:
org.integrations— payment providers and cash desk configurationsorg.playerGroups— player groupsorg.campaigns— push notifications and campaignsorg.promoCodes/org.promoCampaigns— promo codes and promotionsorg.automation— automation rulesorg.audit— audit logorg.transactionTags— transaction tags
Full Access only (requireFullAccess: true):
- User and role management (
org.users,org.roles) - Creating new clubs
Owner only (ownerOnly: true):
- Organization settings (
org.settings)
Dependencies work in a cascade: when you grant club.catalog, the system automatically pulls in club.base, club.schedules, and club.equipment — because editing the catalog requires access to schedules and equipment. This chain unfolds automatically when selecting permissions in the CRM.
Audit Log and Control
Section titled “Audit Log and Control”The audit log (org.audit) is a tool for after-the-fact control. Accessible via Organization → Audit Log; visible only to users with the AuditLogRead permission.
What is logged. All mutations through the CRM: session creation and completion, payment processing, balance top-ups and debits, refunds, tariff changes, product additions, user management. Each record contains: who, when, and exactly what was changed.
Use cases:
- Applied discount. Open the transaction detail — see the staff member who applied the discount, the time and amount.
- Unauthorized tariff change. The log shows who changed the tariff parameters and when, even if the change has since been reverted.
- Disputed refund. Every refund is attributed to a specific user and operation time.
- Shift review. Staff shift, cash desk opening and closing — all in the log with timestamps.
Who sees the log. Only users with org.audit. A regular cashier cannot see the log and has no awareness of it in the interface. This is standard practice: a control tool should not be visible to the person being monitored.
Retention. Action history is not deleted when a user is removed. If a staff member is dismissed and their account deleted, operations from their working period remain in the log attributed to their identifier.
Shift Handover and Temporary Access
Section titled “Shift Handover and Temporary Access”Shift handover. In IZI, each cash shift is tied to a specific user. A staff member opens a shift → works → closes it. The next staff member opens their own shift. This creates a clear boundary of responsibility: every operation during a shift period is attributed to the person who opened it.
Shift handover steps:
- The outgoing staff member closes the cash shift through the CRM
- The incoming staff member opens their own shift
- Cash discrepancies are visible in shift analytics (
club.analytics.shifts) — recorded per shift and user
Temporary access to a function. If a staff member needs temporary access to extended functions (for example, to process a cash collection in the absence of a senior administrator), the correct approach is to add the required permission to a temporary role, assign it, complete the task, then revert to the previous role. Do not create a permanent profile with excess permissions “just in case.”
Multiple clubs. A staff member can be added to several clubs in one organization with different roles at each. This is a normal configuration for a network manager who, for example, has full access at three clubs and analytics-only access at two others.
Offboarding checklist:
- Make sure their cash shift is closed
- Remove the user from the organization (Organization → Users → delete)
- Confirm they are not the only person with Full Access — otherwise you lose the ability to manage roles
Related: What is IZI · Club settings in CRM · Top-up bonuses · Tariffs and pricing · Bar and warehouse
Permission descriptions are based on the IZI CRM configuration (accessGroups.ts, permissionOwner.ts). The permission set may expand with new platform versions. Current permissions are available under Organization → Roles in your account.
See also
Section titled “See also”Frequently asked questions
What roles does IZI provide out of the box?
IZI has one built-in staff role: Administrator (ADMINISTRATOR) — base club-level access for day-to-day operations. IZI Technical Support is a system role auto-added to every organization for IZI's own service access; it is not assigned to staff. Beyond Administrator, the owner creates any number of custom roles with exactly the permission set each position needs.
How does the owner differ from a user with full access?
The organization owner is the only one with access to organization settings (org.settings). A user with the Full Access flag receives all organization and club permissions, but organization settings remain owner-only. Additionally, only Full Access roles can manage other users and roles, or create new clubs.
What can a shift administrator do?
A staff member with basic club permissions (club.base) can see the hall, create and end sessions, accept payments, top up balances, handle bar orders, create and edit player profiles, and open and close the cash shift. They cannot change tariffs, edit the product catalog, or view analytics — unless those permissions are explicitly added to the role.
How do I create a custom role?
Go to Organization → Roles → Add button. Enter a name, select organization-level and club-level permissions from the checklists, and save. The role is immediately available for assignment. The Full Access toggle in a role is an alternative to manual selection — it automatically grants all permissions.
Can I prevent a cashier from changing tariffs?
Yes. Catalog editing permission (club.catalog) is a separate key not included in the basic staff set. A custom role built for cashier work with only club.base cannot create, edit, or delete tariffs, products, discounts, or schedules. To prevent this — simply don't add club.catalog to the role.
What is the difference between club-level and organization-level permissions?
Organization-level permissions (org.*) cover the entire network: integrations, transaction tags, player groups, campaigns, automations. Club-level permissions (club.*) cover operations at a specific location: hall, cash desk, analytics, catalog, warehouse. A role contains both levels simultaneously, and a staff member gets access based on the intersection of their role and the clubs they are added to.
Can I give a staff member access to only some clubs in the network?
Yes. When adding a user you specify which clubs they have access to. The same staff member can have different roles in different clubs — for example, senior administrator at one location and cashier at another.
How do I block a staff member?
Remove them from the organization in the Users section. Their session token is immediately invalidated and login with their credentials becomes impossible. Removing a user does not erase their action history in the audit log — operations remain attributed to their account.
Where is the audit log?
Organization → Audit Log (requires org.audit permission). The log records mutations: who, when, what action was performed. Accessible to users with AuditLogRead permission. Regular staff cannot see the log — only the owner or users with an explicit org.audit grant.
Can I see who applied a discount?
Yes. Every transaction stores the identifier of the user who created it. Through the audit log (org.audit) or the transaction detail you can see which staff member applied the discount, refund, or manual balance adjustment.
Is two-factor authentication available in IZI?
Two-factor authentication is not a built-in CRM feature at the organization level. Additional security is provided through cash shift management (each administrator opens their own shift), the role model without excess permissions, and the audit log for after-the-fact review.
A staff member has left — what should I do with their account?
Remove the user from the organization in User Management (requires a role with Full Access flag). Sessions are immediately invalidated. The operation history for their working period remains in the audit log attributed to their account — important for audit and shift reconciliation.