Roles at a glance

basic

Who can do what in Apolaris AI — employees, site-scoped users, privilege admins, managers, and franchise/HQ operators — and what Apolaris operates for you.

Apolaris AI does not lock people into a handful of fixed roles. Instead, access is built from granular permissions (called privileges) that you turn on or off per person. You assemble each person's "role" by giving them exactly the access they need — nothing more.

This page is the quick map: the common shapes a real role tends to take, what each one can touch, and where the line falls between what you control and what Apolaris operates for you behind the scenes. For the exhaustive list of every individual permission, see the Privileges reference.

How access really works

There are no pre-baked role names in the product. Three things, combined, decide what any one person can do:

The manager flag (is_manager). A manager passes every privilege check, unconditionally, across your whole organization. There is no feature box a manager fails.
Individual privilege boxes. A non-manager needs the specific privilege for each action. Granting "view customers" does not also grant "edit customers" — each switch is separate. Managers always pass; everyone else needs the exact privilege.
Site visibility. Almost everything is scoped to the sites (locations) a person can see. Managers see every site; everyone else sees a calculated set (explained under Site scoping).

Because roles are built from switches, two people you'd both call "a receptionist" can have different access. When you wonder "can this person do X?", the answer is never the job title — it's which privilege boxes are ticked and which sites they can see.

You set all of this on the Users & privileges screen. See Users & privileges for the step-by-step, and Employees, users & permissions for how an employee record and a login account relate.

You do not have to rebuild those switches for every hire. A privilege template saves a set of them under a name and applies it in one click on the user form; twelve defaults are provided and you can add your own. See Privilege templates.

The common role shapes

These are the patterns most organizations end up with. Each is just a particular set of privilege boxes — you can mix and match freely.

Role shape	Built from	Typically can	Sites they see
Regular employee (POS)	`can_use_pos` + `pos_only` plus a few task privileges	Use the scoped staff workspace ("Caja"): take bookings, ring up sales, view own earnings — only what's switched on	Their assigned sites
Site-scoped user	Specific privileges (e.g. `can_view_booking`, `can_add_sale`), no manager flag	Exactly the actions whose boxes are ticked, and nothing else	Assigned sites + any explicit grants
Privilege admin	`can_manage_privileges` (non-manager)	Create and edit other users and their privileges — but cannot grant the two protected flags (see the escalation guard)	Assigned sites + grants
Domain manager	`is_manager`	Everything in the organization, all sites, including managing users	All sites
Franchise / HQ operator	`can_manage_material_requests`, `can_manage_loyalty`, and/or `can_manage_discounts`	Run the brand-wide functions for the privileges they hold (central warehouse stock and orders, loyalty program, discount codes)	Depends on flags; HQ functions span the brand

Start everyone at the lowest set of boxes that lets them do their job, and add more when they hit a wall. It is easier to grant one more privilege than to discover later that someone could see more than they should.

Regular employee (portal)

A person with Use the POS (can_use_pos) may open the scoped staff workspace. This grant is additive: they still land in the management dashboard after signing in and keep every other privilege they hold — so a manager can be given the till without losing their own home screen. Inside the POS they only see the actions their other privileges allow. By default they can view their own earnings and bonus progress (can_view_own_earnings is on by default); other actions — taking bookings, ringing up sales, submitting expenses (can_submit_expense), using the contact center (can_use_ccaas) — each require their own switch.

To keep someone at the till and out of the CRM, add POS only — no CRM access (pos_only): they land in the POS after signing in and every management URL returns "contact your administrator". It requires Use the POS; on its own it does nothing, so a stray tick can never leave a person with no workspace at all. Anyone without Use the POS is simply redirected out of the POS — no second flag needed.

Site-scoped user

This is the most common non-manager shape: someone who is not a manager and holds a handful of specific privileges. They can do precisely what those boxes allow and see only their sites. A receptionist who should see the whole location's calendar (not just their own appointments) needs View whole-site schedule (can_view_site_schedule) on top of their booking privileges.

Privilege admin

You can delegate user management below the manager level. A non-manager with Manage Privileges (can_manage_privileges) can add, edit, and remove other users and their privileges, without being a full manager. This is useful when an office lead handles onboarding but should not have unrestricted access to everything else.

The escalation guard: a privilege admin cannot grant or toggle the two protected flags — is_manager and can_manage_privileges themselves. This prevents a delegated admin from quietly promoting themselves (or someone else) to manager, or from minting more privilege admins. Only a manager can hand out those two flags. The ability to administer privileges at all is can_admin_privileges(), which is true for any manager and for any non-manager with can_manage_privileges.

Domain manager

A manager (is_manager) has full access to the entire organization and every site, and always passes the privilege check on every feature — including managing users. Reserve this flag for trusted leads and owners. Everyone else should be built from individual privileges.

Franchise / HQ operator

There is no is_franchise or is_hq flag. "HQ" is simply a person holding the relevant management privilege, working against your organization's central warehouse(s):

Manage Material Requests (can_manage_material_requests) — curate the orderable catalog, control central warehouse stock, and approve/ship the orders sites place. (The site-side counterpart, Order Material from HQ / can_order_material, lets a location buy from HQ.)
Manage Loyalty Program (can_manage_loyalty) — configure the brand-wide loyalty tiers and reward catalog. (Site staff enroll customers and redeem with can_use_loyalty.)
Manage Discount Codes (can_manage_discounts) — create promo/influencer codes and read their impact report. (Applying a code at checkout rides on sales privileges; cashiers do not need this.)

An organization can have one or more central warehouses; transfers move stock between them. See Material ordering (franchise) for the full workflow.

A franchise/HQ operator who is not also a manager is still site-scoped for ordinary data. Their HQ functions (catalog, stock, loyalty config, discount codes) span the brand; their everyday operational data stays within their visible sites.

Site scoping

Most actions are limited to the sites a person can see:

Managers see every site in the organization.
Everyone else sees their linked employee's assigned sites plus any explicit site grants you add. (In code this is visible_sites_qs(): the employee's sites unioned with the visible_sites grants.)

So you can give a roaming supervisor access to two specific locations by linking them to those sites and/or adding explicit grants — without making them a manager. See Switching sites for how this looks day to day.

If someone "can't see" a customer, sale, or appointment they expect, check site visibility before privileges. The record may simply belong to a site outside their assigned + granted set.

Cross-data impacts to keep in mind

Roles decide who can take actions, and those actions ripple across the system. A few worth knowing when you hand out privileges:

A sale touches inventory, loyalty points, and analytics at once. Giving someone sales privileges means they can move all three.
A discount code lowers the net sale amount, which is the figure reports count — so granting discount management affects what your revenue numbers show.
Material ordering moves real stock between warehouses and sites; an HQ operator's approvals change inventory counts on both ends.

What Apolaris operates for you

Some things are operated by Apolaris — the company running the platform — rather than from within your organization: global configuration, and provisioning or removing whole organizations. These are performed by Apolaris on the platform itself; they are intentionally not part of your in-app management and are not documented as customer features.

Even a domain manager — who passes every privilege check inside your organization — cannot reach platform-operator screens. The most powerful role you assign is Domain manager. Anything beyond your organization's boundary is Apolaris's job; if you need a platform-level change, contact support.

Where to go next

Privileges reference — every individual permission and what it unlocks.
Users & privileges — how to create users and assign privileges.
Employees, users & permissions — how employee records and login accounts relate.
Switching sites — site visibility in daily use.