Staff Roles and Permissions in IZI CRM
เนื้อหานี้ยังไม่มีในภาษาของคุณ
Staff Roles and Permissions in IZI CRM
Section titled “Staff Roles and Permissions in IZI CRM”IZI’s permission system is built around 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. One employee can hold different roles in different clubs within the same network. The key design decision: the cashier’s base access and the right to edit tariffs are two separate permissions, and that separation is intentional. Below is how the system is structured, what each permission group covers, and how to keep access as narrow as the job actually requires.
Hierarchy: organization → club → roles
Section titled “Hierarchy: organization → club → roles”IZI organizes access at two levels, and understanding this hierarchy is the foundation of correct setup.
Organization level covers everything that applies to the entire network: user and role management, integrations (payment gateways, cash register providers), player groups, promo campaigns, automations, transaction tags, and the audit log. Organization-level permissions use the org.* prefix.
Club level covers day-to-day operations at a specific location: the gaming floor, cash shifts, sessions, bar orders, analytics, warehouse, tariffs, and equipment. Club-level permissions use the club.* prefix.
A role carries permissions from both levels simultaneously. When you add a staff member, you define which clubs they can access and under which role. One employee — multiple roles across multiple clubs.
The organization owner is a special position. Only the owner can access organization settings (org.settings). No custom role, even one with Full Access, can open those settings — this is a hard system constraint, not a permission you can grant or override.
The Full Access flag on a role instantly grants all organization and club permissions without manual selection. Two operations are exclusively available to Full Access roles: managing users and roles, and creating new clubs. An ordinary role cannot access these even if every other available permission is selected.
Built-in roles in IZI
Section titled “Built-in roles in IZI”IZI ships with two system roles:
| Role | Intended for | What it can do | What it cannot do |
|---|---|---|---|
| Administrator (ADMINISTRATOR) | Senior staff, managers | Full access to all club and organization features | Change organization settings — owner only |
| IZI Technical Support | Service use | Internal IZI service access | Assign to staff; created by the system |
Most operators create custom roles for their specific workflows. A typical setup for a club with several staff members looks like this:
| Custom role | Permission set | What it covers |
|---|---|---|
| Cashier | club.base | Floor, sessions, payments, bar, player profiles, cash shift |
| Senior administrator | club.base + financial ops | Everything above plus refunds, cash collection, balance adjustments |
| Club manager | club.base + analytics | Everything above plus KPI reports, revenue, shift analytics |
| Content manager | club.catalog | Editing tariffs, products, schedules, and discounts |
| Analyst | club.analytics.* | Read-only analytics, no floor or cash access |
The built-in Administrator role is fullAccess: true. Assign it deliberately — this user can see and change everything, including other staff members’ roles.
Custom roles — when to create them
Section titled “Custom roles — when to create them”A custom role is the right choice whenever the built-in Administrator role (full club access) is too broad for a position, but you still need a defined permission profile. Common scenarios:
Coach or instructor. Works with players — creates profiles, views session history, assigns player groups. Does not need the cash register or revenue analytics. Role: club.base without financial operations and analytics.
Bar manager. Manages the product catalog — creates items, edits descriptions, sets prices. Does not need access to gaming tariffs or sessions. Role: club.catalog scoped to product categories (configured via the relevant permission checkboxes in the Club Settings group).
Events coordinator. Sets up promo campaigns and player groups for tournaments. Works at the organization level. Role: org.campaigns + org.playerGroups with no operational club access.
Financial analyst. Views revenue reports, shift summaries, bar analytics — does not work the floor. Role: club.analytics.kpi + club.analytics.daily + club.analytics.bar + club.analytics.shifts.
Technical staff. Manages hardware — adds and configures computers, zones, screensavers. Role: club.equipment + club.screensavers + club.iziBoot.config.
The rule is straightforward: if a position needs one function, create a role with that function only. Excess permissions are the source of accidental changes and audit complications.
Permissions: the full map
Section titled “Permissions: the full map”Here is the current permission structure roles are built from. Groups match the tabs in the role builder (Organization → Roles → Add).
Club level
Section titled “Club level”Club administration — day-to-day operations and hardware:
- Floor, orders, bar orders, clients and player groups (
club.base) - Transaction tags, equipment, remote access, creating holds
- Club map — the visual layout of PCs and zones on the floor screen
- IZI Boot, screensavers, IZI Monitoring, warehouse
- Cancel and restore — six separate permissions: tariff, product, combo (each action its own checkbox)
- Ban/unban a player in the club, archive and restore a player — three independent permissions
- Disk protection removal (
club.diskProtection) - Data export (
club.export)
Club settings — point-of-sale configuration:
- Billing management for the club’s payer
- Catalog: tariffs, products, discounts (
club.catalog) - Schedules
- Club administration (general settings)
- IZI Boot settings, IZI Monitoring settings
- Integrations: Telegram, CCBoot
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— session dataclub.analytics.clients— client baseclub.analytics.shifts— shift reportsclub.analytics.suspicious— suspicious operationsclub.analytics.promo_codes— promo codesclub.analytics.topupBonus— top-up bonusesclub.analytics.pricing_simulator— pricing simulator
Financial operations — each operation is a separate checkbox:
- Cash register management (
club.finance.cashboxes) - Gaming balance top-up / deduction
- Bonus balance top-up / deduction
- Refund (
club.finance.op.refund) - Cash collection (
club.finance.op.cashCollection) - Account transfer (
club.finance.op.accountTransfer) - Applying a discount (
club.discounts.apply) — separate from making a sale
Organization level
Section titled “Organization level”Full Access required — managing users and roles, and creating new clubs, are available only to roles with the Full Access flag; there is no standalone checkbox for them.
General settings:
org.integrations— payment providers and cash register configurationsorg.clubSettings— network-wide club settingsorg.player.ban— ban/unban a player across the whole organizationorg.warehouse— network-wide warehouseorg.transactionTags— transaction tagsorg.promoCodes/org.promoCampaigns— promo codes and promotionsorg.export— data exportorg.products.write/org.productCategories.write— create and edit shared network products and categoriesorg.suppliers.write— create and edit suppliersorg.audit— audit logorg.automation— automation rulesorg.gameAccounts— game accountssubscription.view— billing management for the whole network
Campaigns:
org.campaigns— push notifications and campaignsorg.playerGroups— player groups
Owner only (ownerOnly: true):
- Organization settings (
org.settings)
Dependencies cascade automatically: if you grant club.catalog, IZI automatically includes club.base, club.schedules, and club.equipment — because editing the catalog requires access to schedules and equipment. The CRM’s permission editor resolves this chain for you when you make your selection.
Audit log and monitoring
Section titled “Audit log and monitoring”The audit log (org.audit) is your after-the-fact control tool. Open it via Organization → Audit Log. Access requires the AuditLogRead permission.
What is logged. Every mutation through the CRM: opening and closing sessions, payments, balance top-ups and deductions, refunds, tariff changes, product additions, user management changes. Each record contains: who, when, and exactly what changed.
Typical use cases:
- Applied discount. Open the transaction detail — you see the staff member who applied the discount, the time, and the amount.
- Unauthorized tariff change. The log shows who changed which tariff parameter and when, even if the change was later reversed.
- Disputed refund. Every refund is attributed to a specific user and timestamp.
- Shift review. Shift open, close, and cash register events are all logged with timestamps.
Who sees the log. Only users with org.audit. A regular cashier does not see the log and has no access to it in the interface. This is standard practice: the monitoring tool should not be visible to those being monitored.
Retention. Action history is not deleted when a user is removed. If a staff member is dismissed and their account deleted, their operations during employment remain in the log attributed to their user ID.
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 their shift, works, and closes it. The next staff member opens their own shift. This creates a clear line of accountability: every operation during a shift is attributed to the person who opened it.
Steps for handing over a shift:
- The outgoing staff member closes the cash shift through the CRM
- The incoming staff member opens their shift
- Any cash discrepancies appear in shift analytics (
club.analytics.shifts) and are pinned to the specific shift and user
Temporary elevated access. If a staff member needs temporary access to an extended function — 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 original role. Do not create a permanent profile with excess permissions “just in case.”
Multiple clubs. A staff member can be added to multiple clubs in the same organization with different roles in each. This is a normal configuration for a network manager who, for example, has full access at three locations and analytics-only access at two more.
Offboarding checklist:
- Confirm the employee’s cash shift is closed
- Remove the user from the organization (Organization → Users → Remove)
- Verify they were not the only user 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 visible under Organization → Roles in your account.
See also
Section titled “See also”คำถามที่พบบ่อย
What roles does IZI include out of the box?
IZI ships with two system roles: Administrator (ADMINISTRATOR), which grants full access to all club features, and IZI Technical Support, a service role that cannot be assigned to staff. Beyond these, the organization owner can create any number of custom roles with any combination of permissions.
How is the owner different from a user with Full Access?
The organization owner is the only account that can access organization settings (org.settings). A user with the Full Access flag gets all organization and club permissions, but org.settings remain owner-only — this is a hard system constraint, not a configurable permission. In addition, only a Full Access user can manage other users and roles, and create new clubs.
What can a shift administrator do?
A staff member with the base club permission set (club.base) can view the floor, open and close sessions, take payments, top up balances, handle bar orders, create and edit player profiles, and open and close the cash shift. They cannot edit tariffs, manage the product catalog, or view analytics unless those permissions are explicitly added to their role.
How do I create a custom role?
Go to Organization → Roles → Add. Enter a name, select the organization-level and club-level permissions from the checklists, and save. The role is immediately available to assign to any user. The Full Access flag is an alternative to manual selection — it automatically grants every permission in the system.
Can I prevent a cashier from editing tariffs?
Yes. Catalog editing (club.catalog) is a separate permission key that is not part of the base staff set. A user with only club.base cannot create, edit, or delete tariffs, products, discounts, or schedules. To enforce this, simply do not add club.catalog to the cashier role.
What is the difference between org-level and club-level permissions?
Organization-level permissions (org.*) govern network-wide actions: integrations, transaction tags, player groups, promo campaigns, automations, and the audit log. Club-level permissions (club.*) govern operations within a specific club: the floor, cash shifts, analytics, catalog, warehouse, and equipment. A role contains both levels, and a staff member's effective access is 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 employee can hold different roles in different clubs — for example, senior administrator in one location and cashier in another.
How do I revoke a staff member's access?
Remove them from the organization under Users. Their session token is immediately invalidated and login becomes impossible. Removing a user does not erase their action history — all operations remain attributed to their account in the audit log.
Where do I find the audit log?
Organization → Audit Log (requires the org.audit permission). The log records every mutation: who, when, and what action was performed. Regular staff cannot see the log — only the owner or users with org.audit explicitly granted.
Can I see who applied a discount?
Yes. Every transaction stores the ID of the user who created it. The audit log (org.audit) or the transaction detail view shows which staff member applied a discount, processed a refund, or made a manual balance adjustment.
Does IZI support two-factor authentication?
Built-in 2FA at the organization level is not currently part of the CRM. Additional security is provided by the shift model (each administrator opens their own shift), the role model that avoids excess permissions, and the audit log for after-the-fact review.
An employee left — what should I do with their account?
Remove the user from the organization under User Management (requires a Full Access role). Sessions are invalidated immediately. Their operation history for the period of employment remains in the audit log, attributed to their account — important for audit and shift reconciliation.
Is applying a discount at checkout a separate permission?
Yes, `club.discounts.apply` is not part of the base cashier set and is granted separately. This prevents any staff member with checkout access from cutting prices at will without the manager knowing.
IZI LLC (ООО «ИЗИ»), TIN 7842227686, OGRN 1257800012249, office 1, premises 3-N, lit. A, 15-17 Perekupnoy lane, Saint Petersburg, 191024, Russia, admin@izi.is · Cookie settings