Understand Permission Levels
Changelog: v4 adds the custom roles section. Live UI verification at store #99997 on 2026-05-04 confirmed 11 roles in the Permissions tab: the 8 default roles documented in v3 plus 3 store-specific custom roles (Advanced Team Member, Longterm Employee, Billing Portal). v4 adds a new Custom roles subsection explaining that stores can extend beyond the 8 defaults, documents what custom roles look like in practice, and updates the At a glance and pre-publish checklist accordingly. v3 enriched v2 from the official OneClick Permissions PDF. v2 grounded the article in concrete permission names from an example store's customization rubric. v1 framed the permission model correctly but used generic placeholders for examples. Em-dashes remain excluded.
At a glance
Permissions control who can do what across every OneClick module. This reference explains how roles relate to permissions, the eight default roles OneClick ships with, how stores can add custom roles beyond the defaults, how scheduling-platform sync creates accounts automatically, why OneClick articles never refer to roles by name, how terminations affect access, and how stores use a customization rubric to keep their role configurations organized.
Before you start
This is a reference article. Read it once, return when needed.
Core reference content
Roles versus permissions
Every team member has a role. Roles are containers for permissions. A permission is a single capability (for example, Manage Checklists, Stamp passports, View break reports). A role bundles permissions to represent a job function.
Role names are configurable per store. One store may call mid-level leaders "Shift Leader," another "Team Leader," another a custom title. Some stores use seven role tiers, others use five, others use eleven or more. This is why OneClick articles never say "a Shift Leader can do X." Instead they say "a role with the X permission can do X." The role name is local to the store; the permission is the universal concept.
Permissions are the stable layer. OneClick defines permissions and they do not change based on store configuration. If a store wants a different role to carry a permission, the role configuration changes, not the permission name.
Default role configuration
Out of the box, OneClick ships with eight default roles configured for a typical restaurant workflow. Each role can be renamed, reordered, hidden, or replaced with a custom role; additional roles can be added beyond the default eight.
| Role | Typical use |
|---|---|
| Service Account | Shared store device login (store iPads, public-facing devices) |
| Team Member | Baseline team member with limited app access |
| Trainer | Team member authorized to train others and rate passports |
| Team Leader | Frontline leader; starts passports, manages basic operations |
| Shift Leader | Runs shifts, manages breaks, stamps passports |
| Manager | Manages store configurations, reviews checklists |
| Director | Full access across the store |
| Operator | Business owner, typically granted Director-equivalent access |
The Operator role corresponds to the business owner. Operators rarely perform UI-level tasks directly; day-to-day OneClick use is by the Director tier and below. That is why OneClick articles address the reader as a leader or team member, not as the operator.
Custom roles
Stores can add roles beyond the eight defaults to reflect their specific organizational structure. Custom roles work identically to default roles: they are containers for the same permissions, named and configured to match how the store actually operates.
Custom roles appear in the Permissions tab alongside the default roles. They are added during store setup or via a support request at any time.
Examples of custom roles observed in live stores:
| Custom role | Typical use |
|---|---|
| Advanced Team Member | A mid-level designation between Team Member and Trainer, recognizing experienced team members who have not yet completed the Trainer pathway |
| Longterm Employee | A tenure-based recognition role, often carrying the same permissions as Team Member but used to distinguish long-tenured staff in reporting or scheduling |
| Billing Portal | A narrow service account variant that grants access to billing functions only, separate from the standard Service Account |
These examples are store-specific. Your store's custom roles will reflect its own operational language and structure. If you are unsure what custom roles exist at your store, check the Permissions tab on any team member profile or ask whoever configures roles at your store.
Custom roles follow the same two-permission-check pattern as default roles. A custom leadership role still requires both the Team Member checkbox and the custom role checkbox to be checked. Unchecking Team Member blocks sign-in regardless of what other roles are checked.
Automatic account creation from your scheduling platform
OneClick syncs automatically with your scheduling platform (HotSchedules or the CFA Home plus Vendor Bridge integration). Every team member on the schedule receives an automatic OneClick account. The team member signs in using the same email registered in the scheduling platform, then sets a new password specific to OneClick.
When a team member gains a new leadership role in HR, their OneClick permissions gain the matching role checkbox automatically, which grants access to any new features for that role. The reverse is true when a leader steps down or leaves: the leadership role checkbox is removed and access contracts automatically.
The two-permission-check pattern for leaders
Leader accounts need two permission checkboxes checked: the Team Member checkbox and the checkbox for their specific leadership role.
If the Team Member checkbox is not checked, the system treats the account as terminated and blocks app access, even when leadership role checkboxes are still checked. A leader with "Shift Leader" checked but "Team Member" unchecked cannot sign in.
A leader does not need to check every role below their current tier. A Shift Leader needs only Team Member plus Shift Leader; they do not need to also check Trainer or Team Leader.
The 3-day termination grace period
When a team member is marked as Terminated in your HR system, OneClick waits three days before applying the change. After three days, the Team Member permission is automatically unchecked, blocking app access.
The delay is intentional: it catches accidental terminations before they remove access, and it preserves the team member's record (passport progress, ratings, infractions) so leaders can still reference the history. Leadership-role checkboxes remain in place, but the unchecked Team Member checkbox blocks sign-in.
If a termination is reversed within the 3-day window, no access is lost. If it is reversed after the window, the Team Member checkbox must be re-checked manually.
Where permissions show up
Permissions gate actions across every module. Examples drawn from real OneClick features:
On checklists, each has a Required Permission Level setting that maps to permissions like View checklists, Review checklists, and Manage checklists. On passports, starting, rating, and stamping each require specific permissions (Complete passports, Create ratings, Stamp passports, and so on). On Ratings, answering a prompt, creating a rating, and viewing rating history are separate permissions (View rating prompts, Create ratings, View rating history). On Shifts, creating shifts, editing shift assignments, and running auto-schedule each have their own permissions (Create Shifts, Edit shift assignments, Autoschedule Shifts, Modify/Create Layouts). On Breaks, managing, running, and resetting breaks are separately permissioned (Manage breaks, Manage breaks - Run, Manage breaks - Reset). On Team profile actions, viewing emergency contacts, editing sign-in PINs, and editing permissions each have their own (View emergency contact info, Edit sign-in PIN, Edit permissions).
Some permissions are intentionally not configurable. For example, daily notes on the Shifts screen follow layout visibility: everyone who sees the layouts also sees the notes, and this is not a per-role setting.
How permission changes happen
Role-level permission editing is not fully self-serve in the current product. Some actions (like Edit permissions on an individual team member within your store's bounds) can be performed by a role with that permission, but the permission typically limits how far up a leader can assign (for example, Managers can grant access up to "Manager" but not to "Director"). Broader changes to the role configuration itself are handled through support.
Support can change the following for you:
- Add, rename, or move permission roles (the columns of the permission table)
- Adjust who can access different areas of the app (the checkmarks inside a row)
- Share best-practice recommendations observed in other high-performing stores
Contact support at OneClickApp.com/support. See Request a Permission Change for the full process.
Distribute the permission-change workload
Granting permissions is itself a permission, protected by the Edit permissions capability. Director-level roles have full access to every capability by default, which makes them the natural go-to for a permission change. The person who first set up the OneClick account for the store typically has Director-equivalent access at minimum.
Rather than always routing permission requests to the person at the top of your hierarchy, find the closest leader who already carries the Edit permissions capability and ask them. This distributes the workload across everyone qualified and keeps changes moving.
Common permission categories
OneClick permissions tend to fall into predictable shapes across modules. Understanding the shapes helps when reading a rubric:
- View permissions. Read-only access to a feature's data. Examples: View ratings, View passports, View checklists, View break reports, View shift assignments, View Checklist Report. These are the lowest-impact permissions, typically granted broadly.
- Creation and submission permissions. The ability to add new records or submit activity. Examples: Create ratings, Submit speed ratings, Create Shifts, Create One-Off Task, Add Recorded New Waste. Usually granted from Team Leader up, though it varies.
- Management and configuration permissions. The ability to change how a feature is set up. Examples: Manage checklists, Manage passports, Manage breaks, Modify/Create Layouts, Manage Vendors, Manage Cash Till Logs. These are higher-impact and typically granted from Shift Leader or Manager up.
- Certification and review permissions. The ability to approve, stamp, or mark work as reviewed. Examples: Stamp passports, Review checklists, Review/Complete One-Off Task, Complete passports. These govern the points where a leader's signature is required.
- Destructive permissions. The ability to delete, reset, or undo records. Examples: Reset passports, Manage breaks - Reset, Delete Task, Delete Messages, Delete history (ratings, infractions, and similar), Delete Employee Files. These are the highest-impact permissions and should be granted sparingly.
How stores manage their configuration: the customization rubric
A customization rubric is a spreadsheet that maps every OneClick permission to every role at a store, showing which permissions are granted to which roles. Each row is a permission, each column is a role, and each cell is a checkbox or similar indicator. The rubric typically includes a Notes column that explains why specific permissions are configured a particular way for that store.
A well-maintained rubric serves three purposes. First, consistency across stores. A multi-store organization can compare rubrics side by side and catch configuration drift. Second, onboarding new leaders. A new Shift Leader can look at the rubric and see exactly what their role can and cannot do. Third, audit before changing anything. Because a permission change request often affects multiple rows (one permission name may apply to many roles), the rubric is the fastest way to see the blast radius before submitting a change.
Rubrics are maintained outside the OneClick product itself, not built into it. If your store does not have one, ask whoever configures roles at your store. A rubric is not required to use OneClick, but it is the fastest way to keep a multi-role, multi-permission configuration organized.
Advanced-package permissions
Some OneClick permissions require an advanced package to be enabled. For example, Manage break reports sits behind an advanced breaks package. If a permission exists in the feature list but the action is not available in the product for any role, check whether the advanced package is active for your store. [VERIFY: canonical list of advanced packages and which permissions each unlocks.]
The "Requires support team action" principle
Many permission-related tickets end up categorized as "Requires support team action" because the change needs engineering or CS to apply. This is intentional; the permission system has enough blast radius that self-serve edits would be higher-risk than routing through support. Articles in the KB make this explicit so you do not waste time hunting for self-serve options.
Reading permission-based language in the KB
When an article says "You need a role with the Manage Checklists permission":
- Check your role's permissions, or ask whoever configures roles at your store. If your store has a customization rubric, find Manage Checklists in the permission list and see which roles are checked.
- If your role does not carry the permission and should, submit a Permission Change request.
- Do not swap into a different role to get access; the permission system is the correct lever.
Video
Not planned.
Common gotchas
An article references a permission name I do not see in my role settings. The KB uses canonical OneClick permission names. Your store's role settings should show the same names. If they do not, submit a Permission Change request and ask support to clarify.
I assigned a team member a new role and they still cannot do the thing. Role changes can take a fresh login to propagate. Have the team member log out and back in. If the capability is still missing, confirm the role actually carries the permission, and that the team member still has the Team Member checkbox checked alongside the leadership role.
A team member was marked Terminated in HR but can still sign in. The 3-day grace period has not elapsed. Wait the three days, or have support manually uncheck the Team Member permission if the termination is urgent.
A team member was marked Terminated by mistake and I want to restore access quickly. Re-activate in HR within the 3-day grace window and no action is needed in OneClick. After the window, the Team Member checkbox must be re-checked manually.
A leader has their leadership role checked but cannot sign in. The Team Member checkbox is probably unchecked. Both are required for a leader account.
Two stores have the same role name but different permissions. Role configurations are per store. In a multi-store organization, audit role configurations (ideally via each store's customization rubric) periodically to keep them consistent.
I need to give one team member a one-off permission without changing their role. Not supported. Permissions flow through roles, not direct assignments. Either assign a role that carries the permission or request a role configuration change.
A permission exists in the rubric but the feature does not appear in the product. Some permissions require an advanced package to be active (for example, Manage break reports requires the advanced breaks package). Confirm the package is enabled for your store before assuming the permission itself is broken.
Some permissions are checked for every role and cannot be changed. A handful of permissions are intentionally not configurable (for example, visibility of daily notes on the Shifts screen follows layout visibility). These are correctly not adjustable; they are product behavior, not configuration.
I see roles in the Permissions tab that are not in the default list. Your store has custom roles configured. Custom roles work the same way as default roles. Ask whoever manages permissions at your store for a current list, or check your store's customization rubric if one exists.
Related articles
- Request a Permission Change (How-To Guides)
- Submit Feedback Through the Voice Matters Program (How-To Guides)
- Why a Permission Change Has Not Taken Effect (Troubleshooting)
- Understand Your Customization Rubric (Reference)
- Understand the Service Account (Reference)
Still stuck
If the permission model produces unexpected behavior, submit a support ticket with your store number, the team member and role involved, the specific action failing, and screenshots of the permission list or the rubric row in question.
Pre-publish checklist status
122 842df528-761d-4f97-b623-f2b5d51b84f8 complete Seven sections filled (Reference adaptation).
123 b6713967-540b-47ec-a9df-6ab348d6843d complete No em dashes.
124 b145a31f-504d-4374-aa41-ec4529ea3735 complete No hedge words.
125 b84e3062-bbe9-4e66-90a0-d5ee48fa9310 complete Role references are permission-based throughout.
126 c8938c11-5a35-4087-a4c6-a14d2099dba7 complete Voice: operator is not the subject of OneClick actions.
127 f5c92732-3303-4e1e-bb46-7de6cb9813ac complete At a glance strictly v0.3-compliant.
128 2a59383b-7729-4ac0-9a81-8c86a02cbe6e complete Canonical permission names grounded in real OneClick feature list.
129 1f7a3a52-47f2-467f-b607-cfc9baa1afe8 complete Rubric-as-store-tool concept introduced.
130 f76d19fa-1894-44f8-a71b-da6eb775983e complete Advanced-package caveat added.
131 597e6c73-5f6b-4b3c-8c40-d25fec30ba4a complete Non-configurable-permission caveat added.
132 80ed39c3-32e4-4f27-9856-1a77ca366097 complete No real store numbers in body or metadata.
133 cea0f8e4-8e4b-45fd-bc8e-6fb2242dbdf1 complete Default role configuration (8 defaults) documented and live-verified 2026-05-04.
134 28189d3c-faac-4d9e-aa25-1e96cf58501a complete Custom roles section added. 3 confirmed examples from live UI (Advanced Team Member, Longterm Employee, Billing Portal). Framed as store-specific examples, not universal defaults.
135 097dfd99-c40f-4856-9808-69b6e328778b complete Custom roles gotcha added.
136 31edb713-6f42-448b-ad15-3c3f34163209 complete Two-permission-check pattern applies to custom roles. documented.
137 8895674f-1938-4d2f-895b-b71fe2b8ef04 complete Two-permission-check pattern documented.
138 1eca0cb2-211a-4ce3-ba11-51be89e7fc99 complete 3-day termination grace period documented.
139 af85b298-8250-4432-8eff-4998402df5ab complete Automatic account creation from scheduling platform documented.
140 27f8447a-e17a-4b4f-b843-7d828ce79fd2 complete Distribute-the-workload guidance added.
141 0fbd4d4e-b820-4de6-a5eb-bc19760b6573 incomplete VERIFY block resolved (canonical list of advanced packages).
142 3a03b6f1-f037-4931-800f-b4a0e243794b incomplete Reviewed by Jared and Kevin.