Understand how access and permissions work
Understand organization roles, Spaces and Operations access, resource permissions and project-creation authority in Node Cluster.
There is no single “team permission” that answers every access question. Start with the action a person needs to perform and the resource it affects.
The controls you will encounter
| Control | Question it answers | What it does not establish |
|---|---|---|
| Organization membership and role | Does this account belong here, and what is its role ceiling? | Which specific project a Member should use. |
| Spaces / Operations access | Which working areas can this person enter? | Permission for every resource or administrative action in that area. |
| Space access | Can this person use work through the department’s access context? | Authority to create new departmental projects. |
| Project access | What access applies to this specific project? | An organization-wide Admin role. |
| Project creation governance | In which departments may this person create or publish projects? | Access to existing departmental work. |
| Task assignment policy | Which permitted task edits and assignments may a project writer make? | Basic access to a project they cannot otherwise open. |
| Operations scopes | Which scoped operational capabilities are allowed? | Bypassing the organization role or feature availability. |
Organization roles and resource roles are different
Owner, Admin, Member, and Viewer are organization roles. Viewer, Editor, and Manager can also describe access to a specific resource. Always ask which kind of role you are looking at.
Owners and Admins have broad organization access and bypass controls that can restrict ordinary Members. Do not use an Admin account to test whether a restricted colleague can open a project. Organization Viewers remain read-only; giving them a higher project role does not turn them into contributors.
A resource Manager can manage supported sharing and policy controls for that resource. That is not permission to administer the whole organization. Editors and Managers still act within the resource and organization rules applicable to them.
Access may come from more than one place
A person can have access through a Space, a direct project grant, resource ownership, or other supported visibility rules. Removing one source does not necessarily remove all effective access. Explicit project overrides and Space blocks can also change the result.
Use the effective level shown for the actual resource in Team → Inventory when investigating access. Treat explanatory source labels as context for that result, not as a replacement for it. Space access and project access must be inspected separately.
Creation is independent
A Member whose primary department is Sales can be authorized to create a new Sales project without seeing every existing Sales project. Another Member may edit a shared Sales project without being allowed to create there. Both situations are valid.
Use the narrowest relevant control
For a new project destination, review creation governance. For a missing project, review resource access. For disabled reassignment, review task policy and project write access. For missing integration controls, review Operations, organization role, scopes, and enabled features.
Copying a URL, assigning a task, selecting a department, or adding a project to an overview should never be used as a substitute for checking access.
Owner-only controls still exist
Owner and Admin are both privileged roles, but not every administrative control is identical. Workspace renaming is Owner-only in the reviewed interface. An Admin’s member-role selector offers Member and Viewer, while an Owner can choose privileged roles. Use the specific setup guide for the action instead of reading broad access as permission to perform every Owner action.