Permissions control which buttons, fields, and screens each staff member can see and use in Rundoo. They sit on each person's record so two people sharing a register can have entirely different access — a cashier who can ring sales but can't view costs, a manager who can void and refund but can't edit company-level settings, an admin with everything on.

In the Admin mode, open Staff in the left sidebar, click a staff member, and open the Permissions tab.

How the panel is laid out

The panel groups the permissions Rundoo ships into six sections that mirror the parts of the product they gate: Admin, Blocks, Customer Management, Inventory, Point of Sale, Reporting. Each section header carries Enable section / Disable section actions that flip every checkbox in that section together; All permissions at the top flips every section at once.

The top of the staff list shows each person's permission count as a fraction — e.g. 28 of 42 — so you can see at a glance who's a full admin and who's near a baseline cashier. Total today: 42 permissions, across the six sections.

Changes save per-checkbox; there's no Save button on this tab. Reload the panel after a change to confirm it stuck.

<aside> 💡 Permissions and POS security are separate layers. The Permissions tab decides whether the staff member can see the action at all; POS security decides whether they need a manager's PIN or login key to execute it. Voids, price overrides, refund-to-card, and below-cost sales typically need both — the permission turns the action on, POS security gates the actual click.

</aside>

How each permission below was verified

Every row in the tables below was checked by toggling the specific permission OFF on a dedicated test staff member (PERM, [email protected]), re-logging PERM into demo.rundoo.app so the client authorization cache reflects the new state, navigating to the gated surface as PERM, and observing what a real user would see in the UI. Nothing here was probed via direct API calls or network sniffing — every verdict comes from a screenshot or DOM-state observation. The Verified column captures the kind of UI evidence that grounds each row:

• ✓ render — a UI element (button, column, panel, nav item) physically disappears when the permission is OFF. Verified directly from the screenshot diff against the all-ON baseline.
• ✓ route — the page itself fails to load; the server blocks the underlying URL and the Rundoo error page replaces the content.
• ✓ hidden — a column or field disappears from a page that otherwise still renders (a specific case of render, called out separately because the surface is partial).
• needs data — the perm couldn't be exercised end-to-end in UI in this pass. Either the gated action lives behind a record in a specific state the demo doesn't carry (a draft inventory count, an open PO, an unrefunded bill payment, an active cart line) or the gated control still renders with the perm OFF and the click-time server-side rejection needs the modal's required-field set to be driven to a fully valid state before the gate fires — beyond what this UI-only harness scripted. Marked honestly per Rundocs Prime invariant: bias to 'couldn't verify' over speculation.

Four particularly clean before/after pairs from the harness — the kind of contrast that drove the ✓ render tag — are shown below.

Custom prices, promotions, spiffs — ON (left) vs OFF (right): Add custom price / Import custom prices disappear

Generate, import, deactivate gift cards — ON vs OFF: Generate / Import buttons and pending-card numbers disappear