Roles & Permissions

Every organisation on Eirly controls what its members can see and do through roles. A role is a named bundle of capabilities — individual permissions like View results or Manage API keys — that you assign to members.

Your organisation starts with a set of ready-made roles that cover most teams. If they don’t fit, you can build your own — and for Medicare ordering, you always will (see below).

Where to find this

Members — invite people, and set which roles each member holds. Settings → Roles — view the built-in roles, and create or edit your own.

Both are only visible to members whose own role permits it.

How permissions are decided

Three rules govern every permission check. Understanding them explains almost every “why can/can’t they do that?” question.

flowchart TD
    A["Member attempts an action"] --> B{"Holds the Owner role?"}
    B -- "Yes" --> C["Allowed — always"]
    B -- "No" --> D["Start from the Member floor:<br/>no capabilities"]
    D --> E["Add every capability from<br/>every role the member holds"]
    E --> F{"Is this action's capability<br/>in that combined set?"}
    F -- "Yes" --> G["Allowed"]
    F -- "No" --> H["Not allowed"]

Note what isn’t there: any step that takes access away. A capability is either added by one of the member’s roles or it never arrives.

1. A member can hold more than one role

Roles are additive. If someone holds both Support and Read-only, they get everything in either role — the union, never the smaller of the two. This is how you compose access without creating a new role for every combination: give a support person the Support role plus a role that permits Medicare ordering, and they can do both jobs.

There is no “deny” — a capability is either granted by one of the member’s roles, or it isn’t granted at all.

2. Owners bypass everything

A member holding the Owner role has full access to the organisation, always. Owner isn’t a long list of ticked capabilities — it’s a rule that short-circuits every check. Adding a new feature to Eirly never requires you to re-grant it to your owners.

Because of this, Owner cannot be edited or deleted.

3. The base Member role grants nothing on its own

Everyone in the organisation implicitly holds Member. It exists as the floor that every member stands on — it is not a starter set of permissions, and it grants no capabilities by itself. A person who holds only Member can sign in and belongs to the organisation, but can’t reach its features.

That’s deliberate: access is something you grant, not something you take away. Member also can’t be assigned or removed by hand, for the same reason.

The built-in roles

Every organisation is created with these. All except Owner and Member can be edited, so treat them as sensible starting points rather than fixed definitions.

Role	Intended for	Access
Owner	The people ultimately responsible for the organisation	Everything, always. System role — cannot be edited or deleted.
Admin	Day-to-day administrators	Everything except placing Medicare orders (see below). Editable.
Support	Staff handling clients and their referrals	View and download referrals and results, view clients, re-send verification links. No billing, API or settings. Editable.
Read-only	Auditors, observers, read-only integrations staff	View referrals, results and clients. Nothing else. Editable.
Member	—	The implicit floor described above. System role — cannot be assigned, edited or deleted.

Why Admin can’t place Medicare orders

Ordering under Medicare is tied to an individual doctor’s provider number and signature — it’s a personal, professional act, not an administrative one. Your practice manager almost certainly administers the Medicare settings without being the ordering doctor, so Admin deliberately excludes it.

Admins still manage the Medicare surface: the practice address, and every practitioner’s provider details. What they can’t do is order under a provider number, or apply someone else’s signature.

Medicare ordering is opt-in: no built-in role grants it. To let a doctor order, create a role with the Order with Medicare provider number capability and assign it to them — on its own, or alongside another role. See Letting a doctor order under Medicare below, and Medicare Ordering.

Building your own roles

If none of the built-in roles fit, create one: Settings → Roles → New role. Give it a name and tick the capabilities it should include. Custom roles are private to your organisation.

A few things worth knowing:

• Editing a role takes effect immediately for every member who holds it. There’s no re-assignment step.
• Custom roles don’t gain new capabilities automatically. When Eirly adds a capability, existing custom roles are untouched — we never silently widen access you defined. Tick it yourself if you want it.
• Deleting a role doesn’t remove the people in it. They stay in the organisation and fall back to the base Member floor, which grants nothing. Give them another role, or they’ll lose access to your organisation’s features.
• You can’t change your own roles. This stops an owner accidentally removing their own access and locking the organisation out. Ask another owner.

Letting a doctor order under Medicare

Ordering under Medicare is deliberately opt-in — it is the one capability no built-in role grants, not even Admin. You decide explicitly which of your practitioners may order under their own provider number, rather than it arriving with an administrative role.

To grant it:

1. Go to Settings → Roles → New role.
2. Name it something your team will recognise — Medicare Ordering Practitioner or Ordering Doctor works well.
3. Tick Order with Medicare provider number (under the Medicare group). That single capability is all the role needs.
4. Save, then assign it to the doctor from the members list — on its own, or alongside their existing role.

That capability lets them set up their own provider record and signature and place Medicare orders. It does not give them any administrative access, and it never lets them apply another practitioner’s signature.

What you can grant

Capabilities are grouped the way the product is. This is the full catalogue — the same list you see as checkboxes in the role editor.

Group	Capabilities
Referrals	View referrals · Download referral · Resend verification · Edit referral details
Ordering	Order referral · Buy referral · View test bundles · Manage test bundles
Results	View results list · View result detail · Download result · Approve results
Clients	View clients · Edit clients · Disable / delete clients
Members & roles	View members · Invite members · Remove members · Assign roles · Manage role definitions
Billing	View billing · Manage cards
Payouts	View payouts
API & webhooks	View API & webhooks · Manage API keys · Manage webhooks
Optimal ranges	View optimal ranges · Manage optimal ranges
Stores	View stores · Manage stores
Organisation settings	View organisation settings · Manage organisation settings
Medicare	Order with Medicare provider number · Manage Medicare settings & practitioners · View Medicare practitioners
Chat	Use practitioner chat

View and manage are separate on purpose

Most areas split into a view capability and a manage capability. Granting View billing without Manage cards lets a bookkeeper read invoices without touching payment methods. The same pattern applies to API keys, webhooks, stores, optimal ranges, test bundles and organisation settings.

Inviting people with the right access

When you invite someone (Members → Invite), you choose the roles they’ll hold when they accept. The invitation carries those roles with it, so there’s no second step after they join — they sign in with exactly the access you intended.

You can change a member’s roles at any time afterwards from the members list. Changes apply on their next request; there’s no need for them to sign out.

How this affects the API

Roles govern people, not integrations.

API credentials authenticate as your organisation, not as a member of it, so an API key isn’t limited by any member’s roles. Removing someone’s Manage API keys capability stops them creating new keys in the portal — it does not restrict what an existing key can already do.

Treat API keys as organisation-level access, and rotate them when the people who held them leave. See Authentication.

---

Questions about setting up roles for your team? Reach out at support@eirly.health.