In a lot of small dental clinics, everyone logs in with the same username and password, or with personal accounts that all happen to see everything. It's not usually a sign of distrust toward staff — it's just that nobody set up anything different, and it's never caused a visible problem. Until it does: a payment analysis report visible to someone who shouldn't see it, or a staff member who left the clinic still able to log in from home six months later because nobody thought to revoke it.
Three roles that map to how a clinic actually runs
- Admin — the owner or manager, with access to staff, finance, clinic setup and every branch
- Doctor — their own calendar, their patients' records and history, their own billing summary
- Receptionist — scheduling, patient records, billing and invoice generation at the front desk
A Receptionist doesn't need to see clinic-wide finance reports to do their job well — they need to generate a bill for the patient in front of them, not analyse the whole clinic's profitability. A Doctor doesn't need payroll access to treat a patient. Scoping access to what a role actually needs isn't a restriction for its own sake; it's what makes the system simpler and safer for everyone using it.
Permissions, beyond the three base roles
Real clinics have exceptions — a senior receptionist who should see billing reports, a doctor who also helps manage inventory. A well-built system lets an Admin grant or revoke specific permissions per person, on top of their base role, rather than forcing a choice between three fixed buckets that never quite fit everyone.
The part most software gets wrong: enforcement
Here's the detail that actually matters most, and the one that's easiest to overlook: permissions have to be checked on the server, for every request — not just used to decide what a menu shows on screen. A system that only hides a button from a Receptionist's view, but still answers the underlying request if called directly, isn't actually enforcing anything; it's just tidying up the interface. Done properly, the same check that decides what a Receptionist sees in the app also blocks the exact same data if requested any other way.
When a staff member leaves, deactivating their account should revoke access immediately and everywhere — not "by the end of the week" or "next time someone remembers." Their historical records (appointments, notes, billing) should stay intact; only their ability to log in should disappear.
Frequently asked questions
Can permissions be customised beyond Admin, Doctor and Receptionist?⌄
Yes — an Admin can grant specific individual permissions to a Doctor or Receptionist on top of their base role, for cases that don't fit neatly into one of the three.
Is hiding a menu item from a role enough to secure the data behind it?⌄
No — that only hides it from the interface. The underlying request needs to be blocked on the server itself, or a knowledgeable user could still reach the data by calling the system directly.
What happens to a staff member's past records when they're deactivated?⌄
Their historical appointments, clinical notes and billing stay intact and visible to those still authorised to see them — only the deactivated person's own ability to log in is removed.
Should every clinic bother with granular permissions, or are the three base roles enough?⌄
For most small, single-location clinics, the three base roles cover it. Granular permissions become useful once a clinic grows — more staff, more branches, more exceptions to the default.