Permission examples for common team arrangements

See how to configure department members, collaborators, readers, and operators.

These examples show which controls to review together. Use the effective access result for your actual resources before treating the configuration as complete.

A departmental contributor

Need: Riley works in Customer Success, updates the department’s projects, and creates new onboarding projects.

Use organization Member with Spaces enabled. Configure Customer Success Space access for existing work. Set Customer Success as the primary department in Project creation governance. Check the project assignment policy so Riley can make the intended updates.

Check: Riley can open an existing onboarding project and has an authorized Customer Success creation destination. Setting only the primary department would not complete this setup.

A cross-department collaborator

Need: Sam works in Marketing but contributes to one Sales launch.

Keep Marketing as Sam’s primary department. Give Sam the intended role on the specific Sales project. Do not add a Sales creation exception unless Sam also needs to create new Sales projects.

Check: Sam can open and update that delivery as allowed. Access to that project does not imply permission to create other projects in Sales or read every Sales project.

A read-only reviewer

Need: Taylor reviews agreed work and should not edit it.

Use organization Viewer, enable the needed area, and configure access to the intended resources. Do not use an Editor project override as a way to make a Viewer contribute; the organization role remains a ceiling.

Check: Taylor can read the specified project and cannot edit task attributes. Do not promise access to Integrations, Audit, or Secrets just because another read-only setting is present; those areas have their own minimum-role requirements.

A company operator

Need: Casey maintains an integration and reviews operational resources.

Use a role that satisfies the feature’s minimum requirement, enable Operations, and configure the relevant scopes. Give Spaces access only if Casey also needs that working area. Some actions, including provider disconnect controls, can have stricter requirements than viewing the integration page.

Check: Casey can perform the required operation. A visible menu or a configured scope is not proof that every action is permitted.

A department transfer

Need: Morgan moves from Marketing to Customer Success.

Update the primary department and review creation exceptions. Separately review Marketing Space membership, direct project grants, blocks, saved overviews, and Operations scopes. Grant the new job’s access and withdraw old access where appropriate.

Check: Morgan can do the new job and retains only the intended old collaborations. Changing the department field alone does not revoke earlier grants.

A confusing Inventory result

Situation: Jordan has no effective access to a Space but can open a directly shared project within it.

Inspect both resource rosters. A Space-level result answers the question for that Space; the project can have another access source. Also check for explicit blocks and the organization role. Do not diagnose the issue from the primary-department field or aggregate membership count alone.