Here are Zoho CRM roles and profiles explained: they are the two halves of security in the platform, and mixing them up is one of the most common setup mistakes we untangle. The one-line version: a role controls which records a user can see, and a profile controls what actions they can perform. Get both right and people see exactly the data they should and can do exactly their job — no more, no less. Getting that structure right from the start is core to how we set up systems as Zoho CRM consultants, and this guide makes the distinction stick.
It matters beyond tidiness. Verizon's 2024 Data Breach Investigations Report found the human element in 68% of breaches, and internal actors were the catalyst for 35% of breaches — up from 20% the year before (Verizon DBIR). Most of that is honest error, not malice — which is exactly why least-privilege access, built from well-designed roles and profiles, limits the blast radius when someone makes a mistake.
Think of it as two independent questions. Roles answer "whose records can this person see?" — they mirror your org's reporting hierarchy, and data visibility rolls up the tree. Profiles answer "what is this person allowed to do?" — which modules they can open, and whether they can create, edit, delete, export, or run admin operations.
They're set independently, and each user has exactly one of each. Two salespeople can share the same role (so they see the same slice of records) but carry different profiles (so one can export data and the other can't). When a profile permission and a role would seem to conflict, the profile governs the action — the role only ever governs record visibility.
A profile is a bundle of permissions (Zoho). It decides:
Which modules a user can access (Leads, Deals, Reports, and so on).
Which operations they can perform — create, edit, delete, view, export, send email.
Which admin and setup functions they can reach.
Zoho ships two defaults: Administrator (every permission) and Standard (a limited set). Most organizations build a handful of custom profiles from there — a "Sales Rep" profile, a "Read-only Exec" profile — matching permissions to what each group actually needs to do.
A role places a user in your reporting hierarchy, and that position determines whose records they can see (Zoho). The rules are simple but powerful:
A user sees their own records plus those of everyone below them in the hierarchy.
Data rolls up: a manager sees their reps' records; the reps don't see the manager's or each other's.
Peers can't see each other's data by default — there's a per-role "share data with peers" toggle if they should.
Every role must report to a superior role; the tree has to be complete.
Zoho's two default roles are CEO and Manager. The diagram below shows how visibility flows up a typical hierarchy.
When the pure hierarchy is too coarse — a peer genuinely needs to see another team's records — that's the job of data sharing rules, the exception layer that extends access without rewriting your org chart.
Role | Profile | |
Controls | Which records you see | Which actions you can take |
Answers | "Whose data can I access?" | "What am I allowed to do?" |
Based on | Reporting hierarchy | A set of permissions |
Defaults | CEO, Manager | Administrator, Standard |
Per user | Exactly one | Exactly one |
How many custom roles and profiles you get scales with your edition (Zoho):
Edition | Profiles | Roles |
Free | 2 | 2 |
Standard | 5 | 5 |
Professional | 15 | 25 |
Enterprise | 25 | 250 |
Ultimate | 200 | 500 |
Free and Standard leave almost no room to customize, so meaningful role and profile design really starts at Professional and up. (Zoho revises these caps periodically, so confirm against the live feature list when you plan.) The design principle that matters most is least privilege: start people with the minimum access they need and add more deliberately, rather than handing out broad permissions and clawing them back later. That discipline is a big part of the tight Zoho integration work we do as a business systems consultant, and it pairs naturally with how you've structured assignment rules and page layouts.
Sketch your org's reporting hierarchy first — that becomes your roles. Then, for each group in it, list what they actually need to do — that becomes your profiles. Designing the two separately, in that order, keeps you from the common trap of over-granting access just to make the hierarchy work.
If you'd like that structure designed properly the first time — especially if you're on Enterprise or Ultimate with real complexity — book a free Zoho consultation and we'll map your roles, profiles, and sharing rules to how your team actually operates, with least privilege built in from the start.
By the CodeStringers Team — Zoho Experts & Custom Software. CodeStringers is a Zoho and custom-software firm writing from work we've actually shipped for clients.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
How to Set Up Roles and Profiles in Zoho CRM (Without Locking the Wrong People Out) (article)
Zoho CRM Roles and Permissions: Roles Set Reach, Profiles Set Rights (article)
Your Forecast Is Wrong Because Nobody Configured A Pipeline | Zoho CRM Stage Probability (video)
Visibility recalculates immediately. The user sees the records owned by their new position and everyone below it in the hierarchy and loses sight of the old branch, while their own records stay with them. Managers who move sideways often lose access to a former team's deals, so check open deals and scheduled reports before the change. Record ownership does not change with the role; reassign records separately if the handoff needs it.
Yes, and that is the normal design. A role sets which records are visible and a profile sets which actions are allowed, so two reps on the same role can carry different profiles. One can export and the other cannot, while both see the same slice of records. When you need one user to do more, change or clone their profile rather than moving them up the hierarchy, which would widen what they see.
Groups are a sharing convenience, not a security layer. A group collects users, roles, or subordinate roles so that a data sharing rule or a record can be shared with the whole set at once, for example a deal desk that needs read access across regions. Groups never grant actions; the profile still decides whether a member can edit or delete what the group can see.
Yes. A report returns only the records its viewer could open directly, so the role hierarchy shapes every total. A regional manager's pipeline report shows that region's deals, and the same report run by the CEO role shows the whole organization. If a manager needs company-wide numbers without company-wide edit rights, give them a broad role with a read-only profile rather than the Administrator profile.
Field-level security hides or locks individual fields per profile while leaving the record visible. It is the tool for data that some people must see and others must not, such as approved margin, commission, or health information on a contact. Set it after roles and profiles are in place, keep the list of restricted fields short, and document who can edit each one so audits have a single answer.
Quarterly is a workable rhythm for most teams, with an extra check whenever someone changes team or leaves. Pull the user list, confirm each person's role still matches their reporting line and each profile still matches their job, and look for anyone on the Administrator profile who is not an administrator. Deactivate departed users promptly and reassign their records so forecasts do not lose deals.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
