Guide

How to run a governed automation programme

A practical guide to building a governed community of business makers who automate with Power Automate and Microsoft Copilot Studio: the foundations to set first, how to choose makers and use cases, and how to keep it going.

By Josh Igoe, Microsoft Certified Trainer · Updated 14 October 2026

Why run a governed automation programme?

In most organisations, the people who understand a process best are the people who run it every day. Power Platform lets them improve it themselves: a Power Apps form instead of a spreadsheet, a Power Automate approval instead of an email chain, a Copilot Studio agent instead of a shared inbox full of the same questions.

Left alone, this produces a familiar mess: dozens of apps nobody supports, flows running under the account of someone who left last year, and an IT team that discovers business-critical automations only when they break. Shut it down, and the work goes back to spreadsheets or to shadow tools outside your tenant.

A governed automation programme, often called a citizen developer programme, is the middle path. It gives business makers the skills and freedom to build, inside guardrails that IT can support. This guide sets out how to design one that lasts.

Users, builders and makers

It helps to be precise about who you are developing. We use a simple model:

• Users use Microsoft 365 Copilot and the apps others build. Almost everyone.
• Makers are business people who build apps, flows and simple agents for their own team's processes. This is the citizen developer group.
• Builders are IT, automation and digital specialists who build more complex, integrated solutions, support makers and own the platform.

A citizen developer programme is mainly about makers, but it only works if builders and the platform owner are part of it. Makers need someone to escalate to, and IT needs to trust what makers build.

Governance foundations

Put these in place before you invite the first cohort. They do not need to be elaborate, but they need to exist.

Environment strategy

Environments are containers for apps, flows, agents and data. A simple, common pattern:

Managed Environments and environment groups help apply consistent settings, such as sharing limits and usage insights, across these environments where your licensing supports them.

Data policies

Power Platform data policies (previously called data loss prevention policies) control which connectors can be used together. A common approach groups connectors into business, non-business and blocked categories, with a stricter policy in the default environment. Agree the policy before training, so makers learn the rules they will actually work under.

Roles and responsibilities

• Executive sponsor. Gives the programme air cover and links it to business priorities.
• Platform owner. Owns environments, policies and licensing.
• Centre of Excellence lead. Runs the programme day to day: onboarding, community, standards and reporting.
• Makers. Build and own solutions for their own processes, within the rules.
• Maker mentors. Experienced makers or builders who review designs and help when people are stuck.

Solution ownership

Every app, flow and agent outside personal productivity needs a named business owner and a backup. Use solutions and connection references so ownership can change without rebuilding. Decide what happens when an owner leaves.

Visibility

Microsoft's Power Platform admin centre and the Centre of Excellence (CoE) Starter Kit give inventory and usage information about apps, flows, makers and connectors. Even a basic inventory is enough to start conversations with makers before small problems become large ones.

Choosing makers and first use cases

The first cohort sets the tone. Choose makers who:

• Own or deeply understand a process that causes real friction.
• Are comfortable with logic, for example confident with Excel formulas or structured data.
• Have their manager's support and time to practise between sessions.
• Will share what they learn with others.

Good first use cases are small, frequent and visible. Look for processes that run weekly or daily, involve a handful of people, currently rely on email or spreadsheets, and do not involve highly sensitive data. Examples: equipment or room requests, simple approvals, onboarding checklists, issue logs and status tracking. Avoid starting with anything that touches payroll, regulated decisions or external customers.

Score candidates on value (time, errors, frustration), feasibility (data available, connectors allowed) and risk. Pick one use case per maker or pair of makers.

A staged curriculum

Makers learn best in stages, with practice between them. A sequence that works:

1. Everyday Copilot foundations. Help makers become confident users before asking them to build. AB-730 is for everyday users.
2. Simple agents. Introduce agent-building skills for business users. MS-4019 is for users building simple agents.
3. Copilot Studio. For makers and developers, explore MS-4022. Other app and automation skills discussed in this article are educational context, not additional IGOE AI course offers.
4. Internal governance and supervised practice. Apply your organisation’s policies and review work with an internal mentor.

Building a community that lasts

Training starts a programme. A community sustains it.

• A Teams community where makers ask questions, share patterns and see what others have built.
• Regular show-and-tell sessions, short and informal, where makers demonstrate what they built and what they learned.
• Office hours with mentors or builders for the stuck bits.
• Shared patterns and templates: approved approaches for approvals, notifications, error handling and naming.
• Recognition. Simple acknowledgement from leaders goes a long way, as do certification milestones.
• A clear path upwards: when a maker's solution becomes important to many people, a defined process moves it to a supported environment with builder involvement.

Common pitfalls

• Training without governance. Makers trained before the environment strategy and data policies exist build habits you will later need to undo.
• Governance without enablement. Policies so restrictive that nothing useful can be built push people back to spreadsheets and unsanctioned tools.
• No time allocated. Makers expected to build ‘in spare time’ rarely finish.
• Choosing ambitious first projects. A complex, cross-departmental first build is likely to stall and discourage everyone.
• Personal ownership of business solutions. Flows running under individual accounts break when people change roles.
• Measuring apps built. The number of apps is not a measure of value. Measure processes improved.

Measuring the programme

Agree measures at the start. Useful ones include:

• Makers trained, and makers actively building three and six months later.
• Solutions in production, the processes they address and their owners.
• Hours saved or errors avoided, validated by the teams that run the process rather than estimated by the builder.
• Governance health: solutions in the right environments, without orphaned owners, within data policies.
• Applied Skills results where makers take the assessment.

Our guide to measuring adoption and value includes a reporting template you can adapt.

Your first 90 days

How IT and makers work together

The most successful programmes treat IT as an ally rather than a gatekeeper. In practice that means a few simple agreements.

• A clear line between maker and builder work. Makers own solutions for their team's processes. When a solution needs complex integration, handles sensitive data or becomes critical to many people, builders get involved. Agree the triggers in advance, for example number of users, data classification or external access.
• A light review before production. A short checklist covering ownership, data, connectors, error handling and documentation, reviewed by a mentor, catches most problems without slowing makers down.
• Shared standards. Naming conventions, solution structure and approved patterns for approvals, notifications and error handling make solutions easier for anyone to support.
• A feedback loop. When IT blocks a connector or changes a policy, makers hear why. When makers hit a limit, IT hears about it. A monthly conversation between the platform owner and the community is usually enough.

An illustrative first build

Consider a facilities team that tracks equipment requests in a shared spreadsheet and email. This is an illustrative example, not a client project. A maker from the team builds a Microsoft Forms request form, a SharePoint list to store requests, and a Power Automate flow that routes each request for approval and notifies the requester. A simple Copilot Studio agent later answers ‘where is my request?’ questions from the same list. A mentor reviews the design before it moves to the departmental production environment. The facilities manager is named as owner, with the maker as technical lead. The team agrees to measure how long requests take from submission to approval, and how many follow-up emails are needed, before and after launch.

It is small, frequent, visible and low-risk: exactly the kind of first build that gives makers confidence and gives IT evidence that the programme works.

Next step

Explore the current Microsoft Copilot training pathway for leaders, users and agent builders. Compare courses and prices

IGOE AI learning resource · Our guides are independent educational content, not a promise of course inclusions. See the current five-course training offer.