---
title: "Describe special cases and permissions chart"
url: "https://help.altus.pro/pt/article/describe-special-cases-and-permissions-chart"
language: "pt"
last_updated: "2026-05-28T06:28:01.041Z"
---

# Describe special cases and permissions chart

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](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)

| Component | What It Controls |
| --- | --- |
| Security Role | What actions a user can perform |
| Privilege | Specific action (Create, Read, Update, Delete, etc.) |
| Scope | Where the action applies (User / BU / Organisation) |
| Team | Group-based access and shared ownership |
| Sharing | Record-level exceptions to access rules |

* * *

## 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](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
