For Organisation Administrators: licensed Collaborators with the relevant organisation-wide permissions.
What you will achieve
Explain why a particular member can or cannot open an access-controlled page, then identify the smallest appropriate next action.
The diagnostic evaluates frontend route rules. It is not impersonation, a server-authorisation test or proof that the member can open every record on the page.
Before you start
Ask for the affected organisation, page and intended task. Obtain the exact error and approximate time without requesting passwords, session cookies or invitation tokens.
Confirm the member is active in the intended organisation. Check their licence separately when the task requires licensed access. A Participant completing an assigned attestation does not need a broad Collaborator role merely to respond.
Run the diagnosis
- Open Settings > Organisation > Membership > Troubleshooting.
- Under Test access, choose the affected Member.
- Choose the relevant Page or area. The list contains pages with declared access requirements; it is not a list of every possible record URL.
- Select Run diagnosis and wait for the result. A loading or error state is not an access decision.
- Read the decision and trace. Distinguish a feature-disabled result, a permission-denied result and an allowed route.
- Review the listed role, direct-grant and effective-permission information. Several grants can overlap; one role name rarely tells the whole story.
Choose the next action
- For a feature-disabled result, use Review features. Check the organisation's operational settings and the feature's lifecycle before changing anything. Do not enable an unreleased capability to resolve an access ticket.
- For a permission result, use Review roles or Review member. Compare the required permission with the person's approved responsibilities.
- For an allowed result, ask the member to reproduce the task in their own session. Open page opens the page as you, not as the selected member.
If access is approved but a grant is missing, make the smallest authorised correction through membership or roles. Run the diagnosis again afterwards.
Check it worked
Record the selected organisation, member, page, diagnosis and any approved change. Have the member confirm the original action now works and that unrelated restricted actions remain restricted.
A successful page diagnosis followed by a record-level denial is useful evidence, not a reason to grant global access. Record ownership, organisation context and the server's action policy still matter.
If something goes wrong
| Problem | Next action |
|---|---|
| No members or routes are available | Check the selected organisation and wait for the data to load; preserve any loading error |
| The desired page is absent | Capture its route and the actual error for support; do not substitute an unrelated page |
| The diagnostic allows access but the task fails | Check the exact record/action and licence, then escalate with the error |
| Removing a role did not remove access | Inspect remaining roles and direct grants |
Human judgement matters
Troubleshooting is an explanation aid, not an approval to broaden access. Never ask the member to share their session or sign in as another person.
What next?
For the wider context, see Manage members, roles and access.
Keep the diagnosis with the access request. Review the underlying role if the same justified correction is repeatedly needed.
Get help
Contact your organisation's support route with this guide reference, the affected page and a sanitised error. Do not include passwords, keys or session details.