Skip to main content

Roles and permissions for your organisation

Your organisation can now control what each member can see and do, using a set of built-in roles or roles you build yourself.

Fine-grained access control​

Until now, membership was close to all-or-nothing. Organisations told us that didn't match how their teams actually work: a bookkeeper shouldn't need access to clinical results, and a support person shouldn't be able to rotate API keys.

Access is now governed by roles — named bundles of individual capabilities like View results, Manage API keys or Invite members.

What you get out of the box​

Every organisation now has these roles, ready to assign:

  • Owner — full access, always.
  • Admin — day-to-day administration.
  • Support — referrals, results and clients; no billing, API or settings.
  • Read-only — view referrals, results and clients, and nothing else.

All except Owner are editable, so they're starting points rather than constraints.

One capability is deliberately not in any of them: Order with Medicare provider number. Ordering under a doctor's own provider number is opt-in, so you grant it explicitly by creating a role with that capability and assigning it — rather than it arriving with an administrative role.

Build your own​

If none of them fit, create a role in Settings → Roles and tick exactly the capabilities it should have. Custom roles are private to your organisation, and editing one takes effect immediately for everyone who holds it.

Three things worth knowing​

  • Members can hold several roles at once, and the result is the union of them. Compose access instead of creating a role for every combination — a doctor can hold Support and a Medicare ordering role.
  • View and manage are separate capabilities almost everywhere. A bookkeeper can read invoices without being able to change payment methods.
  • Invitations carry roles. Choose the roles when you invite someone and they sign in with the right access immediately — no second step.

Nothing changed for your existing members​

Existing members keep the access they had. The new roles were added alongside what your organisation already had, and no one lost a permission in the transition. Owners remain owners.

For the full picture — including the complete capability catalogue and how the base Member role works — see Roles & Permissions.

Building an integration? Roles govern people, not API credentials — an API key authenticates as your organisation and isn't limited by any member's roles. See Authentication.

Questions? Reach out to our team at support@bloodygoodtests.com.au.