Invite your team and assign access

Goal

Invite one teammate through the correct access path, give them only the access they need, and confirm that the invitation and role are correct. This guide covers both a local CMS user and a managed BlockNinja account teammate.

Before you begin

• Use an Admin or Superadmin account for a local CMS invitation.
• Use an account Owner or Manager for an account-portal invitation.
• Confirm the recipient's approved work email and the site they should reach.
• Choose a fictional example address while practising. Never capture a real invitation address in documentation or support evidence.

Hazard: Sending an invitation is an external action. Review the email, role, and site before selecting Send Invite.

Choose the right invitation path

Do not invite the same person through both paths unless your access plan explicitly requires both identities.

Invite a local CMS user

1. In the CMS, open Users.
2. Select Invite User.
3. Enter the person's first name, last name, and approved email address.
4. Select Viewer, Admin, or Superadmin.
5. Read the invitation summary before sending.

Choose a local CMS role

Plugin permissions can add context to a role. Test the actual task after acceptance rather than assuming every screen behaves identically.

Invite through the account portal

1. Open the BlockNinja account portal and choose Team.
2. Select Invite Member.
3. Enter the approved email address.
4. Choose Manager when the person must invite or manage team members; otherwise choose Member for account-dashboard access.
5. Under Site access (optional), choose access only for the required site.
6. Review the choices, then send only when authorised.

Assign per-site access

For each site, the portal offers No access, Admin, Editor, or Viewer. Leave unrelated sites at No access. Account role and site access answer different questions: the account role controls account-dashboard responsibilities, while site access controls entry to a particular site.

After SSO, verify what the person can actually do in that CMS. Do not promise a local Viewer/Admin/Superadmin label unless the current managed-access policy has been independently checked.

Review before sending

• Email belongs to the intended person and organisation.
• Account role is no broader than required.
• Only the intended site has access.
• The site access level matches the assigned work.
• No screenshot, note, or support message exposes private members or sites.

Verify the invitation

1. Confirm the new entry shows the expected pending or invited state.
2. Ask the recipient to use the invitation once.
3. Have them sign in through the same path you intended.
4. Replay one allowed task and one task that should remain unavailable.
5. Record the reviewer, date, invitation path, and verified role without recording personal data.

Change or remove access

Open the relevant user or team-member record. Change the role or per-site access only after confirming the new responsibility. Remove access promptly when it is no longer needed. An account Owner's access may be fixed; transfer ownership through the approved account process rather than trying to weaken it from a site row.

Recover from a problem

• Wrong email: revoke or remove the pending invitation, then create a new one.
• Wrong role: correct it before the person starts work and repeat the access test.
• Invitation not received: confirm spelling and the pending state before resending.
• Person reaches the portal but not the site: check the site's per-site access rather than broadening the account role.
• Local and managed identities are confused: stop, identify which sign-in route is intended, and remove the unnecessary duplicate after review.

Completion check

The task is complete when the recipient can use the intended sign-in path, perform the allowed work, cannot reach unrelated sites or privileged actions, and an independent administrator has confirmed the least-privilege choice.

Publication gate: keep this guide private until a second reviewer has replayed both invitation paths with fictional data and verified the current role labels.