Permission Overrides

Permission overrides let Admins customise the default permission assignments for specific roles — either across the entire organisation, or within a specific project. Overrides extend or restrict what a role can do without changing the role itself.

When to use overrides

Overrides are appropriate when the default role capabilities don't exactly fit your project controls requirements:

• Grant extra access: Give initiator the ability to manage_documents (lock/unlock) in a specific project where initiators also act as document controllers
• Restrict access: Remove view_reports from reviewer in a sensitive project where report data is restricted
• Standardise across the org: Give all reviewer roles send_correspondence access org-wide, because your process requires reviewers to raise RFIs
• Temporary access: Grant a viewer temporary upload_documents access while a team member is absent

Types of overrides

Organisation-level override

Applies across all projects in the organisation. The modified permission applies to every project unless a project-level override sets a different value.

Location: Settings → Permissions (Org Admin required)

Use for: Changes that should apply consistently across all projects (e.g. "all Initiators should be able to manage distribution lists").

Project-level override

Applies to one specific project only. Takes precedence over the org-level default for that project.

Location: Project Settings → Permissions (Project Admin or Org Admin required)

Use for: Exceptions specific to one project (e.g. "In Project Alpha, Reviewers can also send correspondence").

How overrides stack

Scope	Priority
Project-level override	Highest — overrides everything
Org-level override	Middle — overrides the default
Default (role matrix)	Lowest — base value

Example:

Layer	reviewer → send_correspondence
Default	❌ (denied)
Org-level override	✅ (granted)
Project Alpha override	❌ (denied — project-specific exception)

Result in Project Alpha: reviewer cannot send correspondence (project override wins) Result in all other projects: reviewer can send correspondence (org override wins over default)

Configuring overrides

Adding an override

1. Navigate to the Permissions page (org-level or project-level).
2. Find the role you want to modify in the role list.
3. Find the permission action you want to change.
4. Click the toggle to switch between Granted and Denied.
5. The change is saved immediately.

Removing an override

Click the Reset to default link next to the override. The permission reverts to the next level's value (org override for project-level, default for org-level).

Override audit

All permission override changes are logged in the Audit Log under event category management:

• Who changed the permission
• What changed (role, action, old value, new value)
• When the change was made

Best practices for overrides

1. Document overrides in your project controls plan: Permission overrides are not visible in the user interface unless you navigate specifically to the Permissions settings. Document significant overrides so future admins understand why they exist.

2. Use org-level overrides for consistent exceptions: If a customisation applies to all projects, set it at the org level — not individually in each project.

3. Audit overrides regularly: As projects evolve and team members change, overrides may become unnecessary or incorrect. Review permissions quarterly during the project's life.

4. Test after setting overrides: After configuring an override, log in as a test member with that role to confirm the override produces the expected behaviour.

What's next

• Permissions Best Practices — role design patterns and least-privilege guidance
• Organisation Roles — base role capabilities (before overrides)
• Permission Actions Matrix — default permission assignments