This playbook provides a structured approach to diagnosing and resolving access issues in Altus.

Security in Altus is determined by a combination of:

• Security roles
• Business Unit (BU) scope
• Team membership
• Record ownership and sharing

Because of this layered model, troubleshooting must follow a consistent sequence to identify the root cause.

Step 1: Use “Check Effective Rights” (Primary Check)

This is the first and most reliable step.

1. Open the relevant Altus record (e.g. Project, Risk, Issue)
2. In the Command Bar (ribbon), select Check Effective Rights
3. Select the user
4. Review:
5. • Read (View) access
   • Write (Edit) access
   • Delete, Assign, Share permissions

👉 This shows the actual permissions applied to that specific record

✅ If access is correct here → issue is likely user behaviour or UI expectation
❌ If access is missing → continue to next steps

Step 2: Confirm Record Visibility

Ask:

• Can the user see the record at all?
• • NO → likely scope (BU) or role issue
  • YES → proceed to next step

Step 3: Check What the User Can Do

Observe actual behaviour:

• Are fields read-only or editable?
• Can the user:
• • Update data?
  • Change status?
  • Assign ownership?

👉 This helps distinguish between:

• Read-only role issue
• Partial access limitation

Step 4: Validate Security Roles

Confirm:

• Which Basic role is assigned
• Which Modular roles are assigned
• Whether multiple roles are applied

Remember:

• Permissions are cumulative across roles
• Missing access → role likely doesn’t include required privilege

👉 Refer to: https://learn.microsoft.com/en-us/power-platform/admin/assign-security-roles

Step 5: Check Business Unit (BU) Scope

Validate:

• User’s Business Unit
• Record’s Business Unit / ownership structure

Common issue:

• User has correct role but scope is limited to their BU

If needed:

• Role must allow Organisation-level (Global) access

Step 6: Check Team Membership

Confirm whether:

• Record is owned by a team
• User is part of that team

If using group-based access:

• Check linked M365 / Entra ID group membership

👉 Remember:

• Team membership = inherited permissions
• Missing from team = no access

Step 7: Check Record Ownership

Confirm:

• Who owns the record:
• • User
  • Team

Ownership directly affects:

• Visibility
• Edit permissions

Step 8: Check Sharing

Validate whether the record is:

• Shared directly with the user
• Shared via a team

Sharing can:

• Grant access beyond role/BU limits
• Cause differences between users

Step 9: Compare with a Working User

If unsure:

• Compare the problem user with a user who has correct access

Check differences in:

• Roles
• BU
• Teams
• Ownership

👉 This is often the fastest way to isolate issues

Common Root Causes

Key Principles

• Access is not defined in one place
• Always validate using:
• • ✅ “Check Effective Rights”
  • ✅ Real record behaviour
• Roles + BU + Teams + Ownership = final access

Tips

• Start with Check Effective Rights every time
• Avoid guessing — validate step-by-step
• Use group-based access for consistency
• Document standard access patterns for your organisation

✅ This gives you a complete, practical troubleshooting layer on top of your KB set:

• Admin setup ✅
• Security model ✅
• Sync model ✅
• Real-world troubleshooting ✅