Roles & Permissions
Every organisation on BGT 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).
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.
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 BGT 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. |
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 BGT 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:
- Go to Settings → Roles → New role.
- Name it something your team will recognise — Medicare Ordering Practitioner or Ordering Doctor works well.
- Tick Order with Medicare provider number (under the Medicare group). That single capability is all the role needs.
- 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 |
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@bloodygoodtests.com.au.