Altus security is built on the Microsoft Dataverse model, combining security roles, privileges, and scope to determine user access.

While standard role assignments define most access, there are important special cases and behaviours that influence how permissions are applied in practice.

Understanding these ensures accurate governance and avoids unexpected access outcomes.

For detailed Altus-specific scenarios, refer to:
https://docs.altus.pro/products/AltusPPM/Configuration/Security/index.html#special-cases

Important: Platform & Permissions

Security behaviour in Altus is governed by:

• Power Platform / Dataverse security roles
• Business Units (scope)
• Teams and sharing mechanisms

These are configured in:

• Power Platform Admin Centre
• Power Apps / Dataverse

Core Permission Components

Privileges (What users can do)

Examples include:

• Create
• Read
• Update (Write)
• Delete
• Assign
• Share

Scope (Where users can do it)

Access is applied at different levels:

• User (Basic) – Own or shared records
• Business Unit (Local) – Records within the user’s business unit
• Organisation (Global) – All records

These work together to determine effective access.

Special Cases in Permission Behaviour

The following scenarios are particularly important in Altus implementations:

1. Multiple Security Roles

• Users can have multiple roles assigned
• Permissions are cumulative
• The highest level of access across all roles is applied

2. Team-Based Access and Ownership

• Teams can be assigned security roles
• Teams can also own records
• Users inherit access through team membership

In Altus, this is commonly used for:

• Project teams
• Program or portfolio ownership

3. Record Ownership and Sharing

Access is influenced by:

• Record ownership (user or team)
• Explicit sharing

This means users may access records if they are:

• Shared directly
• Owned by a team they belong to

4. Business Unit Boundaries

• Access is restricted by Business Unit hierarchy
• Users cannot automatically access data outside their scope
• Broader access requires appropriate role configuration (e.g. Global scope)

5. Role Assignment Constraints

• Users can only assign roles within their own privilege level
• Prevents unintended escalation of access

Permissions Chart (Conceptual Model)

How This Impacts Altus

These behaviours determine:

Who can access:

• Projects
• Risks, Issues, Deliverables
• Financial and reporting data

What actions users can perform:

• View vs edit vs approve
• Assign or manage records

They also influence:

• Cross-project collaboration
• Portfolio-level visibility
• Governance and compliance controls

Additional Reference

For supporting Microsoft guidance on how permissions and roles are applied in Power Platform, refer to:
https://learn.microsoft.com/en-us/power-platform/admin/assign-security-roles

Key Considerations

• Permissions are cumulative across roles
• Teams and sharing can extend access beyond roles
• Business Units define data visibility boundaries
• Always validate access using real scenarios