Invite a colleague and set up their working access

Invite a colleague to Node Cluster, configure their working access and verify that a normal Member can reach the right Space and project.

An invitation adds a person to your company’s onboarding process. Their organization role, available areas, work access, and project-creation authority still need to match their job.

Invite the colleague

  1. Open Team in the intended organization.
  2. Choose Invite and enter the colleague’s work email.
  3. Choose an organization role. Use Member for someone who contributes work and Viewer for someone whose role should remain read-only. Use Admin only when broad administration is needed.
  4. Select Spaces and, if required, Operations in the invitation’s access choices.
  5. Send the invitation and check the pending invitation entry.

Ask the colleague to accept with the invited account. If they cannot find their company work, first confirm which organization and account they are using.

Configure their work after they join

Open the member record. For someone who works across a whole department, configure the appropriate Space access. For a collaborator who needs only one delivery, share the specific project and check its effective access instead of assuming they need the entire department.

Then open Project creation governance. Set the primary department if the person is a Member who should create work there. Add exceptions for additional departments only when needed. This step does not share existing work.

If the person needs Operations, configure the relevant scopes separately. A project Manager is not automatically an organization administrator, and Operations access alone does not enable every administrative action.

Test the actual job

Ask the colleague to open their project and All Tasks. Have a contributor make an allowed update. Have a Viewer confirm they can read the intended work without editing it. If the colleague is meant to create projects, check that an authorized destination is available.

Use Team’s Inventory to inspect the exact Space and project when the outcome is unexpected. A Space membership count is not a complete list of accessible projects, because individual projects may also be shared directly.

Review later changes

When someone changes departments, review both creation governance and existing access. Changing the primary department does not clean up old project grants. Review Operations scopes and shared overviews as well. When removing access, confirm the effective result rather than relying on a single removed membership entry.

Maintain pending invitations

Open the pending invitation to review its recipient and expiry. Use Resend when the intended recipient needs the email again, Copy link when you need the existing link, or Revoke when the invitation should no longer be accepted. Revoke is not the action for removing someone who already joined.

When changing an existing member’s organization role, recheck scoped permissions afterward: the role-change flow resets them to the new role’s defaults. For a department transfer or departure, follow the member-lifecycle guide so work ownership, project grants, and external service responsibilities are reviewed together.