Short answer: define reception access around the administrative work staff need to perform, then prove that unnecessary information remains inaccessible. Keep appointment logistics, contact details and billing responsibilities distinct from clinical records. Odoo permissions need deliberate design and review; a convenient screen layout does not establish a safe information boundary.
Applies to
Odoo 19 administrative workflows for healthcare, dental and veterinary organisations. This is system design guidance, not clinical or legal advice. The corresponding Odoo 20 documentation was checked in October 2026. This article targets Odoo 19; confirm your installed version before following any screen labels.
Which tasks does reception actually perform?
List the tasks before choosing access groups. Reception may confirm contact details, coordinate appointments, answer administrative questions or direct billing enquiries. The required information differs from what a practitioner, finance user or system administrator needs.
I would ask for representative situations: a new enquiry, a changed appointment, a billing question and a request involving another location. Identify the minimum information needed for each situation. Avoid adding sensitive background notes simply because a shared contact form makes it easy.
For dental and veterinary organisations, distinguish the administrative customer or owner relationship from specialist records. A pet owner’s billing contact and an animal’s clinical history answer different needs. Likewise, a dental appointment reminder does not require treatment details in a general communication field.
How should roles be designed?
Create a responsibility matrix with actions such as read, create, update, export and administer. Include the record scope, not only the application name. A person may need to update a contact’s phone number without seeing every record across all locations.
Odoo 19 uses access rights and record rules as security mechanisms. Access rights granted through groups are additive, so another group can broaden a user’s permissions. Record rules introduce their own combination behaviour. Have an experienced implementer review the complete role rather than assuming one restrictive setting overrides everything else.
Keep administration separate from ordinary reception work. A broad administrator account can make a workflow appear successful while bypassing the intended limits. Use representative ordinary accounts when assessing what staff can actually see and change.
What information should stay out of shared fields?
General notes, messages and attachments can be visible through more workflows than the person entering them expects. Define what belongs in those areas and what must remain in the separately assessed clinical system. Include examples in training so that the policy is practical.
Review document titles and notification content as well as full records. A short preview or attachment name can reveal information even when users do not open the underlying document. The same principle applies to exports and externally delivered messages.
Do not claim that a configuration is compliant merely because access groups have been assigned. The organisation’s obligations, retention decisions and specialist systems need their own review. The ERP implementation should follow the resulting requirements and preserve evidence of how they were applied.
Worked example: reception supports two locations
Imagine a clinic organisation where a central reception team coordinates appointments for two locations. Local staff handle attendance and billing queries, while clinical documentation remains in a separate specialist system. The initial Odoo role gives reception broader access than the agreed administrative scope.
The team lists the necessary contact, scheduling and billing actions and reviews the record boundaries. It removes unnecessary data from shared notes and defines how staff request help when a query requires another role. The design is then assessed using ordinary user accounts.
Reviewers try both allowed work and prohibited access paths, including search, exports and attachments. Findings become specific configuration or process changes. The result is an administrative workflow with documented limits, not a claim that the ERP has replaced the clinical system.
Which access paths need review?
Check forms, list views, searches, reports, exports and relevant integrations. If the implementation uses a portal or custom module, include those paths. A menu hidden from a role is not sufficient evidence that the underlying records cannot be reached another way.
Review cross location and company behaviour where applicable. Shared contacts may be intentional, while transaction or attachment access requires a narrower boundary. Confirm the actual result rather than assuming the company selector alone establishes every restriction.
Odoo 20 changes the documented role model and technical security guidance. This article is specifically about Odoo 19 principles. A later version upgrade should include a fresh permission review instead of carrying forward an old screenshot checklist unchanged.
How should access be maintained after launch?
Assign an owner for new users, role changes and departures. Review temporary access and supplier accounts periodically. Keep the reason for unusual permissions so that later administrators can decide whether the exception still has a purpose.
Train staff on the escalation path for requests outside their role. If the only practical way to resolve an ordinary enquiry is borrowing an administrator login, the process needs correction. Security boundaries are more sustainable when the operating workflow supports them.
Common mistakes include copying a manager’s access for convenience, placing sensitive information in general notes and reviewing only the happy path. Another is collecting more data than reception needs because the form contains an available field.
Close the design with an approved responsibility matrix, representative access evidence and named maintenance owners. Revisit it when workflows, locations or modules change. The objective is a usable administrative process whose information boundaries can be explained and demonstrated.
Related
Read implementation handover for ongoing access ownership.
Official references
How this article was checked: the official Odoo 19 references and their Odoo 20 counterparts were reviewed in October 2026. Examples are illustrative planning exercises, not client results or tests on a live database.
For help applying this to your business, see my portfolio.