Low-Code Platform Governance: [Platform and organisation name]
Governance design for an enterprise low-code platform: scope and principles, maker personas and
solution tiers, the operating model (centre of excellence, fusion teams, RACI), environment
strategy, data and connector policies, managed environment settings, application lifecycle
management and deployment pipelines, solution intake and promotion gates, AI agent guardrails,
inventory and monitoring, security and compliance, licensing and capacity, maker enablement, the
support model, metrics and the rollout plan. Based on the Microsoft Power Platform governance
guidance on Microsoft Learn (environment strategy, data policies, Managed Environments, pipelines,
Power Platform inventory and Copilot Studio security and governance, pages checked October 2026),
written so that the same structure works for other low-code platforms through the neutral terms
in section 2. Replace every [bracketed] value and every row marked Example.
Document control
| Field | Value |
|---|
| Document ID | [LCG-001] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@platform-owner] |
| Approvers/reviewers | [@ciso], [@enterprise-architect], [@data-protection-officer], [@licensing-manager] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Platform and tenant | [Microsoft Power Platform / other platform], [tenant ID or instance URL] |
| Platform products in scope | [Power Apps, Power Automate, Copilot Studio, Power Pages, Dataverse / equivalents] |
| Geographies and data locations | [Geo 1], [Geo 2] |
| Related documents | [Landing zone design], [IAM solution design], [AI usage policy] |
Approvals
| Role | Name | Decision | Date |
|---|
| Platform owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Information security | [@name] | [Decision] | YYYY-MM-DD |
| Data protection | [@name] | [Decision] | YYYY-MM-DD |
| Enterprise architecture | [@name] | [Decision] | YYYY-MM-DD |
| Licensing and finance | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved; environment routing and tenant data policy live |
| 1.1 | YYYY-MM-DD | [@name] | Example: Added agent governance rules and Tier 3 promotion gate |
Contents
1. Purpose, scope and principles
1.1 Purpose
This document defines how [Organisation] lets employees build apps, automations and agents on
[Platform] while keeping data, cost and support under control. It sets the environments makers
work in, the connectors they may combine, how solutions move to production, who supports them and
how the platform team knows what exists. It is the reference for the platform team, the security
team, solution owners and every maker who wants to take a solution beyond personal use.
1.2 Scope
| In scope | Out of scope |
|---|
| Example: All Power Platform environments in the production tenant, including the default environment | Dynamics 365 application design (see Dynamics 365 Solution Blueprint, architecture/dynamics-365-solution-blueprint) |
| Example: Apps, cloud flows, desktop flows, Copilot Studio agents, Power Pages sites | Microsoft 365 Copilot licensing outside the platform |
| Example: Custom connectors and on-premises data gateways | Pro-code Azure services called by connectors (see Landing Zone Design) |
| [Item] | [Item] |
1.3 Governance principles
| ID | Principle | Consequence |
|---|
| LCG-P-001 (Example) | Make the safe path the easy path | Makers are routed to a governed personal environment automatically; no ticket is needed to start building |
| LCG-P-002 (Example) | Control by environment and policy, not by approving every app | Guardrails attach to environment groups; the platform team reviews only Tier 2 and Tier 3 solutions |
| LCG-P-003 (Example) | The default environment is for personal productivity only | Sharing limits and a restrictive data policy apply there; business solutions move out |
| LCG-P-004 (Example) | Anything shared with more than a team has a named owner and a backup owner | Ownership is checked at promotion and every quarter |
| LCG-P-005 (Example) | Production changes arrive through a pipeline as managed solutions | No direct editing in production environments |
| LCG-P-006 (Example) | AI agents follow the same tiers as apps, plus agent-specific rules | Section 9 adds knowledge, tool and publishing controls |
| [LCG-P-NNN] | [Principle] | [Consequence] |
2. Platform landscape and neutral terms
The rest of this document uses the neutral terms. The Power Platform column records the feature
names checked on Microsoft Learn; for another platform, fill the last column from that vendor's
documentation and record gaps as risks in section 16.
| Neutral term | Meaning | Power Platform term | [Other platform] term |
|---|
| Tenant | The top boundary for identity, policy and licensing | Tenant (Microsoft Entra) | [Term or gap] |
| Environment | Container for apps, flows, agents, data and connections, with its own security roles | Environment (default, production, sandbox, developer, trial) | [Term] |
| Environment group | Set of environments that receive the same rules | Environment groups and rules | [Term] |
| Personal workspace routing | Automatic placement of new makers in their own governed environment | Default environment routing | [Term] |
| Data policy | Rules on which connectors may be used together and which are blocked | Data policies (formerly DLP policies), advanced connector policies | [Term] |
| Premium governance tier | Paid feature set that adds controls and insights to environments | Managed Environments | [Term] |
| Deployment pipeline | Governed promotion of a packaged solution between environments | Pipelines in Power Platform | [Term] |
| Solution package | Versioned unit of deployment | Solution (managed and unmanaged) | [Term] |
| Inventory | Tenant-wide list of apps, flows, agents and connectors in use | Power Platform inventory in the admin center | [Term] |
| Agent | Conversational or autonomous AI component built by makers | Copilot Studio agent | [Term] |
2.1 Products and components in use
| Component | Purpose in this organisation | Owner | Licensing basis |
|---|
| Example: Power Apps | Departmental apps on Dataverse and SharePoint | @platform-owner | Per user for Tier 2 and 3 makers and users |
| Example: Power Automate cloud flows | Approvals and integrations | @platform-owner | Included seeded rights for standard connectors; premium per user or per flow |
| Example: Copilot Studio | Employee help agents | @ai-platform-lead | Capacity-based credits |
| Example: On-premises data gateway | Access to [ERP] database | @integration-lead | Infrastructure cost |
| [Component] | [Purpose] | [@owner] | [Basis] |
3. Personas and operating model
3.1 Maker personas
| Persona | Typical profile | May build | Environment | Training required |
|---|
| Personal maker (Example) | Any employee | Personal productivity apps and flows using Microsoft 365 data | Default or personal developer environment | Welcome content only |
| Citizen developer (Example) | Business analyst or power user | Team solutions on approved connectors | Personal developer, then shared team environment | Maker foundations course and quiz |
| Fusion team member (Example) | Business expert working with a professional developer | Department solutions with custom connectors and Dataverse | Shared development, test, production | Foundations plus ALM course |
| Professional developer (Example) | IT or vendor developer | Components, custom connectors, plug-ins, code apps | Any non-default environment | Platform developer track |
| Environment admin (Example) | Named IT staff per environment | Settings, security roles, capacity | Assigned environments | Admin track |
| [Persona] | [Profile] | [Scope] | [Environment] | [Training] |
3.2 Operating model
The platform is run by a centre of excellence (CoE) that owns the tenant settings, policies,
pipelines and enablement, and by business solution owners who own what their makers build. Fusion
teams combine a business owner, citizen developers and at least one professional developer for
Tier 2 and Tier 3 solutions. The CoE is a small enabling team: it sets guardrails, provides
reusable components and coaches makers; it does not build most solutions.
3.3 RACI
| Activity | CoE platform admin | CoE architect | Security | Solution owner | Maker | Service desk |
|---|
| Tenant settings and data policies | A/R | C | C | I | I | I |
| Environment creation (shared, test, production) | R | C | I | A | C | I |
| Tier 2 and 3 design review | C | A/R | R | R | C | I |
| Promotion to production | R | C | C | A | R | I |
| First-line support for production solutions | I | I | I | A | C | R |
| Quarterly ownership and access review | R | I | C | A | R | I |
| Agent publishing approval | C | R | R | A | R | I |
R responsible, A accountable, C consulted, I informed. One A per row.
4. Environment strategy
4.1 Environment types and their use
Microsoft Learn describes these environment types; record how each is used here.
| Type | Use in this organisation | Who may create | Notes to record |
|---|
| Default | Microsoft 365 personal productivity only | Exists in every tenant | Restrictive data policy and sharing limits (section 6) |
| Developer | One personal workspace per maker, created by routing | Routing policy or eligible makers | Unmanaged developer environments are deprecated: no new ones from 15 November 2026 (the Power Apps Developer Plan sign-up then no longer creates an environment), existing ones suspended from 15 December 2026 and deleted from 15 January 2027; enable Managed Environments on any you keep. Managed developer environments, including the personal ones that routing creates, are unaffected, and each user can then create only one managed developer environment (check the current notice) |
| Sandbox | Shared development, test and user acceptance | CoE only | Supports copy and reset |
| Production | Tier 2 and Tier 3 solutions in live use | CoE only | Managed; longer backup retention available |
| Trial | Short evaluations | Disabled for makers (Example) | Removed automatically after a short period |
| Dataverse for Teams | Legacy only | Not allowed | Deprecated; Microsoft states no new ones can be created from 15 November 2026, and environments not upgraded to Dataverse are suspended on 15 September 2027 and decommissioned on 30 October 2027 (check the current notice) |
4.2 Environment groups and topology
| Group | Purpose | Environments | Security tier | Data policy | Pipeline |
|---|
| ENVG-01 Personal development (Example) | Routed developer environments | One per maker | Normal | DP-02 Personal | PL-01 |
| ENVG-02 Shared development (Example) | Fusion team projects | One per project or department | Medium | DP-03 Business | PL-02 |
| ENVG-03 Test and UAT (Example) | Validation before release | One per production environment | Medium | Same as target production | Target of PL-01 and PL-02 |
| ENVG-04 Production (Example) | Live Tier 2 and Tier 3 solutions | By business area and geography | High | DP-03 Business or DP-04 Regulated | Final stage |
| [ENVG-NN] | [Purpose] | [Environments] | [Tier] | [Policy] | [Pipeline] |
4.3 Environment decisions
| ID | Decision | Reason |
|---|
| ENV-D-001 (Example) | Turn on default environment routing for members of the "Makers" security group, creating environments in ENVG-01 | Moves new work out of the default environment without tickets |
| ENV-D-002 (Example) | Only the CoE creates sandbox and production environments, through an environment request form | Keeps naming, region, capacity and ownership consistent |
| ENV-D-003 (Example) | Environment naming: [geo]-[bu]-[purpose]-[stage], for example eu-fin-expenses-prod | Readable inventory and policy scoping |
| ENV-D-004 (Example) | Each production environment has a security group restricting membership | Prevents every licensed user from seeing environment resources |
| [ENV-D-NNN] | [Decision] | [Reason] |
5. Data policies and connector governance
5.1 Classification model
Classic data policies place each connector in one of three groups: Business, Non-Business or
Blocked. Connectors in different groups cannot be used together in one app, flow or agent;
connectors in the Blocked group cannot be used at all. New connectors land in the default group,
which Microsoft recommends leaving as Non-Business so that a new service is never automatically
allowed to mix with business data. Some core connectors cannot be blocked by classic data policies
(for example Dataverse, Approvals and several Microsoft 365 standard connectors); Microsoft
documents advanced connector policies, an allowlist model, as the way to restrict those. Record
which model you use for each scope.
5.2 Policy register
| ID | Scope | Business group | Non-business group | Blocked | Default group | Custom connector rule |
|---|
| DP-01 Tenant baseline (Example) | All environments | Microsoft 365 standard connectors, Dataverse | Remaining standard connectors | Social media and consumer storage connectors | Non-Business | Ignore at tenant level; environment policies decide |
| DP-02 Personal (Example) | ENVG-01 and default | Microsoft 365 standard connectors | None | All non-Microsoft connectors, HTTP | Non-Business | Deny all URL patterns |
| DP-03 Business (Example) | ENVG-02 to ENVG-04 | Approved line-of-business connectors, approved custom connectors | Weather, RSS | Consumer services | Non-Business | Allow https://api.[org].com/* as Business, deny all others |
| DP-04 Regulated (Example) | Regulated production environments | Dataverse, named internal APIs | None | Everything else that can be blocked | Non-Business | Allow named endpoints only; endpoint filtering on SQL and HTTP |
| [DP-NN] | [Scope] | [Connectors] | [Connectors] | [Connectors] | [Group] | [Rule] |
5.3 Connector request and review
- The maker or fusion team requests a connector or a reclassification through the CoE intake
form, stating the data involved, the solution tier and the business owner.
- Security checks the service's terms, data location, authentication method and whether
connector actions or endpoints should be restricted.
- The CoE runs an impact analysis using the inventory's connector usage view before changing a
policy, because violating resources are suspended and connections disabled when a policy
changes. Microsoft states enforcement usually completes within an hour and can take up to 24
hours; plan changes accordingly.
- The change is applied in a non-production environment group first, then communicated to
affected makers with a date.
| Rule | Value |
|---|
| Custom connectors | Example: Built by professional developers only, stored in solutions, endpoints on the approved host list |
| HTTP connectors | Example: Blocked in DP-01 and DP-02; allowed in ENVG-02 to ENVG-04 only with endpoint filtering. Note that child flows depend on the HTTP connector classification |
| On-premises data gateway | Example: Clustered gateways owned by the integration team; makers request a data source, never install a gateway |
| Connector action control | Example: Block delete actions on the SharePoint and SQL connectors in DP-02 |
6. Managed environment settings and group rules
Managed Environments is a premium set of controls. Microsoft Learn lists, among others, environment
groups, sharing limits, weekly usage insights, data policy visibility, pipelines, maker welcome
content, solution checker enforcement, IP firewall, IP cookie binding, customer-managed keys,
Customer Lockbox, extended backup and default environment routing. Microsoft states that every
environment used in a pipeline, except developer environments and the pipelines host, must be a
managed environment. From October 2026, admins are notified when a
pipeline deploys to an unmanaged target and have 30 days to approve enabling Managed Environments
before deployments are blocked, with one 30-day extension per environment (check the current
notice).
| Control | ENVG-01 Personal | ENVG-02 Shared dev | ENVG-03 Test | ENVG-04 Production |
|---|
| Managed Environments enabled | Yes | Yes | Yes | Yes |
| Sharing limit for canvas apps (Example) | Share with individuals only, maximum 5 | Security groups allowed, maximum 50 | Testers' security group only | Security groups allowed, no limit |
| Solution checker enforcement (Example) | Warn | Warn | Block on critical issues | Block on critical issues |
| Maker welcome content (Example) | Personal workspace rules and links | Fusion team rules | Testing guidance | Production change rules |
| Weekly usage insights recipients | CoE | CoE and solution owners | CoE | CoE and solution owners |
| IP firewall and cookie binding (Example) | Off | Off | On | On |
| Customer-managed key (Example) | No | No | No | Regulated environments only |
| Customer Lockbox (Example) | No | No | No | Yes |
| Extended backup retention (Example) | Not applicable | 7 days | 7 days | 28 days |
| [Control] | [Value] | [Value] | [Value] | [Value] |
7. Application lifecycle management and pipelines
7.1 ALM rules
| ID | Rule |
|---|
| ALM-001 (Example) | Every Tier 2 and Tier 3 asset lives in a named solution with a publisher prefix registered by the CoE |
| ALM-002 (Example) | Only managed solutions are deployed to test and production; unmanaged copies stay in development |
| ALM-003 (Example) | Connection references and environment variables carry all environment-specific values |
| ALM-004 (Example) | Production deployments use delegated deployment with a service principal, so solution objects are not owned by a person |
| ALM-005 (Example) | Tier 3 solutions are also exported to source control by an extended pipeline step |
| ALM-006 (Example) | Solution versions follow major.minor.build.revision; rollback is a redeploy of the previous version where the pipeline setting allows it |
| [ALM-NNN] | [Rule] |
7.2 Pipeline register
| ID | Host | Source group | Stages | Approval before production | Deploying identity |
|---|
| PL-01 (Example) | eu-coe-pipelines-host (production type, not used for development) | ENVG-01 | Test, Production | Solution owner and CoE admin | Service principal sp-pp-deploy-eu |
| PL-02 (Example) | Same host | ENVG-02 | Test, UAT, Production | Solution owner, CoE architect for Tier 3 | Same |
| [PL-NN] | [Host] | [Group] | [Stages] | [Approvers] | [Identity] |
Record the documented limits that affect the design: Microsoft states that pipelines cannot deploy
to another tenant (use Azure DevOps or GitHub for that), that cross-geography deployment needs a
host setting, that a host should not also be a development environment and that pipelines do not
carry Dataverse table data. Move reference data with a separate, reviewed process.
8. Solution tiers, intake and promotion gates
8.1 Tier criteria
| Tier | Criteria (any one moves a solution up) | Environment | Review |
|---|
| Tier 1 Personal or team (Example) | Fewer than 10 users, no confidential data, no premium or custom connectors | Personal developer or default | None; self-attested checklist |
| Tier 2 Department (Example) | 10 to 500 users, or confidential data, or premium connectors, or a business process depends on it | Shared development to production | CoE light review at promotion |
| Tier 3 Business critical (Example) | More than 500 users, or regulated or special-category personal data, or external users, or an outage stops a core process, or an autonomous agent | Shared development to production with UAT | Architecture and security review, support handover |
8.2 Promotion gate checklist
| Check | Tier 1 | Tier 2 | Tier 3 |
|---|
| Named owner and backup owner recorded | Yes | Yes | Yes |
| Solution checker without critical findings | Recommended | Yes | Yes |
| Data classification and data policy fit confirmed | Self | CoE | Security |
| Privacy assessment where personal data is processed | Not applicable | Screening | Full DPIA (compliance/dpia) when required |
| Accessibility check of user interfaces | Recommended | Yes | Yes |
| Error handling and run history monitoring in flows | Recommended | Yes | Yes, with alerts |
| Licences assigned to all users | Yes | Yes | Yes |
| Support model agreed (section 14) | Not applicable | Owner support | Service desk handover |
| Documentation: purpose, data, connectors, owners | One paragraph | Short design note | Solution architecture or HLD (architecture/high-level-design) |
9. AI and agent governance
Microsoft Learn lists data policy controls for Copilot Studio agents covering maker and user
authentication, knowledge sources, actions and connectors, HTTP requests, publication to channels,
Application Insights, and triggers for autonomous agents, plus a tenant setting to stop publishing
of agents that use generative AI features, audit logs in Microsoft Purview, a security scan before
publishing, credit caps, and Microsoft Agent 365 as a central control plane for agent identities.
Map each to a rule; for other platforms, find the equivalent or record a gap.
| ID | Rule | Applies to | Enforcement |
|---|
| AGT-001 (Example) | Agents in ENVG-01 may use only Microsoft 365 knowledge the maker can already access and may not be published beyond the maker | Personal agents | Data policy DP-02 blocks channels other than test |
| AGT-002 (Example) | Agents published to all employees require authentication with the corporate identity provider | Tier 2 and 3 agents | Data policy blocks "no authentication" option |
| AGT-003 (Example) | Public website knowledge sources are blocked unless the CoE approves the domain | All | Data policy on knowledge sources |
| AGT-004 (Example) | Autonomous triggers allowed only for Tier 3 agents with a human approval step for write actions | Tier 3 | Data policy on triggers; design review |
| AGT-005 (Example) | Tool calls run with the user's credentials unless a reviewed service account is justified | All | Design review |
| AGT-006 (Example) | Every published agent has an owner, a purpose statement and an entry in the AI register (ai-data/ai-use-case-intake) | Tier 2 and 3 | Promotion gate |
| AGT-007 (Example) | Monthly credit cap per environment, with alerts at 80 percent | Production group | Admin center capacity settings |
| [AGT-NNN] | [Rule] | [Scope] | [Enforcement] |
Connect this section to the AI Usage Policy (ai-data/ai-usage-policy), the Agent Tool
Permission Design (ai-data/agent-tool-permission-design) and, for agents with significant
autonomy, the Agentic Threat Model (ai-data/agentic-threat-model).
10. Inventory, monitoring and resource lifecycle
10.1 Sources of truth
| Source | Content | Use |
|---|
| Admin center inventory | Agents, apps, flows, connectors (preview), environments and groups across the tenant, updated within about 15 minutes according to Microsoft, exportable to CSV and queryable by API | Primary inventory, orphan detection, connector impact analysis |
| Weekly usage insights | Active and inactive resources per managed environment | Clean-up campaigns |
| Microsoft Purview audit log | Maker and admin activity, agent activity | Investigations and evidence |
| CoE Starter Kit | Microsoft Learn states the kit is no longer actively maintained and its core capabilities are part of the admin center | Example: Not adopted; existing kit components retired by [date] |
| [Source] | [Content] | [Use] |
10.2 Lifecycle rules
| ID | Trigger | Action | Owner |
|---|
| LIF-001 (Example) | Owner leaves the organisation | Transfer to backup owner within 10 working days; block published apps or agents if no owner is found | CoE admin |
| LIF-002 (Example) | No use for 90 days | Notify owner; delete after 30 more days without response, Tier 1 only | CoE admin |
| LIF-003 (Example) | Resource in a non-approved region | Move or delete within 30 days | Solution owner |
| LIF-004 (Example) | Security finding on a published agent or app | Block from the inventory, investigate, unblock after fix | Security |
| [LIF-NNN] | [Trigger] | [Action] | [Owner] |
11. Security, identity and compliance
| Area | Decision |
|---|
| Identity | Example: All access through Microsoft Entra ID; conditional access requires a compliant device for production environments |
| Admin roles | Example: Power Platform administrator role assigned just in time through privileged identity management; no standing global admins |
| Environment access | Example: Security group per environment; Dataverse security roles assigned to teams, not individuals |
| Service accounts | Example: Service principals for deployment and integration; credentials in the corporate secret store, rotated every 12 months |
| Logging | Example: Purview audit and admin activity exported to the SIEM; alerts on data policy changes and tenant setting changes |
| Data residency | Example: Environments created only in approved geographies; cross-geo AI data movement disabled |
| Regulatory | Example: Regulated environments follow DP-04, customer-managed keys and Lockbox; records retention per the records schedule |
| External users | Example: Power Pages sites are Tier 3; authentication and web application firewall reviewed by security |
Reference the IAM Solution Design (security/iam-solution-design) and the Security Architecture
(security/security-architecture) for controls that are not specific to the platform.
12. Licensing and capacity
| Topic | Decision |
|---|
| Maker licences | Example: Developer plan for learning only, in the maker's routed managed developer environment; premium per-user licence for Tier 2 and 3 makers |
| User licences | Example: Premium per-user or per-app licences assigned by the solution owner's cost centre before promotion |
| Managed Environments | Microsoft states Managed Environments are an entitlement of standalone Power Apps, Power Automate, Copilot Studio, Power Pages and Dynamics 365 licences, and not of the Developer Plan when running assets (the Power Apps Developer Plan no longer creates developer environments from 15 November 2026); confirm against your agreement |
| Dataverse capacity | Example: Database and file capacity allocated per environment; alert at 80 percent; charge-back quarterly |
| Agent capacity | Example: Credits pooled at tenant level, capped per production environment (AGT-007) |
| Charge-back | Example: Platform cost split by number of active Tier 2 and 3 users per business unit |
Check current licensing terms in the vendor's licensing guide; this table records decisions, not
licensing facts. Use the Software Licence Review (compliance/software-licence-review) for the
annual true-up.
13. Maker enablement and community
| Item | Design |
|---|
| Onboarding | Example: Maker welcome content in every managed environment group, linking to the rules for that group |
| Training paths | Example: Foundations (2 hours), Fusion team ALM (half day), Agent builder (half day), Admin track |
| Reusable assets | Example: Component library, approved custom connectors, solution templates with logging and error handling built in |
| Community | Example: Monthly maker call, internal forum, champions in each business unit identified from the inventory |
| Office hours | Example: Twice weekly, staffed by the CoE architect and a senior maker |
| Recognition | Example: Quarterly showcase of solutions with measured benefits |
14. Support model
| Tier | First line | Second line | Third line | Response target (Example) |
|---|
| Tier 1 | Maker community forum | Not provided | Not provided | Best effort |
| Tier 2 | Solution owner's team | CoE office hours | Vendor support through CoE | Next working day |
| Tier 3 | Service desk with runbook | Fusion team on rota | CoE and vendor support | 4 business hours for priority 2 |
Tier 3 solutions are handed over with a runbook, known errors, monitoring and contacts; use the
Operations Handover (ops/operations-handover) for the content. Platform incidents (outage of a
region, connector failures) are handled by the CoE and communicated through the service status page.
15. Metrics and review cadence
| ID | Metric | Target (Example) | Source | Review |
|---|
| MET-001 | Share of new resources created outside the default environment | Above 90 percent within 6 months | Inventory | Monthly |
| MET-002 | Tier 2 and 3 resources with a valid owner and backup owner | 100 percent | Inventory, owner register | Quarterly |
| MET-003 | Production deployments through pipelines | 100 percent | Pipeline run history | Monthly |
| MET-004 | Data policy violations detected after a policy change | Trend down | Admin center | Per change |
| MET-005 | Median time from intake to production for Tier 2 | Under 15 working days | Intake log | Quarterly |
| MET-006 | Active makers and active users per month | Rising | Usage insights | Monthly |
| MET-007 | Published agents with completed AI register entry | 100 percent | AI register, inventory | Monthly |
The steering board reviews the metrics quarterly and this document at least once a year.
16. Rollout plan and risks
16.1 Rollout
| Phase | Scope | Exit criteria |
|---|
| 1 Assess (Example) | Inventory export, default environment analysis, connector usage | Baseline metrics recorded; list of solutions to move |
| 2 Foundations (Example) | Environment groups, routing, DP-01 baseline, pipelines host | Routing live for pilot makers; no business impact from DP-01 |
| 3 Migrate (Example) | Move Tier 2 and 3 solutions out of the default environment | Default environment holds personal productivity only |
| 4 Optimise (Example) | Agent rules, charge-back, advanced connector policies | Metrics MET-001 to MET-007 at target |
16.2 Risks
| ID | Risk | Likelihood | Impact | Mitigation | Owner |
|---|
| LCG-R-001 (Example) | Policy change suspends business-critical flows | Medium | High | Impact analysis from inventory; staged rollout; communication 2 weeks ahead | @platform-owner |
| LCG-R-002 (Example) | Vendor deprecations catch solutions unprepared (unmanaged developer environments suspended from 15 December 2026; Dataverse for Teams environments suspended on 15 September 2027) | High | Medium | Track the vendor's important changes page monthly; enable Managed Environments or move solutions before each date; migration backlog | @coe-architect |
| LCG-R-003 (Example) | Shadow automation in unmanaged tools if rules feel too strict | Medium | High | Fast intake, personal workspaces, office hours | @coe-lead |
| [LCG-R-NNN] | [Risk] | [L] | [I] | [Mitigation] | [@owner] |
17. Glossary and references
17.1 Glossary
| Term | Meaning |
|---|
| Centre of excellence (CoE) | Team that governs and enables the platform |
| Fusion team | Business experts and professional developers building a solution together |
| Maker | Anyone who builds apps, flows or agents on the platform |
| Data policy | Rule set that classifies connectors and controls which may be combined or used |
| Managed solution | Locked, versioned package deployed to non-development environments |
| Environment routing | Automatic placement of makers in their own governed environment |
| Orphaned resource | App, flow or agent whose owner has left or is unknown |
17.2 References
| Reference | Version or date checked | Use |
|---|
| Microsoft Learn, Develop a tenant environment strategy to adopt Power Platform at scale | Page dated 2026-10-17 | Sections 4 and 6 |
| Microsoft Learn, Data policies and Connector classification | Pages dated 2026-10-14 and 2026-04-07 | Section 5 |
| Microsoft Learn, Managed environments overview | Page dated 2026-10-08 | Section 6 |
| Microsoft Learn, Overview of pipelines in Power Platform | Page dated 2026-09-29 | Section 7 |
| Microsoft Learn, Power Platform inventory | Page dated 2026-09-28 | Section 10 |
| Microsoft Learn, Copilot Studio security and governance | Page dated 2026-09-24 | Section 9 |
| Microsoft Learn, CoE Starter Kit overview (maintenance notice) | Page dated 2026-04-21 | Section 10 |
| Microsoft Learn, Important changes (deprecations) in Power Platform | Page dated 2026-10-06, updated 2026-10-22 | Developer and Dataverse for Teams timelines in section 4.1 |
| Microsoft Learn, Microsoft Agent 365 overview | Generally available since 1 May 2026, checked 2026-10-23 | Section 9 |
| [Other platform documentation] | [Date] | [Use] |
Standard and licence note
Based on the Microsoft Power Platform governance and administration guidance published on
Microsoft Learn (environment strategy, data policies, Managed Environments, pipelines, Power
Platform inventory, Copilot Studio security and governance), checked in October 2026. Feature
names are used for mapping only; no documentation text is reproduced, and all wording, tiers,
rules and examples are original. Features, limits and licensing change often: check the current
official documentation and your licence agreement before use. Microsoft, Power Platform, Power
Apps, Power Automate, Copilot Studio, Dataverse and Microsoft Agent 365 are trademarks of their owners; this template is
not affiliated with or endorsed by them. Template licence: MIT.