Clinical data visibility is not a single choice between showing everyone the same screen and hiding everything. Doctors, consultants, call teams, and accounting staff approach one patient record for different duties. A sound permission structure in Zoho CRM treats those duties through separate layers: teamspace membership, record sharing, roles, profiles, and field-level visibility. Each layer answers a different access question.
The order of those layers matters. In Zoho, the first decision is whether a user can enter the relevant workspace. The next decisions cover which records they can see and what they can do there. Specific fields are separated afterward. Giving access to a doctor who does not own the record is another decision, handled through a user field rather than the role structure.
Four teams open one patient record for different reasons
A doctor may open the patient record to understand treatment history, a consultant to continue a conversation and proposal, the call team to confirm an appointment, and accounting to track collection. These needs meet on one screen but are not equivalent. The question is not merely whether the record opens. It also concerns which information appears and which actions are available.
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 to confirm the following day's appointments. The situation shows how a list requirement can be confused with data access. Visibility, action permissions, and information separation need distinct decisions.
Visibility decisions begin with the teamspace
In Zoho CRM, teamspace membership is the first control. A user cannot access a module there without joining the relevant teamspace. Org modules hold information needed by several teams, while team modules hold information for one team. A team module's dedicated profile determines visibility and actions. The same user can have different team module profiles across different modules.
The default sharing setting for org modules is Private. The setup review should therefore determine whether someone previously widened that setting, rather than assuming an open default. The four levels are Private, Public Read Only, Public Read/Write, and Public Read/Write/Delete. Public Read/Write and the level above it override role hierarchy and sharing rules. Sharing rules can extend access, but cannot narrow it.
Roles determine visibility, while profiles determine actions
A role determines which records a user can reach; a profile determines what the user may do with those records. Each user has one role. Two consultants at the same role level do not see each other's records by default. Share Data with Peers enables that relationship. Superiors Allowed is required when a higher role must see data granted to a subordinate through a specific sharing rule.
A higher position in the hierarchy does not provide access when the profile lacks permission to view the module. Profile permissions are grouped under Module Permissions, Setup Permissions, Extension Permissions, and Developer Permissions. Module controls separately cover viewing, creating, editing, deleting, importing, exporting, sending email, Mass Update, Mass Delete, and Change Owner. Notes and Attachments also have their own permissions.
Doctor access belongs in a user field
When a consultant owns the patient record, a doctor who neither owns it nor sits above that consultant in the role hierarchy does not gain access through hierarchy alone. The documented method in Zoho CRM is to add a user field that identifies the doctor. Its setup assigns read-only, read-and-write, or full record access. The doctor's own profile permissions still limit available actions.
This is not a lookup field. A lookup points to a record in another module; it does not select a user, role, or group. There is no separate field type for choosing a role or group. A module can contain five single-user fields and one multi-user field, with up to ten users in the latter. Tasks, Calls, and Meetings do not support user fields.
A call list is a view, not a permission boundary
The call team's need for a list of today's or tomorrow's confirmations does not mean that the list limits record access. Record visibility comes from the Private starting point, the role structure, and sharing decisions. Once the team reaches a record, profile permissions limit available actions. Exporting and bulk-operation tools are also handled as independent permissions within the profile rather than by the list itself.
A report does not replace these security layers. Users can see in a report the records they can access in the primary module. When fields from parent or child modules are added, those fields can appear even if users cannot directly access the related records. Sharing operates at report-folder level, with options for everyone, the owner, or selected users and roles. Administrator profiles see every report.
Accounting separation happens at field level
An accounting employee requested access to the patient list for collection tracking. Opening the record also revealed the treatment plan, doctor's note, and intraoral photographs because they all sat beneath the same record. Allowing accounting to see the patient without seeing treatment notes cannot be solved with record access alone. The design must first decide where the required collection fields belong.
Field permissions are defined by profile in Professional and higher editions. They are not layout-specific and apply across every layout in the module. Management and accounting therefore need separate profiles. Standard does not offer this field separation; it allows changes to a field to be followed through record history. That history does not separate visibility. The collection fields' module should be decided before configuration.
X-rays, photographs, and notes do not form another field list
Attachments such as X-rays and intraoral photographs are not fields. Attachments, notes, and competitor records inherit access from the primary record to which they belong. A user who cannot see the patient record cannot see its attachment either. This differs from field-level permissions. Choosing which record should hold a sensitive document is therefore an access-design decision made during configuration.
Seeing the record does not automatically permit every action on its related content. Profiles define separate viewing, creating, editing, and deleting permissions for Notes and Attachments. A user needs at least read access to add a note or attachment to a record, or to send email from it. The information inside an attachment, however, cannot be divided through field-level visibility controls.
Roles or territories for branch separation
Under role hierarchy, a record is available to its owner, the owner's superiors, and people granted access through sharing rules; one user can hold only one role. Territory hierarchy additionally opens it to other users in the record's territory and users in higher territories. A user can join several territories and carry a separate forecast target for each. Record ownership remains with one person in both structures.
Field-level permissions, meaning hiding a field from a profile or making it read only, are available from Professional upward. Standard can track field changes in record history, but cannot separate field visibility. Territory Management requires Enterprise or higher and works with Leads, Contacts, Accounts, and Deals. Zoho provides the CEO and Manager roles in paid accounts, while total role capacity depends on edition. Unstated thresholds and compliance availability should be confirmed in Setup.
What the permission structure cannot measure
The audit log does not show who viewed a particular record. On records, it follows changes such as additions, updates, deletions, bulk operations, imports, exports, conversions, and merges. In Setup, it follows changes to items such as workflows, roles, profiles, and reports. Personal fields have Normal and Sensitive classifications. Up to thirty fields per module can be marked, but first and last names cannot qualify.
This compliance layer applies to Leads, Contacts, Vendors, and custom modules, not Deals, Accounts, or team modules. Auto-number, formula, user, and lookup fields are also ineligible. Marking restricts data movement through exports, API access, transfers to Zoho applications, and third parties. These are technical effects. Whether the resulting structure satisfies regulatory obligations is a separate legal assessment for the organization's legal team.
