5 min read
How a healthcare organization went from 140 unmanaged Power Platform assets to a fully governed ALM practice in 12 weeks.
Reduction in deployment time
Rollback capability
Asset visibility
A large healthcare services organization had adopted Power Platform across multiple departments over 18 months. Business analysts built Power Apps for case tracking. Operations teams automated approval workflows with Power Automate. The IT service desk deployed a Copilot Studio agent for employee self-service. A vendor management team built a Power Pages portal for external partner onboarding.Organizations adopt Power Platform and build 50, 100, 200 apps. The platform is doing its job. But IT has no visibility into what exists, who built it, or how it moves between environments.
The platform was delivering value. The problem was everything around it.
140 apps, flows, and agents existed across 12 environments. Nobody had a complete inventory. Development happened directly in production environments. Deployments were manual solution exports, emailed to an admin, who imported them during lunch. There was no source control. No approval gates. No rollback procedure. When a deployment broke a production flow, the team spent hours rebuilding it from screenshots and memory.
The breaking point: A Friday afternoon deployment overwrote a production approval flow handling $2M in weekly purchase orders. The flow silently stopped routing approvals to the correct managers. By Monday morning, three days of purchase orders had been auto-approved without proper authorization.
We started with a two-week Power Platform Assessment to establish the full picture.
140 assets across 12 environments. 34 actively used in production. 28 abandoned (creator had left). 78 were development artifacts, test copies, or duplicates. None were managed solutions.
All 12 environments created ad hoc. Six named "Dev" or "Test" but ran production workloads. Three had identical apps with different versions. Two had no DLP policies.
No DLP policies at the tenant level. No connector governance. No maker onboarding process. No development standards. No deployment documentation.
14 critical items, 23 high items, and 31 medium items. Top risks: unmanaged solutions in production, missing DLP policies, and shared admin credentials.
We used our four-phase approach to build the ALM practice over 10 weeks.
Designed a four-environment model (Developer, Development, Test, Production). Grouped 34 active production assets into five solutions by business function: Core, Case Management, Operations, Service Desk, and Vendor Portal. Defined trunk-based branching strategy with one Azure DevOps repository per solution.
Provisioned four environments with security roles, DLP policies, and access controls. Created five Azure DevOps repositories and committed baseline solutions. Built CI/CD pipelines with Solution Checker gates, automated test imports, and two-person production approval. Replaced all hardcoded connections with connection references and environment variables.
Implemented tenant-level DLP policies with environment-specific overrides. Wrote development standards guide covering naming conventions, error handling, and documentation requirements. Documented change management workflows, rollback procedures, and emergency hotfix processes. Created Copilot Studio agent governance policy.
Ran full deployment cycles and rollback tests for every solution. Completed security validation against production environment. Delivered four recorded knowledge transfer sessions and a 40-page operations runbook covering pipeline administration, solution management, environment administration, and maker onboarding.
The purchase order approval flow that triggered the engagement now deploys through a pipeline with Solution Checker validation, test environment verification, and two-person approval before reaching production. The Friday afternoon overwrite scenario is no longer possible.
You cannot govern what you do not know exists. The assessment phase paid for itself by identifying 78 assets that could be safely decommissioned, reducing the migration scope by more than half.
The technical concept is simple. The execution across dozens of apps and flows, each with multiple connections built over 18 months of ad hoc development, is tedious and error-prone. Budget time for this.
We spent as much time on the development standards guide and maker onboarding materials as on the DLP policies and security configuration. Governance without enablement drives makers away from the platform.
The rollback procedure worked because we tested it during validation. Had we skipped that step, the first real rollback would have been an experiment during a production outage.
Our Power Platform Assessment gives you the inventory, risk heatmap, and prioritized roadmap to start your ALM journey.
