Roles and Permissions Explained

Perceny decides what a person can do in three layers. Understanding the layers is what turns "they cannot see the page" from a mystery into a thirty-second fix.

Layer 1: the role

Every member has one of four roles:

• Stylist — works, sells, sees their own book.
• Cashier — takes payment at the desk, usually across everyone's tickets.
• Manager — runs the day: staff, schedules, approvals, most settings.
• Owner — everything, including billing and configuration.

Each role ships with a default set of permissions. That default is the baseline everything else is measured against.

Layer 2: what you changed for the whole business

You can add permissions to a role, or take them away, for your business. Those edits live inside Features Configuration, on the tab that owns the category:

• Ticket permissions → Ticket Settings
• Appointment permissions → Appointment Settings
• Payment permissions → Payment Settings
• Kiosk, Client, Member, Product, Room, Dispute, Invoice, Summary → their own tabs

Each of those tabs opens with a small tab strip — Stylist / Cashier / Owner / Manager — and the permissions for that category underneath.

Changing one there changes it for everyone with that role.

Layer 3: this one person

An individual can be given a permission their role does not have, or denied one it does. That lives on the member editor's Permissions tab.

Use this for genuine exceptions — the senior stylist who also does the banking — not as a substitute for setting the role up properly. Ten individual overrides are ten things to remember when somebody new joins.

How the layers resolve

Role default → business-wide edits → this person's overrides. The most specific wins.

That order is why a stylist can lose a permission the role normally has, and why granting one to a role does not override an individual denial.

Strict and non-strict checks

Some checks in Perceny are strict and some are not. A non-strict check honours the "all permissions" allow-list and the global-manager bypass; a strict check does not.

This matters when you are auditing what someone can reach: a manager may pass a non-strict check on a surface they were never explicitly granted. If you need a hard boundary, the check needs to be strict — that is a product decision Perceny has already made per surface, not something you configure.

Permissions vs. settings vs. preferences

Three different things, often confused:

• A permission decides whether someone may do something. "Can they refund?"
• A setting decides how the product behaves for the business. "Do we ask for a tip on the terminal?"
• A preference is one person's override of a setting. "Do I get walk-in notifications?"

"They cannot see the page" is nearly always a permission. "It behaves differently for them" is nearly always a preference.

A worked example: refunds

You want only managers and one senior stylist to refund.

1. Features Configuration → Ticket Settings, open the permissions block, switch to the Stylist tab, and remove the refund permission. Every stylist loses it.
2. Check the Cashier tab — remove it there too if the desk should not refund.
3. Open the senior stylist's member editor → Permissions, and grant refund back to them individually.

Now the rule holds for everyone, including people who join next month, and the exception is recorded where anyone can see it.

Auditing

Two places tell you what actually happened:

• Audit Logs — who changed what, and when.
• Requests — what people asked for and who approved it.

If a permission has drifted, the audit log will tell you who moved it.