Locking down a wild Kansas City Zoho CRM.

The stated need was a Zoho CRM permission build to support a new business program. The program's data couldn't be widely visible, and that requirement was firm. The internal admin team had attempted to design the permission matrix themselves and hadn't been able to get it landed.

What the problem actually was.

The bigger picture: the CRM had been running with effectively no enforcement of permissions. The unrestricted visibility of records had already been creating some friction in day-to-day operations, but nothing serious enough to stop work. The new program changed the calculus — strict separation wasn't optional anymore, and that meant the organization had to do its first real exercise in deciding who should see what across 165 users and a dozen teams.

The rule set the admin team had created as a starting design was under-specified for what the system actually needed to enforce. Not because anyone had done sloppy work — because the organization had never had to think about permissions at this level of resolution before.

A custom module to silo the new program would have created duplicative architecture and a maintenance burden that didn't justify itself. The right move was to do the work properly inside the existing structure: roles, profiles, and sharing rules.

For the rest of this to make sense, three Zoho CRM concepts matter, and they're worth a sentence each.

Roles govern what records you can see. They follow the org hierarchy — if you're above someone in the role tree, you see their records.

Profiles govern what you can do. Which modules you can open, which fields you can edit, whether you can mass-delete, export, transfer ownership, and so on.

Sharing rules are the exceptions layer. They grant access across the role hierarchy when the hierarchy alone doesn't give you what you need — say, when Team A needs read access to Team B's accounts but not the other way around.

That's the simplified version we tell clients. Roles don't quite govern only what you see; profiles don't quite govern only what you do. But it's the right starting picture for most conversations.

Two constraints shaped the approach. The client's legal team would not allow a consultant to work in production data; everything had to be built in a Zoho CRM sandbox with fabricated test records. This was 2022, before AI-generated test data was a practical option, so the fake data had the limitations you would expect — uniform names, obvious patterns, edge cases that didn't exist until we constructed them by hand. And sales operations couldn't be interrupted, which meant cutover had to land cleanly in a single window.

Phase 1: Discovery in meetings.

The bulk of the project's hours were spent with the internal admin team, walking through specific scenarios. What does a regional manager see when they open the Deals module? What does an account executive see when their teammate is reassigned? What needs to be invisible to teams outside the new program? Most of the answers were sparse enough to raise suspicion. Whenever a permission matrix is clean and simple, it almost never reflects reality, especially for an organization of that size.

Phase 2: First build, rolled back.

We built the matrix in the sandbox against the design the admin team provided. When we got to implementation, several scenarios didn't behave the way the users required. Unfortunately, migration day was the first time we had heard of most of those requirements. To complicate matters, the admin team's testing of the first build was light — light enough that even the known requirements were not all implemented correctly. Work effectively stopped, and the matrix was immediately rolled back.

Phase 3: Independent validation.

The second attempt required a new approach. Zoho CRM sandbox permits up to five developer seats. One was ours. We used the remaining four to spin up test accounts and assigned them across the role and profile combinations that hadn't been exercised. Running through real scenarios as those test users surfaced cases the original design hadn't accounted for — interactions between roles, sharing rules, and field-level access that nobody had a reason to think about before the new program made it necessary. Doing that pass ourselves, rather than waiting on internal testing cycles, is what got the second build to a defensible place.

Phase 4: Rebuild and go-live.

The rebuild was done in the open. Rather than design the matrix privately and hand over a finished artifact, we built it on a shared Miro board so the admin team could follow every decision as it was made. There were no trade secrets to protect — none of the design was treated as proprietary or kept back, and the transparency was deliberate. We created a profile for each of the dozen or so internal teams — sales reps, sales managers, senior management, marketing, admins, and the rest — and laid them out across a series of grids: one to compare what each team could see, another for what each team could do. Putting it in that form made the gaps and overlaps obvious at a glance, which is exactly what the under-specified first design had been missing.

This time the testing was not left light. We assigned the sandbox developer accounts to the admins themselves and had them log in as mock users under a range of role and profile assignments, working through real scenarios. The people who would own the system after we left were the ones exercising it.

With the matrix validated, sharing rules and role hierarchy changes were sequenced to apply in a single low-traffic window. Cutover landed without interrupting operations. A few minor adjustments were needed on go-live morning — nothing significant — and the new program launched with its data properly separated from the rest of the business, albeit delayed.

Some of what changed is easy to measure. Some of it isn't, and pretending otherwise wouldn't be honest.

The measurable part.

The new program launched with its data properly siloed from the rest of the CRM. Go-live morning required a few minor tweaks but no rollback, no escalations, and no disruption to the 165-user base. The organization came out of the engagement with a complex permission model that actually worked.

The harder-to-quantify part.

The larger value was probably the method, not the matrix. Because the rebuild happened on a shared board and the admins did the validation themselves — logging in as mock users and watching where access broke — they came away with more than a working permission model. They had seen how one gets built and how it gets tested, in their own system, against their own scenarios. That was the part the first internal attempt had been missing, and it's the part most likely to outlast the engagement.

Whether the model stayed in sync with everything that came after isn't something we can speak to. Testing each new permission change against real scenarios is a discipline that has to be kept up once the consultant is gone, and that's genuinely outside our control. What we can say is that the model was correct on the day we handed it over — and that the people responsible for it had been shown how to keep it that way.