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.

The reason to override at the project boundary rather than mint new roles is that it keeps your access model clean as it scales. Every one-off role you create is something a security review later has to understand; a small set of organization roles adjusted per project where genuinely needed is far easier to reason about. This matters because projects legitimately differ in sensitivity — one under active regulatory scrutiny may need editing locked down while an exploratory one stays open — and handling that at the boundary lets you accommodate the difference without your permission scheme sprawling into an unauditable tangle.

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.