Layered Platform ALM
A security-first decomposition framework for Microsoft Power Platform in enterprise and government deployments.
Read the Methodology View on GitHub GovFLOW
What Is LP-ALM?
LP-ALM decomposes Power Platform solutions into five discrete, ordered deployment layers instead of a single monolithic solution. Each layer has a defined scope, deployment method, and dependency contract with the layers around it.
The result: smaller deployment blast radius, security controls that precede schema, zero secrets in source control, and independent team ownership of each layer.
The Five Layers
| # | Layer | Purpose | Source Control | Pipeline |
|---|---|---|---|---|
| 1 | _Security | Security roles, field security profiles | ✅ | ✅ |
| 2 | _Core | All Dataverse schema — tables, columns, views, forms | ✅ | ✅ |
| 3 | _Config | Environment variable values | Never | Never |
| 4 | _Automation | Power Automate flows, connection references | ✅ | ✅ |
| 5 | _UI | Model-driven apps, canvas apps, site maps | ✅ | ✅ |
_Config is the controlled exception: it carries environment-specific values and is always deployed manually. It is permanently excluded from source control and pipelines — a zero-secrets-in-repo guarantee.
Core Principles
Security deploys first — always. Access control structures exist before any data schema is created. This is a structural control, not a process rule.
_UI cannot introduce schema. Tables and columns belong in _Core. The PR validation pipeline enforces this with an automated schema contamination check.
Managed solutions in upper environments. Test and Prod receive managed solutions only. Ad-hoc customization is blocked by the platform.
Service accounts, not personal credentials. Connection references are bound to service accounts in every environment. Required for GCC High; best practice everywhere.
NIST 800-53 Alignment
LP-ALM is designed for FedRAMP and GCC High deployments and maps directly to NIST 800-53 controls:
| Control | Implementation |
|---|---|
| AC-2 Account Management | Service principal application users per environment; no personal credentials |
| AC-3 Access Enforcement | _Security deploys before schema; managed solutions prevent unauthorized change |
| AC-6 Least Privilege | Per-persona security roles; pipeline SP uses System Administrator only where required (prvWriteRole) |
| CM-2 Baseline Configuration | Four committed layers are the authoritative baseline; _Config tracked in environment register |
| CM-3 Configuration Change Control | All changes via PR + pipeline; managed solutions block direct environment modification |
| SA-3 System Development Life Cycle | Structured Dev → Test → Prod lifecycle with independent layer sequencing and rollback |
What’s in This Repository
| Document | Description |
|---|---|
| LP-ALM Methodology | Complete 11-section methodology reference |
| Onboarding Checklist | New team and new project setup steps |
| Component Placement | Decision tree: where does this component go? |
| Security Role Matrix | Privilege matrix template with Append/Append To guidance |
Framework Alignment
LP-ALM governs what is inside a solution artifact and how it moves between environments. Platform-layer concerns — DLP policies, environment provisioning, monitoring, BCDR — are out of scope by design and are covered by Microsoft’s platform governance frameworks.
| Framework | Relationship to LP-ALM |
|---|---|
| Power Platform Well-Architected | LP-ALM directly implements the Security and Operational Excellence pillars at the solution layer. Use the Well-Architected assessment to evaluate the full workload across all five pillars. |
| Power Platform Landing Zones | Landing Zones governs environment provisioning, DLP policies, and IAM. LP-ALM governs solution deployment within those environments. For enterprise deployments, both apply. |
| CoE Starter Kit | Compatible. CoE Starter Kit addresses tenant governance and citizen developer management. LP-ALM addresses pro-developer solution ALM. |
Recommended reading order for enterprise adoption:
- Power Platform Landing Zones — establish the platform foundation
- LP-ALM — structure solution deployment within that foundation
- Power Platform Well-Architected — validate the workload design
See Section 12 of the methodology for the full alignment mapping and platform prerequisites. | Environment Register | Environment inventory template |
Suitable For
- Enterprise Power Platform teams managing multi-environment deployments
- Government and regulated-industry projects (FedRAMP, CMMC, FISMA, HIPAA)
- Architects building repeatable delivery pipelines with Azure DevOps and PAC CLI
- Consulting teams needing a documented, defensible ALM methodology
LP-ALM is not appropriate for single-environment prototypes, citizen developer projects without a dedicated ALM team, or solutions that will never leave a development environment.