Zoho CRM Data Sharing vs Field-Level Security: Which Controls What?

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.

What is data sharing in Zoho CRM?

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.

What is field-level security in Zoho CRM?

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.

The core difference: rows vs columns

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.

How the layers stack

Every time a user tries to see data, their effective visibility is whatever survives all the layers in sequence:

1. Org-wide default sets the baseline — Private locks records to owners and superiors.

2. Role hierarchy lets superiors see subordinates' records.

3. Data sharing rules (and peer sharing) extend access sideways where you've allowed it.

4. 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.

A worked example: the sales rep

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.

A worked example: healthcare and PII

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.)

Which editions do you need?

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.

Where teams get it wrong

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.

Zoho CRM data sharing vs field-level security: where this leaves you

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.