Understanding administration boundaries in Altus
Altus is built on the Microsoft Power Platform, which means administration and configuration activities are distributed across multiple layers:
- Altus application settings (in-app)
- Power Platform / Dataverse (environment level)
- Microsoft 365 / Entra ID (identity & access)
- Power BI (Insights and reporting)
As a result, not all administrative tasks are managed directly within Altus, and different privileges and skillsets are required depending on where the task is performed.
Important: If your organisation has upgraded from a Microsoft Project Online-based solution, refer to the following section of the upgrade guide for additional context on administration and configuration differences: https://help.altus.pro/en/article/upgrading-from-microsoft-project-online-to-altus#-10.-general-settings-and-administration
Important: Not All Settings Are Self-Service
While Altus supports low-code / no-code configuration, this does not mean all areas are fully self-service.
Based on Altus guidance and administration modelling:
- Some configurations are safe for self-service within Altus
- Some require elevated platform-level access (Power Platform / Power BI / M365)
- Others require specialist knowledge and engagement with your implementation partner
⚠️ Many advanced configuration and customisation activities are not recommended to perform without prior guidance from your technical support or implementation partner.
This is particularly important as users familiar with other platforms may assume all settings are self-service—but in a Power Platform solution like Altus, governance and solution integrity must be maintained.
Administration Responsibility Model
The table below outlines how administration tasks are typically distributed:
In-App (Altus Settings – Self-Service)
Area | Example Tasks | Required Role |
|---|---|---|
System Configuration | Feature toggles, UI settings, behaviour controls | Altus Admin User |
Project Configuration | Project types, forms, views, fields (limited scope) | Altus Admin User |
Resource Settings | Timesheets, resource behaviour | Altus Admin User |
Configuration Settings | System-wide behaviour tuning | Altus Admin User |
These are generally safe self-service areas and do not require deep Power Platform expertise
Platform-Level (Power Platform / Admin Centre)
Area | Example Tasks | Required Role |
|---|---|---|
Security Roles | Create/edit roles, assign permissions | System Administrator |
Users & Teams | Group-based access, Dataverse teams | System Administrator |
Business Units | Data access hierarchy | System Administrator |
Environment Settings | Environment-level configuration | Power Platform Admin |
⚠️ These are managed in:
- Power Platform Admin Centre
- Power Apps (make.powerapps.com)
👉 Require platform-level access and understanding of Dataverse security
Identity & Access (Microsoft 365 / Entra ID)
Area | Example Tasks | Required Role |
|---|---|---|
User Accounts | Create/manage users | M365 Admin |
Security Groups | Group-based access control | Entra ID Admin |
Group Membership | Onboarding/offboarding users | Entra ID Admin |
⚠️ These drive access into Altus but are fully external to the application
Reporting & Insights (Power BI)
Area | Example Tasks | Required Role |
|---|---|---|
Workspace Access | Grant Member/Viewer access | Workspace Admin |
Dataset Management | Refresh schedules, updates | Dataset Owner |
Report Publishing | Upload/update PBIX reports | Power BI Admin / Member |
⚠️ Required for:
- Access to Insights dashboards
- Embedded reporting within Altus
Advanced Customisation (Guided / Partner-Led)
Area | Example Tasks | Required Skillset |
|---|---|---|
Solution Customisation | Forms, tables, views, logic | Power Apps / Dataverse expertise |
Integrations | External systems, APIs | Developer / Architect |
Advanced UI / Components | PCF controls, JavaScript | Developer |
Solution Management | Managed/unmanaged solutions | Extended Admin |
Automation | Power Automate flows, BPFs | Power Platform expertise |
These areas are typically not for beginner administrators and require strong applied knowledge of Microsoft Power Platform services.
Key Principles
1. Altus ≠ All Administration
Altus provides application-level configuration, but:
- Identity, security, and reporting are managed externally
- Full administration spans multiple Microsoft platforms
2. Self-Service Has Boundaries
While some changes can be made directly:
- Not all changes are safe or supported for self-service
- Some require structured governance and technical validation
3. Role-Based Access Matters
Different activities require different roles, including:
- Altus Admin User
- System Administrator
- Power BI Workspace Owner
- Solution Customizer
These roles span different platforms and responsibilities.
4. Use a Governed Approach
Organisations should:
- Define who manages each layer
- Use group-based access (Entra ID)
- Align Altus, Power Platform, and Power BI access models
- Engage implementation partners for advanced changes
When to Engage Your Implementation Partner
You should seek guidance when:
- Making structural changes to the data model
- Introducing new integrations
- Customising business logic or workflows
- Modifying reporting architecture
- Implementing advanced UI or automation
👉 These changes can impact:
- Data integrity
- Security
- Upgrade compatibility
- Long-term maintainability
Summary
Altus administration is a shared responsibility model across multiple platforms.
- ✅ Use Altus settings for routine configuration
- ⚙️ Use platform tools for security and environment control
- 📊 Use Power BI for Insights access and reporting
- 🛠️ Engage experts for advanced customisation