Access rules

Access rules are how the platform decides, for any user and any action, whether it’s allowed. Rather than a single setting, a user’s access is the result of several layers combining — and understanding how they fit together is the key to governing access cleanly.

The layers of access

Three things determine what a person can do. Their role sets an organization-wide baseline — the access level and enforced permissions that role carries. Project permissions adjust that baseline for a specific project, where it needs to differ. And module access determines which modules a project uses and the default access to each. A user’s effective access is these layers resolved together: the role they hold, narrowed or widened by the project, scoped to the modules in play.

Enforced consistently

These rules aren’t advisory — they’re enforced at every point a user tries to act, so access is guarded uniformly rather than checked in some places and not others. A person simply cannot take an action their resolved access doesn’t permit, which is what makes the model trustworthy as a control.

Designing access well

The art is to lean on organization-wide roles for the common case and reserve project permissions and module access for genuine exceptions. That keeps access explainable — you can say why someone can do something by pointing at their role and any deliberate overrides — rather than buried in a thicket of one-off grants. Combined with lock management, this is the full picture of who can do what, and when.