Who should see what in a clinic: structuring CRM access

Broad visibility can feel convenient while a clinic team is small. Once Zoho CRM becomes central to a growing operation, however, who can see a record and what they can do with it become separate decisions. A sound access structure starts with roles and profiles, then adds sharing, user fields, field permissions, and compliance markings where each layer serves a defined responsibility.

A new part-time call support worker opened their list on the first day and saw every patient record, treatment note, and imaging file in the clinic. Their only assignment was confirming the next day’s appointments. This situation creates more than a confidentiality concern. It also forces staff to navigate information unrelated to their work. Layered access aligns visibility with actual duties.

When universal visibility becomes a problem

During the first weeks, letting a few people see the same records may appear to simplify work. That convenience changes as the team grows, external support arrives, or an employee leaves. More people can access records than their duties require, while staff depend on personal filters and temporary habits merely to isolate the work for which they are responsible.

Job titles alone cannot resolve that problem. Consultants, coordinators, clinicians, and managers may use the same module without needing the same record set or actions. The existing default sharing setting must be checked first. Record visibility and permitted actions can then be separated, giving every responsibility a clear access route instead of relying on assumptions attached to a title.

Verify default sharing before defining roles

The default organization-level data-sharing setting for Zoho CRM modules is Private. The relevant check is whether somebody changed it during setup. The four levels are Private, Public Read Only, Public Read/Write, and Public Read/Write/Delete. The last two override role hierarchy and sharing rules, so choosing either one changes the foundation on which the remaining visibility structure operates.

Follow Setup, Security Control, Roles and Sharing, Data Sharing Settings, then Default Organization Permissions. Sharing rules can only expand existing access; they cannot narrow it. If a module’s base setting is already broader than required, adding a restrictive sharing rule will not repair the exposure. Confirming the foundation first makes later decisions about hierarchy and exceptions dependable.

Separate roles from profiles

A role determines which records a user can see. A profile determines what the user can do with records already visible to them. Someone in a superior role may reach a subordinate’s records through hierarchy, but hierarchy is insufficient if that person lacks Read or Edit permission for the module. Administrator-profile users can access all data regardless of their roles.

With Private access, two users in the same role have the same permissions but do not see each other’s records by default. Share Data with Peers or a sharing rule can open that visibility. If a superior should also receive data granted to a subordinate through a special rule, select Superiors Allowed in that rule. This keeps hierarchy distinct from deliberate exceptions.

The clinician often does not own the record

A clinician could not find a patient referred to them. The consultant owned the record, the clinician’s role was not above the consultant in the hierarchy, and no field on the record identified the clinician. Adding a role alone would not create the needed connection. Instead, add a Single User or Multiuser field and choose Read only, Read/Write, or Full access.

Access granted through that field remains subject to the additional user’s profile permissions. A module can contain up to five Single User fields and one Multiuser field. These user fields are unavailable in Tasks, Calls, and Meetings. Every Zoho CRM record has one owner. A shared pool therefore uses a dedicated user account as owner, with hierarchy or sharing providing visibility until assignment transfers ownership.

Images and attachments do not have separate visibility

Photographs, radiographs, documents, and other attachments are not fields, so field-level permissions do not hide them separately. Attachments, notes, and competitors inherit access from their parent record. A user who cannot see a patient record cannot reach its attachments either. Correctly defining base record visibility therefore determines who can reach the related material stored with that record.

Once the record is visible, profile permissions form a second layer. For Notes, the profile carries separate View, Create, Edit, and Delete permissions; for Attachments, the documented options are View, Create, and Delete. To add a note or attachment, or send an email from a record, the user needs read or read/write access to that record. Record access and the actions permitted on an attachment are therefore distinct decisions.

Not every field is equally sensitive

Seeing a patient record does not mean every field must be equally open. Available in Professional and higher editions, field-level permissions can hide a field or make it read-only by profile. The setting is not layout-specific and applies across every layout in the module. In the layout editor, use the field’s settings icon and select Set Permission to define access.

Up to thirty personal fields per module can be marked Normal or Sensitive. Auto Number, Formula, User, Lookup, First Name, and Last Name cannot be marked; the framework covers Leads, Contacts, Vendors, and custom modules. HIPAA settings allow up to ten modules and twenty-five fields per module, with four transfer restrictions, and covered organizations must separately sign a BAA. These are product settings; the organization’s legal team determines their legal significance.

Restrict exports through two coordinated layers

A Normal or Sensitive marking restricts movement through exports, API access, transfers to Zoho applications, and third-party transfers. HIPAA settings likewise provide separate controls for API access, exports, application transfers, and third-party transfers. Disabling compliance removes the associated markings. Field selection and transfer restrictions therefore need to be reviewed together, rather than treating a general ability to reach the record as the final decision.

A report is not an additional privacy wall. Users see records available in its primary module, but fields from parent or child modules added to the report may be visible even when those related records are not. Reports are shared at folder level, and administrator profiles see every report. Dashboard field permissions remain effective, but embedded dashboards rely only on allowed domains because CRM permissions no longer operate there.

What the audit log can and cannot show

The Zoho CRM audit log does not record who merely viewed a particular record. It captures additions, updates, deletions, mass updates and deletions, imports and exports, conversions, recycle-bin deletion and restoration, and duplicate-record merges. On the Setup side, it records creation, editing, and deletion involving items such as templates, workflows, webhooks, web forms, roles, profiles, and reports.

The log is available through Setup, Security Control, and Audit Log and can be exported as CSV. Access depends on role hierarchy rather than profile permission. The log is retained for sixty days by default, so longer preservation depends on exporting it.

What breaks when access is narrowed

When a record disappears after access is narrowed, ownership is usually the starting point. A record owned by another consultant needs a sharing rule or user field. The hierarchy position of a dedicated user account determines visibility for records held there. When an employee leaves, ownership passes to a new responsible user. The design does not create ownerless pooled records.

Edition boundaries clarify the design. Field-level permissions require Professional or higher, while CEO and Manager roles come predefined in paid accounts. User fields are edition-independent, while the documentation states no edition threshold for the audit log, so verify that in the target account. No edition threshold is stated for sharing rules or record-level sharing, so check Manage Data Sharing permission. The compliance-setting edition remains unknown and must be verified in Setup, not guessed. A final review should identify one owner and an explicit access route for every record.

Zoho CRM for clinics