Two years ago, we opened up Power Platform to business users at Julius Silvert. The promise was compelling: let the people closest to problems solve them without waiting in the IT queue. Citizen development. Democratized automation. Innovation at the speed of business.
That promise was real. We've seen amazing solutions built by people who'd never written code before. But the promise came with complications we didn't fully anticipate. Shadow IT sprawl. Data governance gaps. Apps that worked until their creator left the company. Security exposures nobody knew existed.
This post is about what we learned and the governance framework we built that actually works - balancing innovation with control without killing either.
The Wild West Phase
For the first six months, we took a hands-off approach. We enabled Power Apps and Power Automate for all Microsoft 365 users and said "go build things." The results were impressive - and terrifying.
Impressive: Our warehouse supervisor built a safety inspection app in a weekend. Our sales coordinator automated their weekly commission calculations. Our facilities manager created an equipment maintenance tracker that replaced a whiteboard.
Terrifying: We discovered 47 flows connecting to external services we'd never approved. Someone built an app that exported customer credit data to a personal SharePoint. Three "critical" processes were running on flows owned by people who'd left the company months ago.
We needed governance. But we also needed to preserve the innovation we'd unlocked. Heavy-handed restrictions would just push development back underground.
The Governance Framework
Our framework is built on three principles:
- Enable by default, restrict by exception. We assume people have good intent and provide guardrails rather than gates.
- Visibility over control. We prioritize knowing what exists over preventing everything.
- Risk-proportionate requirements. Simple automations get minimal oversight. Business-critical apps get more.
Environment Strategy
We use a tiered environment model:
Default Environment (Sandbox)
Every user can build here. No approval needed. Limited connectors - Microsoft 365 services only. Apps here are personal productivity tools. Data cannot leave the tenant. We scan weekly and reach out to creators of anything that looks like it should be promoted.
Departmental Environments
One per major department (Operations, Sales, Finance, etc.). Users request access through a simple form. Approved connectors include department-specific services. Apps here support team workflows. Owners must be documented. Quarterly review of active apps and flows.
Production Environment
Managed by IT. All connectors available. Solutions must go through change management. Documentation required. Testing required. Backup/DR included. This is for business-critical applications.
This tiering lets people experiment freely while creating natural checkpoints as solutions mature.
Data Loss Prevention (DLP) Policies
Our DLP policies are the backbone of our governance. We categorize connectors into three groups:
Business: Internal systems that should talk to each other - D365, SharePoint, Dataverse, Teams, Outlook. These can be combined freely.
Non-Business: External services that might be legitimate but need isolation - Twitter, external email services, generic HTTP connectors. These can talk to each other but not to Business connectors without explicit exception.
Blocked: Services we've determined have no legitimate business use or pose unacceptable risk. The list is short - we'd rather monitor than block in most cases.
The key insight: blanket blocking creates shadow IT. Visibility with guardrails creates manageable risk.
The Power Platform Center of Excellence
We deployed Microsoft's CoE Starter Kit about 18 months ago. It was a game-changer. The kit gives us:
- Inventory: Every app, every flow, every maker, every connector - automatically catalogued
- Analytics: Usage patterns, active vs. abandoned solutions, growth trends
- Hygiene automation: Apps unused for 90 days trigger notifications to creators. Flows that fail repeatedly get flagged for review.
- Compliance reporting: Which solutions access sensitive data? Who owns what?
The CoE Kit isn't just tooling - it's visibility. And visibility enables proportionate response rather than reactive lockdown.
The Maker Journey
We've formalized the path from "I have an idea" to "this runs the business":
Stage 1: Personal Productivity. Build whatever you want in the default environment. No approval. No documentation. If it helps you, great.
Stage 2: Team Solution. Your app is useful to others? Request departmental environment access. Document what it does and who uses it. Name a backup owner. Get basic training on best practices.
Stage 3: Business Process. This is now critical to operations? Migrate to production. Full documentation. Testing. Error handling. Backup/DR. Support from IT.
Most solutions stay at Stage 1 or 2. That's fine. The framework ensures that the ones that matter get the attention they need.
What We Got Wrong
Our framework isn't perfect. Here's what we'd do differently:
Started governance earlier. Six months of Wild West created technical debt we're still cleaning up. Orphaned flows. Duplicate solutions. Data in unexpected places. Light guardrails from day one would have prevented most of this.
Training before tools. We enabled Power Platform before teaching people how to use it well. Result: fragile solutions, poor error handling, performance problems. Now we require basic training before departmental environment access.
Connector management was too permissive. We initially allowed Premium connectors widely because we didn't want to limit innovation. But Premium connector licensing is per-user, and costs ballooned. Now we gate Premium access more carefully.
The Licensing Challenge
Speaking of licensing - this deserves its own section because it's where most organizations get surprised.
Power Platform licensing is complex. Some capabilities are included in Microsoft 365. Some require standalone licenses. Some require Premium connectors. Some are capacity-based (Dataverse storage). The combinations are mind-numbing.
Our approach:
- Microsoft 365 included capabilities: Available to everyone, no gatekeeping
- Per-user Premium licenses: Limited pool, requested through IT, justified by business need
- Per-app licenses: For specific scenarios where per-user doesn't make sense
- Dataverse capacity: Monitored monthly, alerts at 70% utilization
The key is establishing a licensing review as part of the Stage 2 to Stage 3 promotion. Don't let business-critical solutions run on licenses that could evaporate when someone changes roles.
Metrics That Matter
We track several KPIs for our Power Platform program:
Active makers: 34 (out of 180 employees) - about 19% are building solutions
Active apps: 67 (up from 12 two years ago)
Active flows: 142 (up from 8 two years ago)
Orphan rate: 8% (solutions owned by departed employees) - down from 23% before governance
DLP violations caught: 3 this quarter - all resolved without incident
Estimated hours saved: 180 hours/week across all solutions
That last number is the one executives care about. 180 hours per week is roughly 4.5 FTE equivalent. The entire Power Platform licensing cost is less than one FTE salary.
Security Considerations
Citizen development creates security surface area. Our security approach:
Connector auditing: Every external connection is logged. We review monthly for anomalies - unexpected data volumes, new external services, unusual patterns.
Conditional access: Power Platform access respects our Entra ID conditional access policies. Unmanaged devices can't access apps that touch sensitive data.
API limits as safety nets: We configure aggressive API limits in non-production environments. A runaway flow hits its limit before it causes real damage.
Sensitive data detection: We use Microsoft Purview to flag solutions that might be handling data they shouldn't - credit card patterns, SSN formats, etc.
Looking Ahead: AI and Copilot
Power Platform is increasingly AI-infused. Copilot Studio, AI Builder, natural language flow creation - these capabilities are powerful and raise new governance questions.
Our early thinking:
Copilot Studio: Same environment model as apps and flows. Personal experiments in default, team bots in departmental, production-grade in managed environment.
AI Builder: Requires explicit enablement. Training AI models on company data needs oversight. We're piloting with a small group before broader rollout.
Natural language development: Actually helps governance - solutions created through natural language tend to be simpler and more standard than hand-built ones.
Recommendations for Other Organizations
If you're starting your Power Platform governance journey:
- Start with visibility, not control. Deploy the CoE Kit (or equivalent) before writing policies. You can't govern what you can't see.
- Engage your enthusiasts. Your most active makers are your best governance advocates. Include them in policy development.
- Communicate the "why." People accept restrictions when they understand the reasoning. "This protects the company" lands better than "this is the rule."
- Build graduated paths. Let people start small, then support them as solutions mature. Don't gate the beginning.
- Plan for licensing. Model costs before opening the floodgates. Premium features are compelling and expensive.
Power Platform governance isn't about preventing innovation - it's about enabling sustainable innovation. Get it right, and you unlock enormous value. Get it wrong, and you create technical debt, security exposure, and frustrated users.
We're still learning. But two years in, our framework is working. The innovation continues, the risks are managed, and IT sleeps better at night.
Planning an ERP modernization?
6 SAP-to-Dynamics conversions with zero business disruption. Let's discuss your project.
ERP Services Book a Call