Governance Playbook: Power Platform Maker Onboarding Programme

What You’ll Learn

This playbook provides a step-by-step framework for onboarding new Power Platform makers in your organisation. It covers the training path, sandbox provisioning, guardrails, support structures, and ongoing development that turns enthusiastic beginners into responsible citizen developers.

Why Onboarding Matters

Most organisations take one of two approaches to citizen development:

1. Open door: Anyone can build anything. Result: shadow IT, ungoverned apps, security incidents, orphaned solutions that no one can maintain.
2. Locked door: Only IT builds solutions. Result: backlog grows, business users find workaround tools (Zapier, Airtable, etc.), IT loses control anyway.

A maker onboarding programme is the middle path — enabling business users to build while ensuring quality, security, and sustainability from the start.

The Onboarding Journey

Phase 1: Awareness (Week 1)

Goal: The maker understands what Power Platform is, what they can build, and what the rules are.

Activities:

• Welcome email with links to internal Power Platform resources
• 30-minute “What is Power Platform?” video or live session
• Access to the internal maker community (Teams channel, SharePoint site)
• Read the organisation’s citizen developer policy (one page, plain language)

Deliverables:

• Maker registers in the maker directory (a simple SharePoint list or Dataverse table tracking who is building what)
• Maker acknowledges the acceptable use policy

Phase 2: Foundations Training (Weeks 1-2)

Goal: The maker can build a basic app and flow using approved patterns.

Training Path by Role:

Target Role	Training Content	Duration
Business user (first-time)	Power Apps basics, gallery/form pattern, simple approval flow	4-6 hours
Power user (some Excel/VBA)	Above + delegation, variables, collections, error handling	8-10 hours
IT professional	Above + Dataverse modelling, solution management, ALM basics	12-16 hours

Recommended Resources:

• Microsoft Learn modules (free, self-paced)
  • “Get started with Power Apps” learning path
  • “Get started with Power Automate” learning path
• Internal “follow-along” workshop using a real business scenario from your organisation
• PL-900 study materials for those pursuing certification

Key Topics to Cover:

1. What are Power Apps, Power Automate, and Dataverse?
2. How to build a basic canvas app with a gallery and form
3. How to create an approval workflow
4. What delegation is and why it matters
5. Where to save your work (environments, solutions)
6. Who to ask for help (COE contacts, community channels)
7. What the DLP policies allow and restrict

Phase 3: Sandbox Access (Week 2)

Goal: The maker has a safe space to build and experiment.

Provisioning Checklist:

• Developer environment created (or access to shared sandbox)
• Maker granted Environment Maker role
• DLP policy applied (permissive for sandbox)
• Sample data loaded (never production data)
• Connection references configured (approved data sources only)
• Maker knows how to export as a solution

Automation: Automate sandbox provisioning with a Power App request form + Power Automate flow that calls the admin API. Target: sandbox available within 4 hours of completing training.

Phase 4: First Build (Weeks 2-4)

Goal: The maker builds their first real solution with guidance.

Structure:

• Maker identifies a real business problem (not a toy example)
• COE mentor assigned (someone who reviews their first build)
• Weekly 15-minute check-in with mentor
• Build happens in sandbox environment
• Mentor reviews before promotion to production

First Build Criteria:

The first solution should be:

• Small scope (1 app or 1 flow, not both)
• Low risk (no sensitive data, no financial impact)
• Clear owner (the maker is responsible for maintenance)
• Documented (basic README in the solution description)

Common First Builds:

• Team leave request tracker
• Equipment checkout system
• Meeting room booking app
• Document approval workflow
• Expense report submission

Phase 5: Production Promotion (Week 4+)

Goal: The first solution goes live with proper governance.

Production Readiness Checklist:

• Solution exported as managed from sandbox
• Tested by at least one person who didn’t build it
• Error handling implemented (no silent failures)
• Naming convention followed (apps, flows, tables, columns)
• Connection references used (not hardcoded connections)
• Owner documented in the maker directory
• Support plan defined (who fixes it when the maker is on holiday?)
• DLP compliance verified (no blocked connectors needed)

Approval Flow:

1. Maker submits production promotion request
2. COE reviews checklist items
3. If approved: solution deployed to production environment
4. If gaps: specific feedback provided, maker addresses and resubmits

Phase 6: Ongoing Development (Continuous)

Goal: The maker grows their skills and contributes to the community.

Activities:

• Monthly “Maker Meetup” (virtual or in-person, 30 minutes)
• Quarterly skill assessments (self-service, optional)
• Access to advanced training (Dataverse, ALM, custom connectors)
• Opportunity to mentor new makers
• Recognition programme (highlight successful solutions)

Support Structures

COE Support Tiers

Tier	Who	When	Response Time
Self-service	FAQ, docs, videos	First stop for all questions	Immediate
Community	Teams channel, maker peers	”Has anyone done this before?”	Same day
COE office hours	Weekly drop-in session	Complex design questions	Next session
COE ticket	Formal support request	Production issues, access requests	1 business day
Escalation	IT/security team	Security incidents, data breaches	Immediate

Community Channel Best Practices

Create a Teams channel (or Viva Engage community) for makers:

• Pin the essentials: Acceptable use policy, training links, environment request form
• Encourage sharing: Ask makers to post screenshots of what they’ve built
• Weekly tips: COE posts one tip per week (a formula, a pattern, a gotcha)
• No judgement: Beginners ask basic questions — this is healthy
• Tag the experts: Use tags for different components so the right people see relevant questions

Guardrails

What Makers Can Do (Without Approval)

• Build apps and flows in their sandbox environment
• Use standard connectors in the Business DLP group
• Share apps with up to 10 colleagues for testing
• Create Dataverse tables in sandbox environments

What Requires COE Approval

• Promote a solution to production
• Use premium connectors (licensing cost)
• Create custom connectors
• Access production Dataverse environments
• Build solutions that handle sensitive data (PII, financial, health)
• Share apps organisation-wide

What Is Not Allowed

• Build in the production environment directly
• Use personal accounts or unsanctioned services
• Store credentials in flow variables or app formulas
• Create solutions without an identifiable owner
• Bypass DLP policies (even if technically possible)

Measuring Success

Track these metrics to evaluate your onboarding programme:

Metric	Target	Frequency
Makers completing training	80% of registrants	Monthly
Time from request to sandbox	< 4 hours	Monthly
First solutions built	60% of trained makers	Quarterly
Solutions promoted to production	40% of first builds	Quarterly
Production incidents from citizen-built apps	< 2 per quarter	Quarterly
Maker satisfaction (survey)	> 4/5	Quarterly
Orphaned apps (no active owner)	< 10% of total	Quarterly

Scaling the Programme

10-50 Makers

• One COE lead manages the programme part-time
• Monthly meetups
• Manual sandbox provisioning is acceptable
• Informal mentoring (pair experienced makers with newcomers)

50-200 Makers

• Dedicated COE team (2-3 people)
• Automated sandbox provisioning
• Formal mentoring programme with assigned mentors
• Quarterly training cohorts (batch onboarding)
• Power Platform Champions network in each department

200+ Makers

• Full COE team with specialised roles (training, governance, support)
• Self-service onboarding portal (Power App)
• Certification tracks aligned with role-based paths
• Annual Power Platform internal conference / hackathon
• Dedicated Dataverse instance for the COE tools and tracking

Common Mistakes

1. Mandatory training with no hands-on: Reading docs is not onboarding. Makers need to build something during training, ideally solving a real problem from their own work.

2. No mentor for the first build: The gap between training and the first real solution is where most makers give up. A mentor who reviews their work and provides feedback dramatically increases success rates.

3. Too many approvals: If promoting a simple app requires five signatures and a three-week review, makers won’t bother. Streamline the process — one COE review should be sufficient for low-risk solutions.

4. Ignoring the community: A thriving maker community is worth more than any training course. Invest time in the community channel, celebrate successes publicly, and make it safe to ask basic questions.

5. No ownership tracking: When a maker leaves the organisation, their apps and flows become orphaned. Track ownership from day one and require a backup owner for every production solution.

Taking It Further

• Assess your COE maturity with the COE Maturity Assessment
• Design your environment topology with the Environment Strategy Playbook
• Generate a governance policy document with the Governance Policy Generator
• Set DLP policies with the DLP Policy Planner