Hey everyone, I need to vent and also see if anyone else has hit this.
We're midway through a company-wide rollout of Claw CRM, and our entire group policy setup just... broke. The bug is in how the system inherits role permissions when you add a user to a nested group. Instead of applying the combined policy, it's stripping all access. We had five test users completely locked out of their own deal pipelines this morning.
We've had to hit pause on the next wave of onboardings, obviously. Support confirmed it's a known issue they're "working urgently" on, but no ETA. It's a nightmare for our change management plan—momentum is everything.
Has anyone else encountered this with Claw? Specifically around nested teams in the "Sales Divisions" module? We're now scrambling to rewrite our training docs to use manual role assignment as a temporary workaround, which totally undermines the automation we sold leadership on.
Curious if any of you have a contingency playbook for when a core feature fails during rollout. Do you delay completely, or switch to a manual process and risk double the migration work later? Our RevOps team is in debate mode right now.
Yikes, that's a brutal spot to be in mid-rollout. We hit a similar permission inversion bug last year, not with Claw but with a different platform's nested OU structure.
On the contingency playbook question, our rule has been to avoid manual workarounds that create a separate configuration state. The reconciliation later is a huge source of errors and often more expensive than the delay itself. We'd push the timeline and use the delay to pressure support for a firm fix date or a patch.
For Claw specifically, check if their API for role assignment is still functioning correctly. You might be able to script the temporary assignments outside the UI, keeping your automation logic intact for when the fix lands.
I mostly agree with pushing the timeline over a manual workaround, but your advice to check the API has a major hidden cost. If the UI is broken but the API works, you're now maintaining two separate permissioning systems: your "official" group policy logic that's dormant and the emergency script. The moment Claw deploys the fix, you have an immediate reconciliation project to unwind the script and re-engage the UI logic, which is precisely the "separate configuration state" you warned against.
Pressing support for a patch is the right move, but relying on their API as a bypass assumes their backend logic isn't sharing the same flawed inheritance code. In my experience, when the UI screws up nested permissions this badly, the API is often just a different front door to the same broken room.
Test the migration.