Inside the console¶
The admin console is one workspace over the whole platform. This page explains the ideas every other guide page assumes: how access works, what maker-checker means in practice, and the small set of layout patterns the screens reuse.
The shell¶
- Left navigation, grouped by what people do. Groups you have no access to are not shown. Groups remember whether you left them open.
- Command palette (
⌘K/Ctrl-K). The fastest way to reach any screen, and a live search over customers and accounts by name or number. - Header. Breadcrumb, the search pill, an environment chip (DEV / UAT / PROD), your identity with role and branch (or "All branches" for head-office roles), and a theme toggle.
- Live badges. The navigation surfaces work waiting on you: the pending Approvals count and an end-of-day pulse while a close is running.
- Home dashboard. A per-role work queue: the business date, end-of-day status, approvals to decide, screening hits, failed payments and your open till, plus quick actions and a "today" rail.
Access: two dimensions, not one¶
What you can do is decided by two independent things.
1. Functional permissions, named domain:action (for example account:open, journal:post,
payment:dispatch). Your role grants a bundle of them. A permission you do not hold hides the screen
or greys out the action.
2. Approval authority tier, how large an action you may authorise as a checker:
| Tier | Meaning | Typical limit |
|---|---|---|
| T1 | Checker | ≤ 1,000,000 |
| T2 | Senior checker | ≤ 10,000,000 |
| T3 | Manager | Unlimited |
Clearing a parked item needs both the matching approve permission and a sufficient tier. This is deliberate: authority is split by kind of action and by amount, so no single person both raises and authorises a large movement.
Branch scope
Some roles are branch-bound (a teller, a branch manager) and see only their branch; others are head-office and see the whole institution. Ledger, reporting, product, pricing, reference and tax functions are bank-wide regardless of role.
Maker-checker, in practice¶
Many actions do not take effect the moment you submit them. Instead the console tells you the item has been sent to Approvals, and a second person with the right permission and tier authorises it.
- Submitting is not a failure. A message like "Payment exceeds the auto-limit. A checker must authorize it in Approvals" is the system working as designed.
- The person who captured an action cannot authorise their own request (four eyes). Attempting to decide your own item is refused.
- You track your parked items, and decide others', in the Approvals queue.
Actions that route through maker-checker include large transfers and payments, loan approval and write-off, journal posting and reversal, teller cash over a threshold, FX conversion, bill payment, beneficiary registration, agent onboarding and payment recovery.
The layout patterns¶
Almost every screen is one of five shapes. Learn them once:
| Pattern | Used for | What to expect |
|---|---|---|
| Table + detail drawer | Registries (accounts, parties, reference data) | A filterable table; click a row to open a side drawer; a toolbar with search, filters and a create button. |
| Workspace + context rail | Teller, account detail | A main work area with a right-hand rail of status, quick stats and gated actions. |
| Wizard / stepper | Onboarding, loan origination, product creation | Numbered steps that save as you go, so Back and Next never lose data. |
| Tabbed workspace | Teller, compliance, the ledger | One subject, several tabs (for example Cashier / Tills / Vaults / Cash proofs). |
| Timeline / stepper monitor | End of day | A live vertical list of steps with status, counts and inline errors, plus run history. |
Two more conventions worth knowing:
- Typed pickers, not free text. You choose a party, branch, account, product, GL account or code from a searchable picker. Money is entered as an amount and a currency; rates and haircuts have their own inputs. This keeps references valid and currencies explicit.
- Pre-post review. Cash and high-impact actions show a review step (the charges the customer will bear, projected balances, signatures to verify) before anything moves.
Where to go next¶
Pick the module you operate from the user-guide index, or read Approvals & maker-checker next, since it underpins so much of the day-to-day work.