Roles and permissions

1Club decides what an admin user can do from permissions, not from their job title. Each admin user holds one role, and a role is a default bundle of permissions. Every operation in the admin is gated on a specific permission, so two people with different roles can do the same thing whenever they hold the same permission. This page covers the five roles, the permission model behind them, exactly what each permission allows, and how to change a role’s permissions in Settings > Permissions.

​

Overview

• Five built-in roles - Admin, Manager, Front Desk, Instructor, and Member. Every admin user holds exactly one.
• Permissions decide access - a permission is written module.action.scope, and a role is just the set of permissions its holders start with.
• Four actions and a shortcut - View, Create, Edit, and Delete, plus Full access, which grants all of them at once.
• Three scopes - Organization, Club, and Own, from widest to narrowest.
• Customizable per role - an admin edits which permissions each role grants in Settings > Permissions. You cannot create a sixth named role.
• Owner and super admin - two capabilities outside the role list that bypass permission checks by design.

​

Roles

There are five roles and every admin user holds exactly one. The Member role has no admin access at all; members use the member portal and public apps.

​

Owner

Within the Admin role, an organization can mark one or more users as owner. Owners bypass permission checks entirely, and only an owner can delete the organization. Owner is a flag on the user’s membership, not a role. See Users.

​

Super admin

Super admin is a 1Club platform capability used by the 1Club team for support and provisioning. It bypasses organization permission checks and is not something you assign to your own staff.

​

How a permission is built

Every permission has three parts: module.action.scope. For example members.read.club is “view members, within a single club”.

• Module - the area of the product, such as Members, Bookings, or Billing.
• Action - what you may do there: View, Create, Edit, Delete, or Full access.
• Scope - how much of the organization it reaches: Organization, Club, or Own.

An operation always requires the narrowest permission that actually fits it. A screen that only lists things requires View. A button that changes something requires Create, Edit, or Delete.

​

Actions

Not every module offers all four actions. The editor only shows an action when granting it changes something real, so Marketing offers View and Full access while Members offers all four. The module reference lists what each one actually has.

​

Scopes

Club here is 1Club’s own word for one of your locations, which may be a gym, a studio, a court complex, or any other venue. It is the name of the scope, not a facility type. See Organizations and clubs. A wider scope automatically covers the narrower ones: Organization covers Club, and Club covers Own. So a user holding “View members (Organization)” satisfies any check for “View members (Club)”. Scope is why an Instructor stays in their own world. Their permissions are Own-scoped, so they run their own classes, bookings, and check-ins but cannot reach organization-wide surfaces like billing, staff, or settings, even where the action matches.

​

How the hierarchy plays out

Both hierarchies apply at the same time, so one grant can satisfy several checks:

• Full access covers View, Create, Edit, and Delete on the same module.
• Organization covers Club, and Club covers Own.

A Manager holding Bookings: Full access (Club) therefore passes a check for “View bookings (Own)” without holding it literally. That is the point of the model: you grant the least a person needs, and broader holders pass automatically.

​

What each permission allows

The modules below are in the order they appear in Settings > Permissions. Each one lists the actions it offers and what they unlock in the product.

​

Profile

Your own account details: name, photo, contact details, password, and language. Own scope only. Every staff role holds this by default. It never gives access to anyone else’s profile - that is the Members module.

​

Notifications

Your own notification preferences: which emails, push messages, and SMS you personally receive. Own scope only.

​

Members

The people and their records: contacts, members, tags, custom fields, and billing accounts. Two things are worth knowing here:

• Merging is a Delete. A merge absorbs one profile into another and removes it, so a role with Edit can correct a duplicate but cannot resolve it by merging.
• Archiving is an Edit. Archiving is reversible, so it does not need Delete.
• Viewing a member does not include their memberships. A role with member View but no membership View sees the profile - name, contact details, tags, bookings - with the memberships section empty. The expiring-memberships block on Home disappears the same way.

​

Memberships

The plans and passes a member holds: subscriptions, punch cards, and their remaining allowance.

• Cancelling is a Delete. It ends the membership and triggers its refunds, so a role with Edit can extend a membership but cannot call it off.
• Selling a pass as part of a visit is not this module. The “Add plan or pass” tab inside the booking and check-in dialogs, and selling at the till, ride along with the booking or check-in itself. Whoever may check a member in may also sell them the thing that gets them in.

​

Member directory

A deliberately limited roster: names and membership status, with no contact details. It exists so an instructor can see who they teach without being handed the member database.

​

Messages

The inbox, message threads, templates, and shared email inboxes.

​

Classes

The timetable: classes, their instructors, capacity, and schedule.

• Cancelling is a Delete. Cancelling a class cancels every member booking on it and triggers their refunds, so a role with Edit can reschedule and rename a class but cannot call it off.
• Own scope for a class write means sole instructor. An Own-scoped user may only change a class they teach alone, before and after the change, and a class they create can name only themselves. Own on View is looser: they see any class they teach, including one co-taught with a colleague, while the write actions disappear on it.
• Viewing a class does not include its attendees. The roster hanging off a class is Bookings: View.

​

Bookings

Bookings and waitlists, for classes and for area or court reservations.

• Delete means cancel. There is no hard delete for a booking. Cancelling carries refunds, notifications, and a knock-on to any order it belongs to.
• Own scope is not “bookings I made”. It is bookings assigned to the user, plus every booking on a class they teach. Unlike class writes there is no sole-instructor rule, so a co-taught class’s bookings belong to all of its instructors. Editing a whole recurring series additionally requires that no later occurrence belongs to another instructor.
• Cancelling a booking that is already checked in needs the Check-ins override described below, on top of Bookings: Delete.
• Bookings also get cancelled by neighbouring operations under their own permissions: cancelling a class, cancelling an order, cancelling an event, and resolving an instructor time-off conflict.

​

Check-ins

Recording and undoing attendance. Three overrides live behind Full access (Organization) specifically, and they are the reason to think before widening this module’s scope:

• Ignoring the check-in window. Normally a member can only be checked in from an hour before the class until the end of that day.
• Cancelling a booking that has already been checked in. This voids the attendance record and zeroes the instructor’s pay for it.
• Rewriting the entrance method after the visit was recorded and paid for.

By default those three land only on Admin, owner, and 1Club support, because Manager holds Check-ins at Club scope. You can delegate any of them to another role by granting it at Organization scope. You cannot take them away from an Admin.

​

Staff

The instructor roster and admin access for your team. Organization scope only - there is no Club-scoped version of this module. Staff management is bounded by a role hierarchy regardless of the permission. See Managing who has which role.

​

Billing

Transactions, invoices, payments, orders, plans, and revenue configuration.

​

Point of sale

Running the till. This module is layered on top of Billing rather than carved out of it, which makes it useful subtractively: you can grant “can work the register” without granting “can see the books”. Four things to know before granting it:

• Point of sale: View conveys member contact details and the organization’s order history. The register cannot attach a sale to anyone without the customer picker, so this is not a prices-only grant.
• A register-only cashier still cannot do back office. They cannot settle a customer’s outstanding invoice, and they cannot reverse a sale that has already been fulfilled - only discard a draft cart.
• To build a register-only cashier, grant Point of sale and revoke Billing. Unchecking Point of sale on its own does not stop a role that still holds Billing: Create from selling.
• A Point of sale grant widens timetable and roster reads to Club scope. An Own-scoped instructor who is also given Point of sale will see the whole club’s timetable and rosters. That follows from the grant, and it is a reason not to hand the till to instructors casually.

If your organization has the point of sale switched off in settings, the register refuses new sales regardless of permissions, while everything already on the books stays settleable.

​

Marketing

Deals and pipeline, promotions, automations, content, media, reviews, and the website builder.

​

Analytics

Reports and insights.

​

Products

The product catalog: products, brands, and product categories.

• Stock is not part of this module. Stock levels, ingredients, recipes, and deliveries sit on the same screens but belong to Inventory, so a catalog-only editor sees the product grid without the stock panel or recipe editor.
• Any single product permission reveals Revenue > Products. The write actions do not imply View, so a role granted only Create sees the section with Products as its only tab.
• A write action is useless without View. Every catalog screen loads through View, so the editor ticks View for you when you check a write action.
• The register reads the catalog through Point of sale: View, so a cashier prices a sale without holding a product permission.

​

Inventory

Stock, ingredients, recipes, suppliers, and deliveries.

​

Rentals

Lending gear out for a session and getting it back. This split is deliberate: the desk can lend and take back without being able to write off missing gear.

​

Cash

The cash drawer, cash movements, and expenses.

​

Permissions

Administering role permissions - the editor described below. This module is locked to Admin. It shows in the editor with an Admin only badge, an admin always holds it, and no other role can be granted it. That is what stops a role from widening its own access.

​

Modules that are not in the editor

Three modules are enforced by 1Club but are not per-role customizable. They always resolve from the role defaults.

​

Default permissions by role

This is what each role starts with out of the box, before any customization. Admin holds Full access (Organization) on everything and is not shown. Member holds nothing. Worth noticing in that table:

• Front Desk can book and check in, but not undo either. It holds View and Create on Bookings and Check-ins, not Edit or Delete. Grant Edit or Delete if your desk needs to amend or cancel.
• Front Desk reads members but does not amend them, and signs a member up to a plan without being able to extend or delete that membership.
• Instructors read their timetable but do not write it. A class is scheduled for an instructor, so Classes is View only, while the bookings and attendance on that timetable are theirs to run in full.
• Manager runs the gym but does not configure it. Settings is not one of the modules the editor can grant, so organization configuration stays with Admin and owner.
• Neither desk role maintains the product catalog - both read it. Catalog writes were admin-only before Products became its own module, and the defaults preserve that.

​

The Permissions page

Settings > Permissions is where an admin changes what each role can do. It is the whole permission model in one screen, and every checkbox on it maps to a real check in the product. Open it from Settings, in the Organization section. Only users holding the Permissions module reach it, which in practice means Admin and owner.

​

Reading the page

The page is two columns. On the left, the five roles. Each non-admin role carries a badge: Default if it still matches the built-in bundle, Customized if your organization has changed it. Select a role to load it. On the right, that role’s permissions, as one collapsible section per module. A collapsed section still tells you what the role holds there, on the right of its header - for example View, Create or Full access or No access - so you can read the whole role without opening anything. A search box above the list filters by module name, action name, and the words in a module’s description, and it also matches a pasted permission string like members.delete. Matches open automatically. Press Escape or click the clear icon to reset. The search survives switching roles, which is the point: comparing the same permission between Front Desk and Instructor is the usual reason to search. Selecting Admin shows the whole grid ticked and read-only. The Admin role cannot be customized, by design - it is the role that always has a way back in.

​

Changing a permission

Open a module and you get one row per action. Each row is a checkbox and, where more than one scope is meaningful, a scope dropdown.

​

Rules the editor enforces for you

The editor prevents the combinations that would produce a role that half-works.

• Checking a write action also checks View. A role with Edit but not View passes the write check and then fails on every list and detail screen it needs to aim that edit at. Unchecking View clears the write actions that depended on it.
• Full access ticks and locks the actions it implies. You cannot uncheck View while Full access is granting it. Uncheck Full access first.
• Only real permissions are offered. The action rows and scope options are derived from the checks the product actually performs, so there is no checkbox that quietly does nothing.
• A role cannot be left with nothing. Clearing every permission is indistinguishable from reverting the role, so the save is refused with a message pointing you at Reset to default instead.
• The Permissions module cannot be granted to another role. It renders with an Admin only badge and no working checkbox.

​

When a change takes effect

Permission changes are not instant. They apply the next time an affected user’s session refreshes, within about 15 minutes, or immediately if they sign out and back in. The page says so above the editor. If you are testing a change on your own account, sign out and back in rather than waiting.

​

Resetting a role

Reset to default on a role deletes your organization’s customization for that role and puts it back on the built-in bundle. It is enabled only when the role is actually customized, it asks for confirmation, and it warns you if you have unsaved edits it will also discard. There is no history to restore a customization from afterwards, so treat it as final.

​

What the editor cannot do

• Create a role. The five names are fixed. Pick the closest one and tailor its permissions.
• Customize Admin. Admin always holds everything.
• Customize Operations or Settings. Those modules always resolve from the role defaults.
• Take an override away from Admin. The organization-scoped check-in overrides, for instance, can be delegated to other roles but never removed from Admin.

​

Reading the Role permissions table

There is also a read-only view of the whole matrix, for when you are assigning a role rather than editing one. Open Settings > Users, invite or edit a user, and click the info icon next to the role picker. It shows every role against every module, with the actions each role holds and a scope badge such as (Own) where the permission is narrower than the organization. It reflects your organization’s permissions, including any customization, not the generic defaults. Roles with no permissions - Member - are left out, and so is the admin-only Permissions module. If the table cannot load your organization’s real sets it says so and falls back to the built-in defaults rather than showing nothing.

​

Managing who has which role

• Admins and owners manage every user and can assign any role, including Admin and the owner flag.
• Managers, through staff management, can invite, edit, reset the password of, and remove users whose role is below Manager - Front Desk, Instructor, and Member - and can promote someone up to Manager. A Manager cannot modify themselves, another Manager, or an Admin, and can never grant the Admin role or account ownership.
• A role is assigned when a user is invited and can be changed later by editing them. Changing a role replaces the old one; the owner flag is separate and is preserved.

This hierarchy holds regardless of permissions, on both the screen and the server. Manage it all under Settings > Users. See Users.

​

Worked examples

​

Hiring a receptionist at a racket-sports venue

Invite them as Front Desk. Out of the box they look members up, sign them up to a plan, book courts, check people in, take payment at the desk, lend rackets, and answer the inbox. They cannot change organization settings, see staff pay, or maintain the product catalog. Two adjustments are common. If your desk amends member records, grant Members: Edit. If your desk cancels bookings, grant Bookings: Delete - the default deliberately lets them book but not cancel.

​

Onboarding a coach at a jiu-jitsu academy

Invite them as Instructor. They see their own timetable, run the bookings and attendance on it, see the members they teach as names and membership status, read their own earnings, and send their own messages. They cannot open organization billing or settings. If you do not want instructors cancelling bookings on their own classes, remove Bookings: Delete. If you want them amending their own classes, grant Classes: Edit (Own) - it is off by default because a timetable is set for an instructor. Avoid granting them Point of sale: it widens their timetable and roster reads to the whole club.

​

Promoting a studio lead to run a location

Give a trusted senior staffer Manager. They run members and memberships, the timetable, bookings, check-ins, marketing, analytics, inventory, rentals, cash, and the till, and they manage Front Desk and Instructor accounts themselves, so day-to-day team changes no longer need an admin. They take payments but do not configure billing, and they cannot reach organization settings.

​

Building a register-only cashier

Start from Front Desk, then grant Point of sale: View and Create and revoke Billing entirely. Revoking Billing is the part that matters - leaving Billing: Create in place keeps them able to sell through the Orders screen, so unchecking Point of sale alone changes nothing. The result is a role that rings up sales but cannot see the books, settle an invoice, or reverse a fulfilled sale.

​

Adding a co-owner

Give them Admin and mark them as owner. Owners bypass every permission check and are the only users who can delete the organization. Reserve this for the people who actually own the business.

​

Tips and best practices

• Assign the lowest role that fits, then add. Start at Front Desk or Instructor and grant the one permission that is missing, rather than defaulting people to Admin.
• Grant the narrowest action that does the job. Prefer View, Create, Edit, or Delete over Full access when only one of them is needed. Full access absorbs anything added to that module later.
• Be deliberate about Organization scope. Club scope is the right default for staff. Organization is what unlocks the sensitive overrides described above.
• Remember that Delete often means cancel. On classes, bookings, and memberships, Delete is the destructive customer-facing action that triggers refunds and notifications. Withholding it is a real control.
• Keep owners few. Owners bypass every check and can delete the organization.
• Read the role, not the label. What a user can do is the sum of their permissions after customization, not the name of their role.
• Check the Customized badge before debugging. A role that behaves differently from this page’s defaults has probably been customized in your organization.

​

Troubleshooting

Issue: I changed a role’s permissions but the user still has the old access. Cause: Permission changes apply when the user’s session refreshes. Fix: Ask them to sign out and back in, or wait up to about 15 minutes. Issue: A Front Desk user can look a member up but not edit them. Cause: Front Desk holds Members: View by default, not Edit. Fix: Grant Members: Edit at Club scope in Settings > Permissions. Issue: A Front Desk user can book a member in but cannot cancel the booking. Cause: Front Desk holds Bookings: View and Create, not Delete. Fix: Grant Bookings: Delete at Club scope, or route cancellations to a Manager. Issue: I unchecked Point of sale but the role can still sell. Cause: The register and the Billing > Orders screen drive the same operations, and the role still holds Billing: Create. Fix: Revoke Billing from that role as well. See Building a register-only cashier. Issue: I granted a write action and the screen loads empty or errors. Cause: Write actions need the View on the same module to load the records they act on. Fix: The editor ticks View for you when you check a write action. If the role was configured some other way, add View back. Issue: I cannot uncheck View on a module. Cause: Full access is granting it through the hierarchy, so the row is ticked and locked. Fix: Uncheck Full access first, then pick the individual actions you want. Issue: My save was refused with a message about keeping at least one permission. Cause: You cleared every permission for the role, which is indistinguishable from reverting it. Fix: Use Reset to default if that is what you meant, or leave at least one permission checked. Issue: An Instructor cannot see organization billing or settings. Cause: Instructor permissions are Own-scoped by design. Fix: This is expected. If the person needs that access, make them a Manager rather than widening the Instructor role. Settings still requires Admin. Issue: A Manager cannot change another Manager’s or an Admin’s role. Cause: Managers only manage roles below Manager, and can never grant Admin or ownership. Fix: Have an Admin or owner make the change. Issue: I want a brand-new role with a custom name. Cause: 1Club has five fixed roles. Custom named roles are not supported. Fix: Pick the closest role and tailor its permissions in Settings > Permissions.

​

Related

• Users - Invite and manage organization users and assign roles.
• Signing in - How staff authenticate into the admin.
• Organizations and clubs - How organizations and clubs relate, and what Club scope means.