The line between Zoho CRM data sharing vs field-level security is exactly what a billing manager at a healthcare client called us about, in a mild panic: a front-desk hire could see patients' Social Security numbers. Someone had set the Contacts module to "everyone can view everything" to make scheduling easier, and in doing so had also exposed every sensitive field to every user. The fix took twenty minutes once we separated the two questions that were tangled together — which records should this person open? and which fields on those records should they see? Those are two different controls in Zoho CRM, and confusing them is the most common security mistake our Zoho CRM consultants get called in to unwind.
Data sharing and field-level security both sound like "who can see what." They're not the same tool. Data sharing controls row-level access — which records a user can open. Field-level security controls column-level access — which fields on a record a user can see or edit. They aren't alternatives; they're complementary layers, and almost every well-run Zoho org uses both. Here's how each works, how they stack, and how to decide.
Data sharing is Zoho CRM's record-level access model: it decides, per module, which records a user is allowed to view, edit, or delete based on ownership and the role hierarchy. Think of it as the door to each record — data sharing decides whether that door opens for a given user at all.
It's built from three settings that work together, applied in order from broadest to narrowest.
Organization-wide default sharing. Set per module, this is the baseline. Zoho gives you four levels:
Private — only the record's owner and their superiors in the role hierarchy can see it. This is the default, and the right starting point for most sales data.
Public Read Only — everyone can view others' records but not edit or delete them.
Public Read/Write — everyone can view and edit others' records but not delete.
Public Read/Write/Delete — everyone can view, edit, and delete.
The role hierarchy. Roles model your reporting structure. A user's superior can access that user's records; peers at the same level can't see each other's data by default. Roles answer the question "what's your position?" — and they drive record access, not field access.
Data sharing rules. When the org default is Private but a specific team still needs cross-team visibility, sharing rules extend access. Critically, they can only grant additional visibility — never restrict below the org default. Two kinds:
Record-owner-based — share records owned by one role or group with another role or group.
Criteria-based — share records matching conditions, for example "Billing Status = Open," regardless of who owns them.
You configure all of this under Setup → Security Control → Roles and Sharing → Data Sharing Settings, and it takes the "Manage Data Sharing" permission. One rule that surprises admins: "Share Data with Peers" always takes precedence over data sharing rules — if peer sharing is on for a role, it wins.
Field-level security is profile-based control over individual fields: once a user can open a record, it decides which fields on that record they can see and edit. Where data sharing is the door to the record, field-level security is which drawers inside the room are unlocked.
It's set per profile, per field, in three states:
Read & Write — view and edit the field.
Read Only — view but not edit.
Don't Show — the field is hidden entirely; the user can't see or edit it.
Profiles answer a different question from roles: "what are you allowed to do?" You configure field permissions under Setup → Customization → Modules and Fields → [module] → Fields → Field Permissions, tied to each profile. This is how you hide a Social Security number, lock a discount percentage to read-only for reps, or keep a cost field visible to finance and invisible to everyone else — without changing who can open the record.
Strip the feature names away and the distinction is clean:
Data sharing | Field-level security | |
Controls | Row / record access — which records | Column / field access — which fields |
Granularity | The whole record | An individual field |
Tied to | Roles (hierarchy) + groups | Profiles |
Configured in | Security Control → Data Sharing Settings | Customization → Fields → Field Permissions |
Default state | Private (owner + superiors) | Field visible unless restricted |
Direction of effect | Rules only grant extra access | Restricts down to read-only or hidden |
Answers | "Whose records can you open?" | "Which fields can you see/edit?" |
Typical use | Territory separation, "reps see own deals" | Hide SSN, lock discount %, mask cost |
A user can be blocked at either layer. If data sharing won't let them open a record, field-level security never even comes into play. If data sharing does let them in, field permissions still decide what's visible once they're there. That's why they're layers, not a choice.
Every time a user tries to see data, their effective visibility is whatever survives all the layers in sequence:
Org-wide default sets the baseline — Private locks records to owners and superiors.
Role hierarchy lets superiors see subordinates' records.
Data sharing rules (and peer sharing) extend access sideways where you've allowed it.
If the record is visible after those three, field-level security then hides or locks specific fields per the user's profile.
Row access first, column access second. Miss that order and you get exactly the healthcare client's problem: someone loosens the org default to make records easier to find, and inadvertently exposes every field on every record because they never set field permissions.
The everyday case shows both layers doing their jobs on one record.
Your Deals module default is Private, so a rep sees only the deals they own — that's row-level. Their profile sets the Discount % field to Don't Show — that's column-level. Result: the rep opens their own deals but can't see the margin they're giving away. Their sales manager, a superior in the role hierarchy, sees the whole team's deals and the Discount % field. Same records, two different views, produced by two different controls. Neither one alone would do it — data sharing gets the rep to their deals, field-level security keeps the sensitive number out of the picture.
Now the higher-stakes version, which is what we built for that clinic.
Contacts default = Private, so front-desk staff see only patients assigned to them.
SSN, Insurance Policy Number, and Diagnosis Notes are set to Don't Show on the front-desk profile and Read Only on the billing profile.
A criteria-based sharing rule grants the billing team read access to any patient flagged "Billing Open" — without exposing SSN to them.
Physicians, higher in the role hierarchy, see their patients plus the full clinical fields.
The outcome: front desk sees their own patients and no SSN; billing sees billing-flagged patients with SSN read-only; physicians see everything clinical for their patients. That's least-privilege access — each person sees the minimum they need — assembled entirely from the two layers.
It matters because insiders are a real threat surface, not a theoretical one. Verizon's 2024 Data Breach Investigations Report, as reported by the HIPAA Journal, found that internal actors were responsible for a large share of healthcare-sector breaches — the kind of exposure that over-broad record access and unrestricted fields create. When a front-desk login can read a Social Security number, you haven't just made a config choice; you've widened your breach surface. (Breach statistics shift year to year — re-check the current DBIR before quoting a specific figure.)
This is where a plan can hit a wall, so check it before you design.
Organization-wide default sharing is available across paid editions — every serious deployment can set modules to Private and use the role hierarchy.
Data sharing rules scale by edition: per Zoho's current feature comparison, Enterprise supports up to 25 rules per module and Ultimate up to 100. Standard is limited to the org-default level without the fuller rules engine.
Field-level security is, per Zoho's current feature comparison, an Enterprise-and-above capability. Because Zoho re-tiers features periodically, confirm the exact edition floor on Zoho's feature list before you commit — if your security model depends on hiding fields, that dependency may set your edition.
For scale, the granularity itself is edition-bound: Enterprise supports up to 250 roles and 25 profiles, Ultimate up to 500 roles and 200 profiles (per Zoho's feature comparison). If your org chart is complex, that ceiling is worth knowing early.
The same handful of mistakes show up on almost every account we audit:
Loosening the org default to "fix" findability. Someone sets a module Public so records are easier to locate, and silently exposes every field to every user. The right fix is a sharing rule or a better list view, not opening the whole module.
Assuming a hidden field is secure everywhere. Field-level security is per profile. Hide SSN on one profile and forget another, and it's still exposed to that second group. Audit every profile, not just the obvious one.
Using roles to do a profile's job (or vice versa). Roles control records; profiles control fields and permissions. Trying to hide a field by moving someone in the hierarchy doesn't work — and trying to restrict records with field permissions doesn't either.
Forgetting peer sharing overrides rules. Turn on "Share Data with Peers" and your carefully scoped sharing rules can be undercut. Know which switch wins.
Every one of these is the same underlying error: reaching for the wrong layer because the row-versus-column distinction wasn't clear. Map the two questions first — whose records, which fields — and the configuration falls out cleanly.
Getting a security model right in Zoho CRM — especially when PII, HIPAA, or multi-team access is involved — is exactly the kind of work our Zoho integration team does, and when stock controls aren't enough we can extend them with custom software developers. Book a free Zoho consultation and we'll audit your sharing and field permissions before a bad default becomes a bad headline.
Data sharing and field-level security answer two different questions: which records a user can open, and which fields on those records they can see. Data sharing is row access, tied to roles; field-level security is column access, tied to profiles; they stack in that order, and real deployments use both. Set your modules to Private, extend access deliberately with sharing rules, then lock or hide sensitive fields per profile — and confirm your edition supports the pieces you're counting on. If you're modeling this for the first time, our primers on what leads are in Zoho CRM and Zoho CRM Blueprint pair well with a solid security design. Ready to get it right? Book a free Zoho consultation with our team.
By the CodeStringers Team — Zoho Experts & Custom Software. CodeStringers is a custom software engineering firm with a dedicated Zoho practice, 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:
Zoho CRM Sharing Rules, Explained: Granting Access the Hierarchy Can't (article)
The Field You Add Today Is The Migration You Pay For Later | Zoho CRM Custom Fields (video)
Nobody Is Allowed To Change Production | Zoho CRM Sandbox And Change Control (video)
Yes. A field set to Don't Show for a profile is excluded when that user exports records, builds reports or calls the API with their credentials. That makes field-level security a real control rather than a display setting. Integration users need their own profile, so review what an integration can read before connecting it; an integration running as an administrator sees every field on every record.
No. Removing a field from a page layout only changes the form; the field remains readable through reports, exports, list views and the API. Field permissions on the profile are what restrict the data itself. Use layouts to tidy forms and field permissions to protect data. A common mistake is assuming a field removed from the layout is private when it is only out of sight.
Yes. Zoho CRM lets you mark fields as containing personal data and encrypt selected fields at rest so their values are stored encrypted and visible only to permitted users. Encrypted fields have limits on searching and filtering, so apply encryption to identifiers such as government ID numbers rather than to fields used in daily filtering. Combine encryption with field permissions for the strongest protection.
Yes. Field permissions are set per profile, so the same discount field can be read and write for managers, read only for reps, and hidden for support. This is the common pattern for pricing, cost and commission fields. Review the matrix when a new profile is created, because a new profile is often cloned from an existing one and inherits its access to sensitive fields.
Export the field permission settings per profile for the modules that hold sensitive data and review them in a spreadsheet, looking for profiles that can see fields they do not need. Check the audit log for changes to profiles and field permissions. Then log in as a test user on each profile and open a record to confirm what is visible. Repeat after any profile change and at least twice a year.
"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.
