Project permissions

Project permissions let you tailor access for an individual project. Organization-wide roles set a sensible default everywhere; project permissions are how you adjust that default where a particular project needs tighter or looser access.

Defaults and overrides

Within a project, each role has a default access — what a Contributor or a Viewer can do there out of the box. Where a project differs from the norm, you add permission overrides that change a role’s access for that project specifically, without touching the organization-wide role. A user’s effective access in a project is the combination of their inherited organization permissions and any project-level overrides applied on top.

Why per-project control matters

Not every project should be equally open. A project under active regulatory scrutiny might restrict who can edit, while an internal exploratory project might be more permissive. Project permissions make that possible without creating a tangle of one-off roles: you keep a clean set of organization roles and adjust at the project boundary where it’s genuinely needed.

Alongside module access

Project permissions govern what people can do; Module access governs which modules a project uses at all. Together they define the shape of a project — its capabilities and who can exercise them.