Skip to main content
Back to documentation

Roles & permissions

Owner, admin, member, and franchise-owner access — who can do what.

Browse documentation

Access in Mezbano combines platform role, brand membership, and store role. The active plan and enabled modules can narrow which otherwise role-allowed screens are available. Store roles build from member to admin to owner; brand and platform access are separate paths that can grant an owner-equivalent store context.

Store roles

Owner

The highest level of access to a store. An owner can do everything an admin can, plus the most sensitive financial controls — including reopening a finalized month, deleting eligible finance entries, and managing the store’s financial channels and item configuration.

Admin

Runs the store day to day: recording and editing finance entries, reviewing reports, finalizing a month, and exporting financial data. Admins can also manage store members and regional settings, subject to the checks on each action. They cannot reopen a finalized month, delete finance entries, or change owner-only financial catalog configuration.

Member

The operating role for team members working inside one store. Members can run enabled floor workflows such as checklists, temperature logs, and prep. On supported finance-entry screens, a member can create entries and edit only their own entry for the store’s current business day, provided the month is open. Members cannot view reports, finalize months, export financial CSVs, or open administration screens.

Franchise owner

A franchise owner receives owner-equivalent access to every store under their brand and can author shared brand catalogs, including costing and operations content. An operator with a single store appears as “Owner”; the “Franchise owner” label appears when the brand has more than one store.

Platform support

Mezbano platform administrators have privileged, owner-equivalent access for platform operations and support. Mutations are audited under the actual actor. When an administrator deliberately uses the impersonation workflow, the session is marked and mutation audits retain the administrator in the impersonatedBy attribution instead of presenting the action as solely the workspace user. See the security page for the assurance boundary around these controls.