Why a Permission Change Has Not Taken Effect
At a glance
A permission change that was applied correctly can still appear broken to the team member. In most cases the change did take effect; the team member's session has not yet picked it up, or the account configuration has a second requirement that was missed. This article walks through the ten most common causes in order of frequency, with the fix for each.
Before you start
- Confirm who changed the permission and when. The fastest causes to rule out (session cache, the two-check pattern) take minutes; the slowest (a support queue item, an advanced-package gap) take longer.
- Have the affected team member available to sign out and back in if needed.
- If your store has a customization rubric, keep it open. Several causes below ask you to confirm the role actually carries the permission.
Troubleshooting
Cause 1: The team member has not signed out and back in
Permission changes propagate on the next fresh sign-in. A team member whose session was open when the change was made will continue to see the old permissions until they sign out and back in.
Fix. Ask the team member to sign out of the OneClick app or the web interface and sign back in. On mobile, closing the app from the app switcher and reopening also works. On the web, a hard refresh (Ctrl+Shift+R or Cmd+Shift+R) is usually enough.
Cause 2: The leader account is missing the Team Member checkbox
Leader accounts need two permission checkboxes checked: the leadership role (Shift Leader, Manager, and so on) and the Team Member checkbox below it. If the Team Member checkbox is unchecked, the system treats the account as terminated and blocks app access, even when the leadership role is checked.
Fix. Open the team member's profile, go to Permissions, and confirm the Team Member checkbox is checked alongside the leadership role. Check it if missing, save, and ask the leader to sign out and back in. See Understand Permission Levels for the full two-check pattern.
Cause 3: The change is still in the support queue
Role-level permission changes (adding a role, renaming a role, moving permissions between roles) are not self-serve. They route through OneClick support and are applied by the engineering team. Depending on queue depth, the change can take a business day or two to land.
Fix. If a support ticket was opened, check its status. If no ticket was opened, open one now via OneClickApp.com/support. See Request a Permission Change for the submission process.
Cause 4: The change was never actually submitted
Some permission changes feel like they should be self-serve but require support. Editing who can do what at the role level, adding a new role, or moving a permission between roles are all support actions. A leader can set the Required Permission Level on an individual feature (for example, on a checklist) but cannot change what permissions a role itself carries.
Fix. Confirm what type of change was intended. If it is a per-feature setting (for example, "this checklist requires Manager permission"), the leader can set it directly on the feature. If it is a role-level change, open a support ticket. See Understand Permission Levels for the self-serve ceiling.
Cause 5: The termination 3-day grace period is still active
When a team member is marked as Terminated in your HR system, OneClick waits three days before unchecking the Team Member permission. If you recently tried to restore access to a team member who was terminated in HR, the grace period may still be applying the original termination, or the sync may not have run yet.
Fix. If the team member was terminated by mistake, re-activate in your HR system. Within the 3-day window, no OneClick action is needed. After the window, the Team Member checkbox must be re-checked manually by someone with Edit permissions access on the profile.
Cause 6: The role does not actually carry the permission
The permission you expected to gain may not live on the role you think it does. Role configurations drift over time; a Shift Leader at one store may carry permissions that a Shift Leader at another store does not.
Fix. Open your customization rubric if your store has one and look up the specific permission. Confirm which roles have it checked. If the role you assigned does not carry the permission, you need a different role or a rubric change. See Understand Your Customization Rubric.
Cause 7: The feature requires an advanced package that is not enabled
Some OneClick features are gated by advanced packages enabled at the store level. The permission may be granted correctly, but the feature itself is not available to any role until the package is active. Manage break reports is a common example; it requires the advanced breaks package.
Fix. Contact support to confirm whether the feature requires an advanced package and whether that package is active for your store. If it is not, support can activate it (may involve a package change and operator approval).
Cause 8: The permission is intentionally non-configurable
A handful of OneClick behaviors are not controlled by permissions. For example, daily notes on the Shifts screen follow layout visibility: everyone who sees the layout also sees the notes, with no per-role toggle. Trying to "grant" or "revoke" visibility on a non-configurable behavior will appear to do nothing because there is nothing to toggle.
Fix. Confirm the behavior is actually permission-gated. If it is not, the behavior is working as designed. See Understand Permission Levels for the category of non-configurable permissions.
Cause 9: A shared device is still signed in as the Service Account
If the team member is using a shared store device (iPad, shared tablet), the device may still be signed in as the Service Account rather than as the team member's personal account. The Service Account's permissions apply while the device is signed in that way, and the team member's personal permission change will not take effect until they sign in personally.
Fix. Ask the team member to sign out of the Service Account and sign in with their own credentials. See Understand the Service Account. For shift-critical actions that a team member must perform personally (ratings, infractions, passport stamps), personal sign-in is always required; the Service Account should not be used as a workaround.
Cause 10: The change was made at a different store
Multi-store organizations have per-store permission configurations. A change made at Store A does not apply at Store B. If a leader works across multiple stores, they carry one account but each store's configuration determines what the leader can do within that store.
Fix. Confirm the change was made at the store the team member is currently working in. If the team member works across multiple stores, each store needs the change applied independently.
Video
Not planned. Diagnostic articles lean on text; a video would be longer than reading the causes list.
Common gotchas
The permission change was applied but the leader says they still cannot do the action.
Work through the ten causes in order. Cause 1 (fresh sign-in) and Cause 2 (Team Member checkbox) together resolve the large majority of these reports. If neither applies, continue down the list.
We granted a permission and the team member can do the action but cannot see it in the menu.
Menu visibility and action permission are controlled together, but the client renders from cache on navigation. Full sign-out and sign-in, not just navigating back to the menu, is needed to re-render the client with the new permission set.
I want to test the change myself by logging in as the team member.
Do not share credentials. Ask the team member to sign in on their own device and confirm the action is available. If remote verification is needed, screen-share with the team member while they sign in.
The permission change was submitted to support three days ago and still has not landed.
Follow up on the ticket. Most changes are applied within one business day. A three-day delay without communication usually means either the ticket was not received or the change has a dependency (for example, an advanced package that needs operator approval).
Our rubric says the role carries the permission, but the product says otherwise.
The rubric is a local artifact maintained outside OneClick; it is not the source of truth. OneClick's permission settings page is the source of truth. If the rubric and the settings disagree, the settings are correct and the rubric is stale. Update the rubric to match reality.
Related articles
- Understand Permission Levels (Reference)
- Request a Permission Change (How-To Guides)
- Understand Your Customization Rubric (Reference)
- Understand the Service Account (Reference)
- Understand the Team Member Profile (Reference) for the Permissions tab on profiles
- Deactivate a Team Member (How-To Guides) for the 3-day termination grace mechanic
Still stuck
If a permission change is not taking effect after working through all ten causes, submit a support ticket with:
- Your store number.
- The team member's name and role.
- The specific permission involved and the action that is failing.
- A screenshot of the team member's Permissions tab showing all checked and unchecked boxes.
- The date and time the permission change was made, and how (self-serve edit, support ticket, HR sync).
- Whether the team member has signed out and back in since the change.
Support typically responds within one business day.
Pre-publish checklist
9 9858b6c0-3141-4672-bda7-acd5cbca0781 complete Seven sections filled (Troubleshooting diagnostic-sequence pattern).
10 90a99938-2eb6-403f-a7d2-787d01f2495c complete Ten ordered causes, most common first.
11 7fa3dc4c-f70c-422f-b2e9-5fcdb18fafae complete No em dashes, no hedge words.
12 32eaf56b-12dd-4a87-8aef-7d92a8724b04 complete Permission-based role references throughout.
13 9efa1cbe-ea98-46a2-bdbe-38bdadef4e32 complete Voice: leader and team member, not operator.
14 8c3d896c-c168-444d-b088-77ac4f495286 complete No real team member names or store numbers.
15 aa97a7b5-0465-48a1-8c56-61f392345ccc incomplete UI verified against Production.
16 d990ffcd-5a51-453b-b96d-58297ab40b44 incomplete Reviewed by Jared and Kevin.
Why this article exists
Surfaced by the Wave 1 cross-link map Pass 2 audit (Turn 38, Flag 38). Understand Permission Levels references this article as a placeholder in its Related list because permission-change troubleshooting is a common support-ticket pattern where the fix is usually a fresh login or a missed Team Member checkbox, not a product bug. Ten-cause diagnostic sequence should deflect a meaningful share of the customization-category ticket volume Dan has flagged as the 2026 deflection target.
Source
Composite from Understand Permission Levels v3 (394854401) with direct coverage of the two-check pattern, 3-day termination grace period, advanced package caveat, non-configurable permissions, and Service Account interactions. No new VERIFY blocks.