Admin roles and permissions

Goal

Choose the narrowest role that lets a person complete their assigned work, then verify the choice with real tasks. BlockNinja has separate role layers for a local CMS, the managed account portal, and per-site SSO access.

Start with the task, not the title

Write down what the person must do, which site they need, and how long access is required. Job titles such as “manager” do not automatically justify a Manager account role or a CMS Superadmin role.

• List two tasks they must complete.
• List one privileged task they must not complete.
• Name the site or sites in scope.
• Set a review date for temporary access.

Recognise the three role layers

These layers are related but not interchangeable. Record which layer you are changing.

Use local CMS roles

Use account roles

An account Owner has the highest account responsibility and may have fixed access. A Manager can invite and manage team members. A Member can view the account dashboard. Account roles do not by themselves describe what the person can do inside every site.

Ownership changes affect the whole account. Use the approved ownership-transfer process and require independent confirmation.

Use per-site access

Choose No access, Admin, Editor, or Viewer separately for each site. Leave every unrelated site at No access. After acceptance, sign in through SSO and verify the actual CMS experience because managed access and local user labels are distinct concepts.

Apply least privilege

1. Start with the lowest plausible role.
2. Grant access only to the named site.
3. Have the person perform the required task.
4. Confirm the prohibited task remains unavailable.
5. Escalate only when evidence shows a required action is blocked.

Hazard: Never broaden an account role to solve a single-site access problem. Check per-site access first.

Separate routine and privileged work

Use an everyday account for normal editing and reserve privileged access for approved administrative work. Do not share accounts. A shared login prevents reliable audit and makes prompt removal difficult.

Verify a role change

1. Record the old layer and role.
2. Apply the approved change.
3. Ask the person to sign out and sign in through the intended route.
4. Replay the allowed task and the denied task.
5. Confirm unrelated sites remain unavailable.
6. Record the outcome, reviewer, and next review date without storing personal data in public notes.

Review access regularly

• Review Superadmin, Owner, and Manager access first.
• Remove access for people who no longer need the site.
• Reduce temporary elevated roles after the task.
• Check pending invitations and duplicate local/SSO identities.
• Review plugin-specific access as part of the same task test.

Recover from a role problem

• Required action is unavailable: verify the sign-in path and role layer before escalating.
• Unexpected privileged action is available: reduce access immediately, preserve the audit record, and notify the responsible administrator.
• Wrong site is visible: set that site's access to No access and re-test.
• Owner access cannot be edited: use the approved ownership process; do not create a second owner as a workaround.
• Role labels appear to conflict: describe the layer explicitly and verify tasks rather than translating labels by guesswork.

Access decision record

Keep raw identifiers, invitation tokens, and private member details out of user-facing notes and screenshots.

Completion check

The person can complete the assigned work, cannot complete the nominated privileged task, cannot reach unrelated sites, and a second administrator has confirmed the role layer and least-privilege decision.

Publication gate: keep this guide private until Viewer/Admin/Superadmin, Owner/Manager/Member, and No access/Admin/Editor/Viewer have each been independently replayed in the current runtime.