Role permissions explained
A complete reference of every granular role, which staff persona it fits, and the special enforcement rules.
- Updated
- Updated
- Reading time
- 8 min read
- Tags
- rolespermissionsreference
EnWella uses three base membership types (provider, staff, patient) with thirteen additive role flags layered on top. The design principle is **least possible access to perform business function** — the persona presets in the invite flow are starting points, not handcuffs. This article walks every flag, who has it by default, and the rules that no checkbox can override.
The defaults at a glance
Every persona in the invite flow ticks a different subset of these checkboxes — the matrix above is the unmodified default. After invite you can grant or revoke any individual flag; nothing here is permanent. The gold-ringed cell is the single permission that cannot be granted to a non-provider, no matter what — see the signing section below.
`view_all_patients` — read-only chart access
Lets the user open any patient chart at this establishment in read-only mode: demographics, history, notes, vitals, documents. It is the floor for almost every other role — without it, a teammate who can "managedocuments" cannot actually see whose documents they are managing. Patients are scoped per medicalestablishment_id, so granting it never leaks data to another clinic in the same EnWella account.
`create_notes` — draft clinical notes
Lets the user start, edit, and save a draft note from any visit template. The note stays a draft (locked from release, hidden from the patient) until someone with the right signing permission signs it. Off by default for non-clinical staff and for medical assistants — opt-in for scribes and nurses who legitimately compose notes for a provider to sign.
`sign_notes` — primary signature (provider-only enforcement)
Visit note · 2026-04-21
Maria Lopez - follow-up
Draft note · 2026-04-21
Maria Lopez - follow-up
A nurse can be added as co-signer on a template that requires one - the primary signature must still come from a provider
This is the one role that lies. Even if the checkbox is ticked, the application enforces that the primary signature on a clinical note can only come from a DoctorMembership — granting sign_notes to a nurse is silently a no-op, because the gate downstream checks provider? not the role flag. Co-signing is more permissive (provider OR clinical staff) and is configured per template; that is the right hook for a nurse who needs to attest, a supervisor who needs to review, or a trainee model where every visit needs a co-sign.
`edit_clinical_data` — allergies, flags, diagnoses, problem list
Lets the user mutate the structured clinical sections of a chart: allergies, problem list, diagnoses, medication list, alerts/flags. Anyone with this can update a patient's allergy from "penicillin" to "none" — which is exactly why front desk and billing do not have it. Medical assistants, scribes, nurses and providers all do.
`manage_calendar` — create and edit appointments
Lets the user create, reschedule, and cancel calendar events for any provider at this establishment. Without it, a user can only see the calendar (if they have viewallpatients) — they cannot move a slot or book a new visit. Granted to nearly every persona except the billing coordinator, who has no reason to touch the schedule.
`add_new_patients` — register new records
Lets the user create a new patient record (and trigger an invite to the patient portal). Distinct from viewallpatients because it is the operation that creates the patient in the first place — front desk and patient coordinators need it; scribes and billing coordinators do not.
`manage_documents` — uploads, intake, consents
Covers uploading and deleting documents in a chart, sending intake form packets, and managing consent forms. Required for anyone running the front-desk intake flow. Note that this does not include editing a patient's clinical data — uploading a lab report PDF is a managedocuments action; transcribing the lab values into the structured Vitals section is editclinical_data.
`manage_messaging` — secure patient messages
Lets the user read and send messages in the secure patient inbox. Granted by default to providers, nurses, and patient coordinators (and to the practice manager for replying to reviews on the public site). Front desk does not have it — patient messages are PHI, and a handoff to messaging is not a substitute for a phone call.
`manage_surveys` — assign and score screeners
Lets the user assign validated screeners (PHQ-9, GAD-7, AUDIT, custom panels), enter manually-collected scores, and request that a patient retake a survey. Required for anyone running measurement-based care; opt-out for personas that never touch screeners (billing coordinator).
`manage_billing` — day-to-day billing operations
Covers the operational billing surface: invoices, claims, payments, refunds, cards on file, and adjustments. This is the role for a billing coordinator who runs the daily denials queue. It does not include billing settings — fee schedules, custom CPT codes, payer enrollment, and clearinghouse credentials live behind a separate role so a coordinator cannot accidentally re-map a service code.
`manage_team` — invite, deactivate, edit roles
Lets the user invite new teammates, deactivate existing ones, and adjust role checkboxes on anyone in this establishment. Implies the user becomes responsible for the audit trail of every grant they make — every checkbox change is logged with their name and timestamp.
`manage_practice_settings` — clinic, locations, templates
Covers the practice-shaped surfaces: practice details, locations, room layouts, visit templates, note templates, intake form library, public website builder, email/Gmail integration, and outreach campaigns. A practice manager has it; nobody else does by default.
`manage_billing_settings` — fee schedules, codes, payments setup
Covers the billing-shaped configuration: billing templates, custom CPT/HCPCS codes, fee schedules, payer enrollment, the Stripe payments connection, and clearinghouse credentials. Granted to the billing coordinator and practice manager; deliberately separate from manage_billing so a temp covering the daily denials queue cannot reshape your fee schedule.
The two overlays: `admin` and `super_admin`
On top of the thirteen role flags, a membership can carry one of two boolean overlays. admin is the practice-manager bit — Pundit treats it as superadmin? OR :admin, which gates a small set of administrative routes (the team page, the settings hub). superadmin is a developer/account-owner kill switch: fullaccess? is true, every Pundit policy returns true, and there is no establishment scoping. Grant superadmin only to the founder or to a trusted operator with full incident-response responsibility — there is no meaningful audit difference between a super_admin action and a database write.
The persona presets in the invite flow
When you invite a teammate, picking a persona pre-checks the role flags from the matrix above. The presets are: Provider (DoctorMembership; nine clinical roles), Medical Assistant (clinical staff; rooming + intake; no notes), Medical Scribe (clinical staff; draft notes + clinical data; no patient mgmt), Nurse (clinical staff; full clinical support; can co-sign but not primary-sign), Front Desk (non-clinical; scheduling + check-in + intake; no clinical or billing), Billing Coordinator (non-clinical; billing + billing settings only), Practice Manager (non-clinical + admin overlay; full ops oversight, no clinical signing), Patient Coordinator (non-clinical; intake + outreach + messaging). Pick the closest persona, then tune individual checkboxes.
Everything is scoped per establishment
Every role above grants access only inside the current establishment. A provider with viewallpatients at Clinic A cannot see Clinic B patients even if they are also a member there — the establishment context lives on the membership, and Pundit scopes every query against currentmembership.medicalestablishment_id. Multi-establishment users see a clinic switcher in the header; the role checkboxes you tick on each membership are independent.
Frequently asked questions
Why does ticking `sign_notes` for a nurse not actually let them sign?
provider? (DoctorMembership); the role flag exists so the same checkbox UI works for everyone, but the policy will reject the signature. If you want a nurse to attest, configure the template to require a co-sign — that path checks provider? OR clinical_staff? and works as expected.What is the difference between `admin` and `manage_team`?
manageteam lets the user invite, deactivate, and edit role flags on teammates — the day-to-day. admin (the overlay) gates a small set of administrative routes that wrap that work: the team page itself, the settings hub. A practice manager has both; you can grant manageteam without admin if you want someone to be able to edit roles on a user record they already opened, without exposing the whole team page.Can I create a new role flag?
MembershipRoleType on the Rails side); adding one is a schema change and a Pundit-policy change, and would need to ship in a release. If a persona at your practice does not fit any preset cleanly, the right move is to invite them with the closest preset and tune the checkboxes — no two practices use the matrix the same way.How do I see who granted a role to whom?
Membership → Permission, with the actor, the affected user, the flag, and the timestamp. Filter the audit log by event tone Permission to scope to grants and revocations.A teammate left. What is the right way to revoke access?
manage_team). Deactivation revokes all role flags atomically, ends the active session, and preserves the audit history under their name. Do not just untick every flag — that leaves the membership active and lets them log back in.Keep reading
Invite your team and assign roles
How to invite providers and staff, what each role can do, and how to grant time-limited access.
Audit log and access reviews
What is logged, where to read it, and how to run a quarterly access review.
Why is this button disabled? Understanding permissions
How EnWella decides what each person on your team can do, why a button might be greyed out, and the steps to unlock it.