Roles and Access Matrix

This reference translates code-level roles and menu rules into operational language. It is not a full field-level permission document. Its goal is to help teams quickly interpret menu access.

Base Roles

Role values in code:

• super_admin
• admin
• vet
• manager
• receptionist
• staff

Display names may appear as:

• Super Admin
• Hospital Admin
• Veterinarian
• Manager
• Receptionist
• Staff

Menu Access Rules

Admin menus

The code-level ADMIN_MENU is primarily exposed to:

• super_admin
• admin

In general, vet, manager, receptionist, and staff are not the default audience for /admin.

At the same time, an account with isPrimary can behave more broadly in some edge admin or clinical boundary actions. Menu visibility and true action authority should not be treated as identical.

Clinical and retail menus

The broader CLINICAL_MENU and RETAIL_MENU are exposed to all core roles:

• super_admin
• admin
• vet
• manager
• receptionist
• staff

That does not mean every role should perform every action on those screens. Actual use still depends on operational policy and backend guards.

How to Read the New Operational Sections

CLINICAL_MENU

This broadly includes:

• registration and appointments
• OPD and IPD
• laboratory, PACS, and pharmacy
• hotel, grooming, and pet taxi

Service-booking screens are therefore not purely admin screens.

RETAIL_MENU

This broadly includes:

• POS Shop
• Receipt
• retail and settlement screens

POS and Receipt may be broadly visible while still having narrower rules for actions like void or chart-to-POS transfer.

Practical Matrix

How to read the table

• Yes: normal working audience
• Limited: visibility may exist, but not all actions are expected or allowed
• When needed: role can participate depending on hospital policy

Additional Constraints

Audit Log

Audit log belongs operationally to admin work.

Grooming and Pet Taxi enablement

Even when the role is correct, Grooming and Pet Taxi depend on branch feature flags such as isGroomingEnabled and isTaxiEnabled.

Real POS action differences

Not every POS-related action uses the same permission rule.

• sending a chart to POS: narrower, typically clinician or admin context
• void actions from thread or receipt context: may include front-office roles

Multi-branch

When the hospital uses a multi-branch plan, branch-specific scope matters in addition to role labels.

Recommended Operating Rules

• do not reinterpret role names informally
• keep admin rights limited to a small number of users
• when one person has both admin and clinical responsibilities, define which account context they use for which task
• for service-screen access issues, review role, branch feature enablement, and actual backend action authority together

Related Docs

• Manage Staff, Roles, and Branch Operations
• Use Audit Logs
• Use the Shared Service Booking Flow
• Manage POS Sales and Payment