Configure Space access, project overrides, and blocks

Understand inherited access, explicit roles, and why removing a grant may not remove access.

Use Space access when a person should participate across a department. Use individual project access for a narrower collaboration. Check the resulting access for the exact resource after making changes.

Give access to departmental work

In Team, open the member record and confirm Spaces is enabled. In the Space access controls, use the selected-Spaces workflow when the person should work in particular departments. Add the intended Space to Spaces with access, then save or confirm changes as required by the interface.

The UI describes Space access as including current and future projects. Individual project overrides, blocks, and applicable resource rules still matter. Inspect sensitive projects individually instead of assuming that a department list fully describes their access.

The All Spaces mode must not be documented as automatically granting a Member access to every private resource. The current access summary distinguishes navigation mode from actual Space membership and other access sources. Confirm the effective result in Inventory.

Configure a project separately

Use the project’s sharing controls or the member’s Adjust Project access controls where available. The project picker offers inherited access, Viewer, Editor, Manager, and a block option.

ChoiceMeaning for the configuration
Inherit / no overrideRemove this explicit project override and allow the remaining access rules to apply.
ViewerConfigure a read-only project role, subject to the overall access rules.
EditorConfigure project editing access for an eligible contributor.
ManagerConfigure management access for the resource; this is not organization Admin.
BlockedRecord an explicit restriction for that project.

An organization Viewer cannot be promoted above Viewer through this picker. Changing a project role also does not grant departmental project-creation authority.

Understand Space blocks

A Space block is broader than a single project override. The interface retains project overrides while the Space is blocked and explains that they take effect again when it is unblocked. Unblocking is therefore not equivalent to resetting all child projects to a clean baseline.

The picker prevents blocking a Space for its creator. Owners and Admins also have broad role-based access; do not assume a normal Member restriction confines them.

Read counts correctly

“Overrides” means stored project exceptions, not the number of projects the person can currently open. An override count can include blocked projects, explicit Viewer roles, and explicit Editor roles. Likewise, a blocked-Space count is not a count of blocked project rows.

A Space roster can show no effective Space access while a project inside it has a direct grant. Inspect the project roster before concluding that the person cannot reach any work grouped under that Space.

Verify a change

Save pending Space-access changes before editing project overrides. Open Inventory for the Space and the affected project. Check the effective level and its source annotations, then ask the Member to try the intended action. Do not use the administrator’s own successful access as the test.