Skip to content
PokerEnginePro
Back office

The back office.
Run the rooms, the money and the people.

38 pages to run the rooms, the money and the people — with four-eyes approval and an audit log of everything. Staff commands go through the cluster, so the game's rules hold for them: a stakes change lands at the next hand boundary.
Request a demoRoles and permissions

38 pages

A complete back office.
One page for every job.

Dashboard, rooms, tournaments, players, ledger, hands, history, approvals, audit, settings and staff, then KYC, rule packs, vendors, messaging, compliance, BI, licence and more — 38 pages with every module installed, one typed API.

  • 01

    Dashboard

    Tiles that update as play happens, streamed from the cluster.
    • /admin/dashboard

  • 02

    Rooms

    Open, pause, resume and close tables, and change stakes, rake and timers — applied at the next hand boundary.
    • /admin/rooms

  • 03

    Tournaments

    Templates, schedules and Sit & Go lines; pause, resume, move a player, break a table, or cancel with every payment refunded.
    • /admin/tournaments

  • 04

    Players

    Search, profiles with balances and seats, freeze, suspend and reinstate — and play-chip grants for one player or a thousand.
    • /admin/players

  • 05

    Ledger

    The entry explorer, every reconciliation run, the archived months, and the dead-letter queue settled with reasons.
    • /admin/ledger

  • 06

    Hands

    Find any hand and replay it event by event; hole cards only on settled hands, and only for Risk.
    • /admin/hands

  • 07

    History

    Records older than the live window, read from the history database, and a player's whole record exported in one audited step.
    • /admin/history

  • 08

    Approvals

    The queue of changes waiting for a second person; whoever raised a request cannot approve it, and an old one expires.
    • /admin/approvals

  • 09

    Audit

    Every staff action and sensitive read, searchable by action, subject and person.
    • /admin/audit

  • 10

    Settings

    Feature flags, maintenance with drain, games per market, the rake schedule with a live preview, and the play-chip grant ceiling.
    • /admin/settings

  • 11

    Social

    The social casino's switches — store, bonuses, rewarded ads — and the chip-store packages, priced per market in its own currency and scheduled like any setting.
    • /admin/social

  • 12

    Staff

    The role-to-permission matrix with each role's display name, and who has been doing what, read from the audit log.
    • /admin/staff

Those twelve are the daily work, and Social comes with the social casino module. The core adds twelve more: KYC, rule packs, vendors, messaging, integrity, chat, bots, BI, retention, business settings, the licence and support. The modules add thirteen: payments, AML, screening and reports, bonuses and CRM, affiliates and agents, the casino, brands and the Partner API.

The dashboard

A live dashboard.
Every few seconds.

Tiles that update as play happens, streamed from the cluster.
  • Players seated, tables open and running, waitlists, hands in the last hour, rake today and all time per currency, and every stakes level in play.
  • Money waiting in the dead-letter queue, voided hands, requests awaiting a second approver, and maintenance mode — raised on the dashboard.
  • Live numbers come from the lobby's read model and are pushed every three seconds over one server-sent-events connection, so an open dashboard costs the game tier nothing.
backoffice / dashboard
The back-office dashboard: a notice that one approval request is waiting for a second approver; tiles for players seated now (people and bots counted apart), tables running and open, hands per minute, the waiting list, bots seated and players registered; a live activity chart of players seated and hands per minute; and seats taken and free at each stakes level, beside a grouped side menu from Dashboard and Rooms to Payments, Ledger and Chip store settlement.
The back-office dashboard, live: seats, tables, hands, registrations, rake and stakes.

More of the back office

  • backoffice / rooms
    The Rooms page: seven play-money tables of No-Limit, Pot-Limit and Fixed-Limit Hold'em and Pot-Limit Omaha, with their stakes, seats taken, state — one paused — waitlist and hands per hour, and a New room button.
    Rooms: every table with its game, currency, stakes, seats, state, waitlist and hands per hour.
  • backoffice / audit
    The Audit page: rows for a request to reinstate a player, closing a player's account, a play-chip grant, pausing a room, changing a room's stakes and opening a room, each with the time, the staff member, their roles, the action, the subject, the reason, the outcome and the values before and after.
    Audit: who did what, with which roles, why, whether it worked, and the values before and after.
  • backoffice / staff
    The Staff page: notes that staff accounts and MFA live in the identity provider and which roles can make and approve the same change, then a table of permissions by role, from Ops and Finance to SuperAdmin, LoadTest and Agent.
    Staff: what each role may do, permission by permission.
  • backoffice / settings
    The Settings page: a reason field recorded in the audit log, a Maintenance card with Drain tables and Resume normal play, links to the games and tournament settings, the features and play-chip grant ceiling, and the start of the rake by game.
    Settings: maintenance, the games and features, and the rake by game — each change with a reason for the audit log.

Overviews

An Overview tab for the big areas.
Numbers, then the rows behind them.

Rooms, Ledger, Payments, Tournaments, Players, KYC, Casino and the chip store each open on their working list and keep a tab of charts beside it: today to 90 days or your own dates, compared with the period before, and kept in the link so a view can be sent to a colleague.
backoffice / rooms / overview
The Rooms overview for the last seven days. Tiles for players seated now, split into people and bots, tables dealing and open, hands per minute, the waiting list and bots seated, an occupancy gauge, and hands settled with average and peak players seated. Below, a line chart of players and bots seated across the week, with a dotted line for today so far, and a Needs attention panel with one approval request waiting for a second approver.
Rooms, overview: the floor now and over the last seven days — seats, tables, hands per minute, waitlist, occupancy and what needs attention.

Lists and search

From the number to the player.
Without leaving the page.

Every list sorts and filters in the link, chooses its columns, exports what it shows to CSV and opens a row in a side drawer, so staff keep their place in the list. Ctrl K opens a palette that jumps to any page the role may see, or searches players. And a ? beside every page title opens help written for the operator, not the engineer.
  • backoffice / players
    The Players list dimmed behind a side drawer for one active player: status, email, hands played and join date, cash, bonus and play balances, whether they are seated, a location check recorded as placed, and a form to change the account status with a reason that is recorded in the audit log.
    Players: a row opens in a drawer beside the list, with the account, balances, location checks and the status change.
  • backoffice / command palette
    The command palette open over the Players list with the letters pl typed: the Players page as the first result, an action to open help for this page, and a jump to search players for those letters.
    Ctrl K: jump to a page, or search players, from anywhere.
  • backoffice / players / help
    The Players overview dimmed behind a help dialog titled Players: help. Under What this page is for, a short paragraph on finding a player and acting on them; under What you see, the Overview tab marked as the current tab, with plain explanations of active players, registrations, conversion, the funnel from registration to first hand and retention by cohort, and a note that the ? key opens help on any page.
    Help on every page: a ? beside the title explains, in plain language, what the page is for and what each figure means.

Roles and permissions

What each job needs.
And nothing more.

Ops, Finance, Risk, Compliance, Support, Marketing, Auditor, the MLRO, SuperAdmin and a least-privilege LoadTest — ten built-in roles — and the Agent role with the affiliates module, eleven in all — over fine-grained permissions, renamed and regrouped per operator.

Permissions, not roles

Endpoints require one of 86 permissions (49 in the core, the rest added by the modules installed), never a role, so roles can be regrouped without touching code — and the UI hides what a caller cannot do.

A least-privilege load-test role

The load generator signs in as LoadTest: rooms and play-chip grants, and nothing else — no ledger, no hole cards, no approvals.

Back-office roles and what each may do
RoleRun roomsLedgerAdjustGrant chipsApproveAudit logHole cards
Ops
Finance
Risk
Compliance
Support
Marketing
Auditor
SuperAdmin

The permissions that matter most to a buyer, by role — as the admin API grants them.

Integrity

Even SuperAdmin cannot see hole cards.
Integrity is not seniority.

Seeing another player's cards decides whether a game was fair, so it is a permission of its own — held by Risk, for hands that are over, and written down every time it is used or refused.
  • Only Risk can, only for settled hands, and every look is audited.
  • A hole card never appears in a broadcast, a log line or a staff view of a live hand.
Auth/AdminPermissions.cs
/// <summary>Reading the hole cards of a settled hand. Never live — there is no god view.</summary>
public const string HandsHoleCards = "hands.holecards";

// …

/// The matrix. Auditor is read-only by construction; SuperAdmin holds everything *except* hole cards,
/// because seeing another player's cards is an integrity decision, not a seniority one.
// …
[SuperAdmin] = AdminPermissions.All.Remove(AdminPermissions.HandsHoleCards),
backoffice/Poker.Admin.Api/Auth/AdminPermissions.cs — the admin API's permission matrix, quoted from the source. The UI reads the same list the API enforces.

Four-eyes approval

Two to approve.
Never the one who asked.

Large withdrawals, payouts by exception, chargeback write-offs, crypto returns, vendor changes — approved by the family's specialist — rule-pack reviews and market assignment, high-risk KYC approvals, screening clears, AML, integrity and responsible-gambling releases, confiscations, ledger adjustments, stake changes at real-money tables, reinstatements and tournament cancellations all need a second person.
  1. 1

    Maker

    Raises the change — Ops lowering the stakes of a running real-money room, say.

  2. 2

    Admin API

    Stores it as a pending request and writes an audit row. Nothing changes yet.

  3. 3

    Checker

    Another person with approvals.decide approves it — never the one who raised it, never once it has expired.

  4. 4

    Cluster

    Applies the change — a room's from its next hand — and the decision is audited too.

The four actions that wait

  • room.update

    Stakes, buy-ins or rake

    Changing the stakes, buy-in limits or rake of a running real-money room. Approved, it applies from the next hand.

  • tournament.cancel

    Cancelling a tournament

    Cancelling a real-money tournament in play — every payment is refunded.

  • player.status

    Reinstating an account

    Bringing a closed account back.

  • deadletter.dismiss

    Dismissing a dead letter

    Deciding that a failed real-money command is not owed, with a reason.

Play chips need no second person — not even to raise the grant ceiling. Approval is kept for real money and for steps that cannot be undone, so it never becomes a rubber stamp.

The audit log

An audit log of everything.
Refusals included.

Every command and every sensitive read — refusals included — with who, their roles, before, after, reason and address.
  • Who: the staff member's id and name, and the roles they held at that moment.
  • What: the action and its subject — a room, a player, a setting, a batch.
  • Before and after: the values on both sides of the change, as JSON a person can read years later.
  • Why: the reason given, and the approval request when a second person signed it off.
  • From where: the address the request came from.
  • Whether it worked: refusals are recorded too — “tried and was refused” is what an investigation needs.
  • flag.set
  • maintenance.set
  • variants.set
  • rake.set
  • player.grant
  • playgrant.ceiling.set
  • player.history.export
Governance/AuditLog.cs
/// <summary>One staff action, as it will be read back months later.</summary>
public sealed record AuditRecord(
    string Actor,
    string ActorName,
    IReadOnlyCollection<string> Roles,
    string Action,
    string Subject,
    object? Before = null,
    object? After = null,
    string? Reason = null,
    Guid? ApprovalId = null,
    string? IpAddress = null,
    bool Succeeded = true,
    string? Details = null);
platform/Poker.Platform.Persistence/Governance/AuditLog.cs — one row per staff command and per sensitive read.

Settings

Run the room from Settings.
Without a deploy.

Feature flags, maintenance with drain, games per market, the rake schedule with a live preview, and the play-chip grant ceiling.

Feature flags

Switch a feature on or off for the whole room, with a reason, recorded before and after.
  • /admin/flags

Maintenance with drain

Maintenance mode drains the tables: the hand in progress finishes, no new hand starts and nobody new sits down.
  • maintenance.set

Games per market

Which games and stakes are offered is a switch per operator and per jurisdiction, set from the back office.
  • variants.set

The rake schedule, previewed

Rake lines by game, currency and big-blind band — percentage, cap, minimum pot, no-flop-no-drop — with a preview of what a pot would rake before anything is saved.
  • POST /rake/preview

The play-chip grant ceiling

A chart default that staff can override from Settings with a reason; it applies to the next grant on every replica, without a restart.
  • playgrant.ceiling.set

Every change names a reason

Settings, flags, maintenance, the games offered, the rake and the grant ceiling are changed with a reason, recorded with the before and after.
  • reason required

Play-chip grants

Grant play chips.
A thousand at a time.

Batch grants with per-player results, a ceiling staff can tune, and an audit row per batch.

  • Play money only. A real-money currency is refused, so real money can never be granted this way.
  • One result per player. Up to 1,000 players per batch, each answered Granted, AlreadyGranted, UnknownPlayer, AccountClosed or Failed — not all or nothing.
  • Sent twice, credited once. Each grant is keyed by its batch and its player, so a batch sent again after a lost answer credits nobody twice.
  • Balanced like any bonus. A grant is the same ledger credit as the daily bonus, so reconciliation already balances it and a failure goes to the dead-letter queue.
POST /admin/players/grants
public sealed record PlayGrant(Guid UserId, long Amount);

public sealed record PlayGrantRequest(
    string Currency,
    string Reason,
    string IdempotencyKey,
    IReadOnlyList<PlayGrant> Grants);

public enum PlayGrantOutcome
{
    Granted,
    AlreadyGranted,
    UnknownPlayer,
    AccountClosed,
    Failed,
}

// GET /admin/settings/play-grant-ceiling
public sealed record PlayGrantCeilingView(
    long Default,
    long? Override,
    long Effective);
backoffice/Poker.Admin.Api/Endpoints/PlayGrantEndpoints.cs — the request, the outcomes and the ceiling, with the doc comments left out and the declarations reflowed to fit.

The whole operation

Beyond the tables.
Players, payments, partners and proof.

Know your players, move their money, grow the room and answer the regulator.

01

KYC review and payments queues

Identity review with the vendor's checks, the withdrawal review queue, a payments explorer and the players' funds.

02

CRM and campaigns

Segments built from rules, tags and notes on players, and scheduled campaigns with A/B splits sent through consent-gated messaging, each with its cost and return. A referral programme and the Partner API carry segments and events outwards.

03

Affiliates and agents

Affiliates with tracking links and multi-level plans — revenue share or a fee per player — and statements. Agents and sub-agents work on a prepaid float, see only their own downline, and settle commissions as ledger entries a second person decides. Agents are on only where a market's pack allows them.

04

Risk and fraud cases

Collusion, multi-accounting, bot and real-time-assistance detection, worked as cases.

05

BI dashboards and regulator reports

The returns each regulator asks for — the MGA's and the UKGC's first — generated as each period ends, and a BI page with active players, retention, rake per active player and conversion, canned and scheduled reports, and ad-hoc queries on a read-only replica. The warehouse is fed by player id only.

Tour the back office.
With your own team's roles.

A live walkthrough of the engine, the back office and a production-shaped cluster — with the numbers behind every claim on this site.

Request a demoLicensing options