What you'll achieve
You will review who belongs to the organisation, maintain role-based permissions, handle membership requests and diagnose why a member can or cannot open a governed page.
Who this is for
This guide is for an Organisation Administrator with the permission or assigned action described below. If the navigation or action is missing, check the selected organisation, effective account level, feature state and role before assuming the product is unavailable.
Before you start
Check that you have:
- An approved joiner, mover or leaver decision.
- The member's work email and intended account level.
- A clear role design that separates access, accountability and capability.
- A second reviewer for unusually broad or sensitive access.
1. Start with the member record
Open Settings > Organisation > Membership > Members. Confirm the selected organisation, the person's identity, membership status and account level before changing a role.
2. Review requests before creating duplicate access
Open Requests and decide each pending request using your organisation's approval process. A join request is evidence of interest, not approval. Check whether an invitation or active membership already exists.
3. Use roles for repeatable access
Open Roles. Prefer a role whose purpose matches the work. Review its permissions, assigned users and required capability information before assigning it. Create a new role only when an existing role cannot express the decision cleanly.
4. Use audiences for communication scope
Open Audiences when you need a reusable group for policy or communication coverage. Audience membership is not a substitute for a role and does not silently grant platform permissions.
5. Run access troubleshooting
Open Troubleshooting, select the member and the target page, then run the diagnosis. Read the route requirements, effective feature state and permission sources. Fix the missing cause rather than adding broad access speculatively.
6. Recheck after every change
Ask the person to refresh or sign in again if needed, then confirm they can reach the intended task and cannot reach unrelated administration surfaces.
Check it worked
- The member is active at the intended account level.
- Their effective permissions come from the expected role or explicit approved grant.
- The access diagnosis passes for the intended page.
- The access decision is recorded outside the member table where your process requires it.
If something goes wrong
| What you see | What to do |
|---|---|
| The member is active but the page is hidden | Run Access troubleshooting and check feature state, permission and organisation context. |
| A role grants too much | Do not use it. Refine or create a narrower approved role. |
| A direct grant appears | Confirm why it exists. Direct grants bypass the reusable role catalogue and deserve extra review. |
| The person changed jobs | Apply the mover process: remove obsolete roles before adding new ones, then recheck access. |
Human judgement, security and privacy
Access is a governance decision, not an administrative convenience. Do not test by signing in as the member or asking for their password. Use effective-access evidence and confirmation from the member.
What's next
Review the member again after their first real task, then include their access in your normal joiner, mover and leaver review rhythm.
Need help?
Use your organisation's approved Backstory support route. Include the organisation, page and action that failed, but do not include passwords, invitation links, secret keys or unnecessary personal or confidential content.