DEV Community: Alex Pechenizkiy

Power Automate Naming Conventions That Scale

Alex Pechenizkiy — Mon, 21 Sep 2026 18:59:46 +0000

Open the Power Platform Admin Center. Navigate to your production environment. Click into the flow list. What do you see?

"My Flow." "Test - Copy." "John's Approval Flow (2)." "Untitled." Fourteen flows named "When an item is created."

This is the reality of most Power Automate tenants. And it's not a minor inconvenience. When something breaks at 2 AM, you need to find the right flow in seconds. When a maker leaves the organization, someone else needs to understand what each flow does. When you run an inventory across 300 flows, naming is the difference between actionable data and noise.

Naming conventions are the cheapest governance control you can implement. No licenses required. No premium features. Just discipline and a standard that everyone follows.

TL;DR

Use a four-segment naming pattern for every Power Automate flow: Domain-Entity-Action-Trigger. Apply the same discipline to connection references and environment variables. This single standard makes flow inventories searchable, troubleshooting faster, and governance automatable.

The Naming Pattern

Every cloud flow name should follow this structure:

{Domain}-{Entity}-{Action}-{Trigger}

Four segments, hyphen-separated, no spaces. Each segment serves a specific purpose.

Domain Codes

The domain identifies which business area owns the flow. Use short, uppercase codes:

Code	Domain	Examples
HR	Human Resources	Onboarding, evaluations, leave requests
FIN	Finance	Invoices, expenses, budget approvals
SALES	Sales	Leads, opportunities, quotes
IT	Information Technology	Provisioning, tickets, access requests
OPS	Operations	Work orders, scheduling, logistics
MKT	Marketing	Campaigns, events, content approvals
PROC	Procurement	Purchase orders, vendor management
SEC	Security	Access reviews, compliance checks

If your organization has specific departments that don't fit these codes, create your own. The key is consistency. Pick a list, publish it, and enforce it.

Entity

The entity is what the flow operates on. Use the business object name, not the Dataverse table name. "Evaluation" not "cr4b2_evaluation." "Invoice" not "salesinvoice." Keep it readable by a business user.

Action

The action describes what the flow does. Common actions:

Create - creates a record or resource
Notify - sends a notification (email, Teams, push)
Sync - synchronizes data between systems
Approve - routes through an approval process
Archive - moves or flags records for archival
Validate - checks data against business rules
Calculate - computes values (totals, scores, dates)
Export - generates files or reports

Trigger

The trigger tells you what starts the flow. This is critical for troubleshooting. If you know a flow fires on record creation and the issue started after someone bulk-imported records, you have your answer.

Common trigger suffixes:

OnCreate - when a record is created
OnUpdate - when a record is modified
OnStatusChange - when a status field changes
Scheduled - runs on a timer (daily, weekly, hourly)
Manual - triggered by a button or user action
OnEmail - triggered by an incoming email
OnApproval - triggered by an approval response

Real Examples

Here's what good naming looks like in practice:

Bad Name	Good Name	Why It's Better
Send notification	HR-Evaluation-SubmitNotification-OnStatusChange	You know the domain, what it acts on, what it does, and what triggers it
Invoice approval	FIN-Invoice-ApprovalRequest-OnCreate	Distinguishes from the 4 other invoice flows in the environment
Sync contacts	SALES-Contact-SyncToCRM-Scheduled	Clear that it's a scheduled sync, not a real-time trigger
My Flow (2)	IT-AccessRequest-Provision-OnApproval	Self-documenting. No guessing required.
Weekly report	MKT-Campaign-ExportMetrics-Scheduled	Tells you exactly which report and when it runs
Untitled	PROC-PurchaseOrder-Validate-OnCreate	The flow name IS the documentation

When you have 50 flows in an environment, these names let you filter by domain, sort alphabetically, and find exactly what you need. When you have 200 flows, this naming convention is the only thing standing between you and chaos.

Connection Reference Naming

Connection references are the mechanism that lets you deploy solutions across environments without hardcoding credentials. They get their own naming convention:

{publisher}_{connector}_{purpose}

All lowercase, underscores as separators.

Bad Name	Good Name	Why
SharePoint Connection	contoso_sharepointonline_hrdocuments	Specifies which SharePoint connection for what purpose
Outlook	contoso_office365outlook_notifications	Distinguishes from the Outlook connection used for approvals
Dataverse	contoso_dataverse_hrsystem	When you have 3 Dataverse connections for different solutions, this matters
My SQL Connection	contoso_sql_financereporting	Identifies the target system and purpose

Why does the publisher prefix matter? Because when you import a managed solution, the connection references show up in the target environment. If two different ISVs both have a connection reference called "SharePoint," you have a collision. The publisher prefix prevents that.

Environment Variable Naming

Environment variables store configuration values that change between environments. URLs, email addresses, feature flags, thresholds. Same idea:

{publisher}_{Domain}_{VariableName}

Examples:

contoso_HR_NotificationMailbox - the email address that receives HR notifications
contoso_FIN_ApprovalThreshold - the dollar amount that triggers executive approval
contoso_IT_ServiceNowBaseUrl - the ServiceNow instance URL for the IT integration
contoso_SALES_LeadScoringEnabled - feature flag for the lead scoring flow

Building Power Platform governance?

This naming standard is one piece of a complete governance framework. For more patterns on environment strategy, solution awareness, and flow inventory, follow Alex on LinkedIn where I share practical Power Platform architecture posts every week.

Use consistent naming across all three

When your flow is named HR-Evaluation-SubmitNotification-OnStatusChange, its connection reference is contoso_office365outlook_hrnotifications, and its environment variable is contoso_HR_NotificationMailbox, an admin can trace the entire chain without opening anything. The naming convention IS the documentation.

Flow Description Template

The flow name tells you what. The description tells you why and how. Every flow should have a description that follows this template:

Purpose: [One sentence explaining the business reason]
Owner: [Team or role, not a person's name]
Dependencies: [External systems, other flows, specific data]
SLA: [Expected run time and any time-sensitive requirements]
Last reviewed: [Date of last review]

Example:

Purpose: Sends email notification to the evaluation manager when
an employee submits their self-evaluation for review.
Owner: HR Operations Team
Dependencies: Office 365 Outlook connector, Evaluation table,
contoso_HR_NotificationMailbox environment variable
SLA: Must complete within 5 minutes of status change
Last reviewed: 2026-03-01

This takes 30 seconds to write. It saves hours when someone is troubleshooting at 11 PM.

Enforcement

A naming convention that nobody follows is just a document. Here's how you actually enforce it.

Publish the standard Write it down. Put it in your governance wiki, your CoE documentation, your maker onboarding materials. Make it findable.
Add it to your maker welcome content Managed Environments let you configure a welcome message for makers. Include a link to the naming standard. Every maker sees it when they open the environment.
Build a compliance check flow Use the Power Automate Management connector or PowerShell (Get-AdminFlow) to pull all flow names. Run a regex against the naming pattern. Flag violations.
Use the CoE Starter Kit The Center of Excellence Starter Kit includes inventory flows that sync all flows to Dataverse. Build a model-driven app or Power BI report that highlights flows not matching the pattern.
Review in your governance cadence Monthly or quarterly, review the compliance report. Reach out to makers with non-compliant flows. Rename or ask them to rename. This is a conversation, not a punishment.

Don't block flow creation

Some admins want to prevent flows from being saved unless the name matches a pattern. Power Platform doesn't support this natively, and custom enforcement that blocks makers will kill adoption. Use detection and coaching, not blocking.

The Regex Pattern

If you want to validate flow names programmatically, here's a regex pattern that matches the convention:

^[A-Z]{2,5}-[A-Za-z]+-[A-Za-z]+-(?:OnCreate|OnUpdate|OnStatusChange|Scheduled|Manual|OnEmail|OnApproval)$

This matches:

2-5 uppercase letters for the domain
One or more letters for the entity
One or more letters for the action
A known trigger suffix

You can expand the trigger list as needed. The point is that the check is automatable.

How Do You Name Child Flows and Desktop Flows?

Child flows and desktop flows follow the same four-segment naming convention with one addition. Child flows append a _Child suffix so you can instantly distinguish them in an inventory. Desktop flows replace the trigger segment with Desktop, making it clear which runtime executes them. Both approaches keep your naming consistent across flow types.

Child flows (flows called by other flows) follow the same convention but add a _Child suffix:

HR-Evaluation-SendEmail-OnCreate_Child

Desktop flows use a similar pattern but replace the trigger segment with Desktop:

FIN-Invoice-ExtractLineItems-Desktop

This makes it immediately obvious in an inventory which flows are cloud flows, which are child flows, and which are desktop flows.

Start Today

You don't need to rename every flow in your tenant on day one. Start with new flows. Apply the standard going forward. Then work through the backlog in batches, prioritizing production environments and business-critical flows.

The naming convention is the foundation for everything else in this series. Environment strategy, solution awareness, and flow inventory all become dramatically easier when every flow has a name that tells you exactly what it is.

Power Automate Governance - The Enterprise Playbook

This article is part of a 10-part series:

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.

This article was originally published at az365.ai. I'm Alex Pechenizkiy, an Azure and Power Platform solutions architect writing honest, vendor-neutral analysis of the Microsoft AI stack. More at az365.ai.

Power Automate Environment Strategy - Dev Test Prod Done Right

Alex Pechenizkiy — Sun, 20 Sep 2026 17:12:19 +0000

Open the Power Platform Admin Center. Click on Environments. If you see one environment where every Power Automate flow runs - the default - this article is for you.

The default environment is the single biggest governance liability in Power Platform. Every licensed user in your tenant gets the Environment Maker role in the default environment. Every user can create flows, apps, and connections there. Every user's work sits next to every other user's work. There are no guardrails, no separation, and no way to promote tested work to production because there's only one environment. Everything is production.

This is how most organizations run Power Automate. And it works until it doesn't. Until someone's test flow sends 10,000 emails to real customers. Until a maker's experimental flow consumes all the API capacity. Until you need to roll back a change and realize there's nothing to roll back to because there's no dev/test/prod separation.

TL;DR

Every Power Automate workload needs at least three environments: dev, test, and production. Use developer environments for maker sandboxes, environment routing to keep the default environment clean, and Managed Environments for governance controls.

The 3-Environment Minimum

At minimum, you need three environments for any workload that matters:

Environment	Purpose	Who Has Access	Data
Development	Build and iterate on flows	Makers and developers	Sample/test data only
Test (UAT)	Validate before production	Makers, testers, business stakeholders	Production-like data (anonymized if needed)
Production	Live business processes	End users via apps, flows run automatically	Real business data

This isn't new. Software development has followed dev/test/prod for decades. Power Platform is software development. The fact that citizen developers build flows doesn't change the fundamental need for environment separation.

Solutions move from Dev to Test to Prod through managed solution exports and imports. Connection references and environment variables handle the configuration differences between environments. This is Application Lifecycle Management (ALM), and it's the only way to reliably deploy Power Automate flows at scale.

Developer Environments

Developer environments solve a specific problem: makers need a place to experiment without polluting shared environments. In the past, organizations either gave makers access to the default environment (too risky) or created shared dev environments (still messy).

Developer environments are personal sandboxes. Key facts from Microsoft's current documentation:

Each user can create up to 3 developer environments through the Power Platform admin center
They include Dataverse at no additional storage cost to the tenant
Capacity: 2 GB database, 750 flow runs per month
They are meant for development and testing, not production use
Auto-cleanup: disabled after 30 days of inactivity, then deleted 15 days later if not re-enabled
The Developer Plan license is free and gives access to premium connectors for dev/test purposes

Developer environments are not trial environments

Trial environments expire after 30 days. Developer environments persist as long as there's activity. They're cleaned up only when inactive. Different mechanism, different purpose.

Default Environment Routing

Here's the governance feature that ties it together. Environment routing automatically redirects makers away from the default environment and into their own personal developer environments.

When enabled, a maker who navigates to make.powerapps.com or make.powerautomate.com lands in their own developer environment instead of the default. If they don't have a developer environment yet, one's created automatically.

Open Power Platform admin center Navigate to admin.powerplatform.microsoft.com. You need Power Platform admin privileges.
Go to Manage > Tenant settings > Environment routing Find the Environment routing setting under Tenant settings. It's off by default.
Select the product portals Choose which portals trigger routing: Power Apps, Power Automate, Copilot Studio. Enable all three for full coverage.
Create a new routing rule Select New rule. Give it a name. Choose whether to route Everyone or a specific security group.
Assign an environment group Select the environment group that new developer environments will be automatically placed into. This ensures group-level governance rules apply immediately.
Save and test Save the rule. Have a test user navigate to make.powerautomate.com. They should land in their developer environment, not the default.

The developer environments created by routing are Managed Environments by default. This means they inherit the preconfigured settings:

Sharing limits: excludes sharing with security groups, limited to 5 individuals
Solution Checker: set to Warn
Usage insights: enabled

Premium license requirement

A premium license isn't required to create or preview resources in a managed developer environment. But users need a premium license to run resources there. The Developer Plan covers creation and testing. Running in production requires a paid license.

What Do Managed Environments Actually Add?

Managed Environments give admins sharing limits, solution checker enforcement, usage insights, maker welcome content, and environment-level data policies. They layer governance controls on top of any existing environment without changing how makers build. The tradeoff is that users who run resources in a Managed Environment need premium licensing.

Managed Environments are not a separate environment type. They're a set of capabilities you enable on an existing environment.

What Managed Environments add:

Capability	Without Managed Environments	With Managed Environments
Sharing limits	Anyone can share with anyone	Admins control sharing limits per environment
Solution Checker enforcement	Optional, maker's choice	Enforced at environment level (None, Warn, or Block)
Usage insights	Limited to admin center analytics	Richer usage data in the admin center
Maker welcome content	None	Custom welcome message with links to governance docs
Data policies	Tenant-level DLP only	Environment-level DLP enforcement
Backup and restore	Standard	Enhanced with longer retention

Managed Environments require premium licensing for users who run resources. This is the tradeoff. You get governance controls, but you need to plan your licensing accordingly.

Environment Groups

Environment groups let you organize environments and enforce rules at the group level. Instead of configuring sharing limits, solution checker, and other settings on each environment individually, you configure them once on the group and every environment in that group inherits the rules.

This matters when you have 10, 20, or 50 environments. Configuring each one manually doesn't scale. Environment groups make it manageable.

The recommended pattern:

Environment Group	Contains	Rules
Developer environments	All maker developer environments (auto-populated by routing)	Sharing limited to 5 users, solution checker warns, usage insights on
Shared development	Team dev environments for formal projects	Sharing limited to security groups, solution checker warns
Test / UAT	Test environments for each project	Sharing limited, solution checker blocks on errors
Production	Live environments	Strict sharing limits, solution checker blocks, full audit logging

When environment routing creates a new developer environment, it can automatically place it in the Developer environments group. The maker gets a governed environment from day one without any admin intervention.

Building Power Platform governance?

Environment strategy is one layer of a complete governance framework. For more on naming conventions, solution awareness, and automated compliance, follow Alex on LinkedIn for weekly Power Platform architecture posts.

Connection References and Environment Variables

These are the bridge between environments. Without them, you can't move flows from dev to test to prod.

Connection references abstract the authentication. In dev, the connection reference points to your dev SharePoint site. In test, it points to the test site. In prod, the production site. The flow itself is identical across all three environments. Only the connection reference value changes.

Environment variables store configuration that differs per environment. Email addresses, URLs, thresholds, feature flags. The flow references the variable, not the value. When you import the solution into a new environment, you set the variable values for that environment.

Example of the same flow across three environments:

Component	Dev	Test	Prod
Flow name	HR-Evaluation-Notify-OnStatusChange	Same	Same
Connection ref: contoso_outlook_hr	dev.maker@contoso.com	test.serviceaccount@contoso.com	prod.serviceaccount@contoso.com
Env var: contoso_HR_NotificationMailbox	alex@contoso.com (dev testing)	hr-test@contoso.com	hr-notifications@contoso.com
Env var: contoso_HR_ApprovalThreshold	0 (approve everything for testing)	1000	5000

The flow logic never changes between environments. Only the configuration changes. This is what makes ALM possible.

Name them consistently

Use the naming conventions from the first article in this series. When your flow is HR-Evaluation-Notify-OnStatusChange, your connection reference is contoso_outlook_hrnotifications, and your environment variable is contoso_HR_NotificationMailbox, the entire chain is traceable by name alone.

The Full Picture

Putting it all together:

Makers start in their own developer environment (created by environment routing)
They build flows inside solutions using connection references and environment variables
When ready, they export the solution and import it into a shared test environment
Business stakeholders validate in test
The solution is promoted to production as a managed solution
Each environment is in an environment group with appropriate governance rules
The default environment is locked down. No new flows are built there.

This isn't aspirational. This is the environment strategy that Microsoft recommends and that the platform supports today. The tooling exists. The licensing model supports it. The only thing missing in most organizations is the decision to implement it.

Start with What You Have

If you're running everything in the default environment today, here's the pragmatic path forward:

Create a production environment Provision a new environment with Dataverse. This becomes your target for business-critical flows.
Create a dev environment Provision a development environment. This is where makers build new flows going forward.
Enable environment routing Route new makers to developer environments. This prevents new flows from landing in the default.
Migrate critical flows Move your most important flows into solutions in the dev environment. Deploy to production through managed solutions.
Enable Managed Environments on production Turn on Managed Environments for your production environment. Configure sharing limits and solution checker enforcement.
Gradually migrate the rest Work through the remaining flows in the default environment over weeks or months. Not everything needs to move at once.

The goal isn't to migrate everything overnight. The goal is to stop making the problem worse (new flows in the default environment) while gradually fixing the existing state.

Power Automate Governance - The Enterprise Playbook

This article is part of a 10-part series:

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.

Power Automate Flow Inventory - You Can't Govern What You Can't See

Alex Pechenizkiy — Sat, 19 Sep 2026 16:57:43 +0000

Ask any IT leader how many Power Automate flows run in their tenant. The answer is almost always a guess. "Maybe 20 or 30." "A handful." "Not many."

Then you run an actual Power Automate flow inventory. The real number is often 300, 800, or 2,000. A meaningful fraction are typically owned by people who no longer work at the company. Some haven't run successfully in months. Others connect to external services that IT never approved. Several may be sending data to personal OneDrive accounts. The CoE Starter Kit's Maker dashboard documentation describes exactly this orphan-and-unsanctioned-flow pattern as the typical reason organizations install it in the first place.

TL;DR

Most organizations drastically underestimate how many Power Automate flows exist in their tenant. Use PowerShell, admin connectors, or the CoE Starter Kit to build a complete flow inventory. Classify every flow by criticality, fix orphans, and set up continuous sync so the inventory stays current.

This isn't hypothetical. This is what happens in every organization where Power Platform adoption grew organically without governance. Users discover Power Automate, solve their own problems, and move on. Nobody tracks what was built. Nobody reviews what's running. Nobody knows what happens when those flows break.

You can't govern what you can't see. The inventory is step one.

Why Do You Need a Power Automate Flow Inventory?

Without a flow inventory, you cannot identify orphaned flows, enforce naming conventions, audit connector usage, or verify license compliance. A flow inventory gives administrators a single source of truth for every automation in the tenant, enabling informed governance decisions instead of guesswork.

Discovery Methods

There are four ways to discover flows in your tenant, from simplest to most comprehensive.

Method	Effort	Scope	Automation	Best For
Power Platform Admin Center	Low	Per environment	Manual	Quick spot checks, small tenants
PowerShell cmdlets	Medium	Per environment or all environments	Scriptable	Bulk export, one-time audits
Admin connectors in Power Automate	Medium	All environments	Fully automated	Ongoing monitoring, custom reporting
CoE Starter Kit Core module	High (initial setup)	All environments	Fully automated, continuous sync	Enterprise-scale governance

1. Power Platform Admin Center

The simplest approach. Navigate to admin.powerplatform.microsoft.com, select an environment, go to Resources, and click Flows. You get a list of all cloud flows in that environment with owner, status, and creation date.

Limitations: you can only view one environment at a time. Filtering is basic. There's no export button for custom analysis. For a tenant with 3 environments, this is manageable. For a tenant with 30 environments, it's not practical.

Best for: quick spot checks and small organizations.

2. PowerShell Cmdlets

The Get-AdminFlow cmdlet from the Microsoft.PowerApps.Administration.PowerShell module returns detailed information about flows. You can script it to loop through all environments and export the results.

# Install the module
Install-Module -Name Microsoft.PowerApps.Administration.PowerShell

# Get all flows across all environments
$environments = Get-AdminPowerAppEnvironment
$allFlows = @()

foreach ($env in $environments) {
    $flows = Get-AdminFlow -EnvironmentName $env.EnvironmentName
    foreach ($flow in $flows) {
        $allFlows += [PSCustomObject]@{
            FlowName       = $flow.DisplayName
            FlowId         = $flow.FlowName
            Environment    = $env.DisplayName
            CreatedBy      = $flow.CreatedBy.userId
            CreatedTime    = $flow.CreatedTime
            LastModified   = $flow.LastModifiedTime
            State          = $flow.Enabled
        }
    }
}

$allFlows | Export-Csv -Path "FlowInventory.csv" -NoTypeInformation

PowerShell returns the most up-to-date data because it queries the platform APIs directly. Get-AdminFlow returns all cloud flows in an environment. You get flow name, ID, creator, creation date, last modified date, and enabled/disabled state.

Best for: one-time audits, scripted bulk operations, and organizations comfortable with PowerShell.

3. Admin Connectors

Power Platform provides admin connectors that you can use inside Power Automate flows themselves. This means you can build a flow that inventories all other flows. Recursive? Yes. Useful? Extremely.

The relevant connectors:

Power Automate Management - list flows, get flow details, list flow runs
Power Automate for Admins (Microsoft Flow for Admins) - disable flows, delete flows, administrative actions
Power Platform for Admins - environment operations, DLP policies

You build a scheduled flow that runs daily or weekly, calls the admin connector to list all flows across environments, and writes the results to a Dataverse table or SharePoint list. This gives you a continuously updated inventory without manual effort.

Best for: ongoing monitoring with custom logic. You can add classification rules, anomaly detection, and alerting directly in the flow.

4. CoE Starter Kit Core Module

The Center of Excellence Starter Kit is Microsoft's reference implementation for Power Platform governance. The Core module includes inventory flows that automatically sync all apps, flows, connectors, and environments to Dataverse tables.

The inventory flows run on a driver/sync pattern:

Admin | Sync Template v4 (Driver) - orchestrates the sync process
Admin | Sync Template v3 (Flows) - gets cloud flow information using the Power Automate Management connector
Admin | Sync Template v3 (Flow Action Details) - (optional) gets the actions and triggers for every flow

The CoE Starter Kit stores inventory in Dataverse and includes Power BI dashboards for visualization. It handles the heavy lifting of discovery, deduplication, and incremental sync. The inventory flows only update objects modified since the last sync, reducing API consumption.

CoE Starter Kit sizing

The CoE Starter Kit using cloud flows for inventory is suitable for small to medium tenants. For tenants where Power Platform inventory exceeds 10,000 objects (combined environments, apps, flows), Microsoft recommends the data export integration, which is currently in experimental preview.

Best for: enterprise-scale governance. If you're serious about Power Platform governance, the CoE Starter Kit is the starting point. You'll likely customize it, but it provides the foundation.

What to Capture Per Flow

Running a discovery query is step one. Making the data useful is step two. Here is what you should capture for every flow in your inventory:

Data Point	Where to Get It	Why It Matters
Flow display name	Get-AdminFlow / Admin connector	Naming convention compliance check
Flow ID	Get-AdminFlow	Unique identifier for programmatic management
Owner (user or service principal)	Get-AdminFlow / flow details	Orphan detection, license compliance
Environment	Environment enumeration	Which environment the flow lives in
Trigger type	Flow definition / Flow Action Details	Understanding what starts the flow
Connectors used	Flow Action Details (CoE)	Connector audit, DLP compliance
Last successful run date	Flow run history	Detecting abandoned flows
Flow status (enabled/disabled)	Get-AdminFlow	Finding flows that silently stopped
Solution membership	Solution component query	Identifying loose flows vs solution-aware
Created date	Get-AdminFlow	Age analysis, finding legacy flows
Description	Flow details	Documentation compliance check

Classification Framework

Raw inventory data is overwhelming. A flat list of 500 flows isn't actionable. Classification turns data into decisions.

Classification	Criteria	Governance Level	Examples
Business-critical	Supports a core business process. Failure impacts revenue, compliance, or operations.	Highest. Service principal ownership, managed solution, monitored 24/7.	Invoice approval, regulatory reporting, customer onboarding
Team productivity	Department-level workflow. Failure impacts a team's efficiency but not the whole organization.	Medium. Solution-aware, named correctly, owner tracked.	Leave request approvals, team status reports, document routing
Personal	Individual automation. One person uses it for their own work.	Low. Track in inventory, ensure no PII exposure.	Email sorting rules, personal task reminders, calendar sync
Experimental	Testing, learning, proof of concept. Not intended for ongoing use.	Minimal. Track, auto-disable if inactive for 60 days.	Hackathon projects, training exercises, connector testing

Classification should be a field in your inventory, not a separate spreadsheet. If you use the CoE Starter Kit, add a custom column to the flow inventory table. If you use a SharePoint list, add a choice column. The classification drives the governance response.

The Orphan Problem

An orphaned flow is a flow whose owner no longer has a valid account. The owner left the organization, their account was disabled, and the flow keeps running. Or tries to. Usually it starts failing because the connections tied to the owner's account no longer authenticate.

How to Detect Orphans

In the Power Platform Admin Center, orphaned flows show no owner in the Owners column on the environment's flow resource page. In PowerShell, you can cross-reference the flow creator's user ID against Microsoft Entra to check if the account is still active.

The CoE Starter Kit does this automatically. Its inventory flows track the maker's status and flag flows owned by disabled or deleted users.

How to Fix Orphans

Identify the orphan Use admin center, PowerShell, or CoE inventory to find flows with invalid owners.
Assess business impact Is the flow still needed? Check the last run date and whether the business process it supports is still active.
Assign a co-owner In the admin center or via PowerShell (Set-AdminFlowOwnerRole), add a new co-owner to the flow.
Fix the connections The new owner needs to re-authenticate any connections that were tied to the previous owner's account.
Consider service principal ownership For business-critical flows, change ownership to a service principal to prevent future orphaning.

Prevent Orphans by Design

The best way to handle orphans is to prevent them. Service principal ownership is the answer for any flow that supports an organizational process.

A service principal is a non-human identity in Microsoft Entra. It doesn't have a user account that can be disabled when someone leaves. It doesn't take vacation. It doesn't change roles. When a flow is owned by a service principal, the ownership is stable regardless of personnel changes.

Key facts about service principal flow ownership:

Service principals can own and run flows
For solution-aware flows, connections don't need to be shared separately with the service principal
Premium service principal flows need a Power Automate Process or per-flow license
Standard (non-premium) service principal flows get 25,000 base requests per tenant per 24 hours
Service principal flows in context of Dynamics 365 applications get higher limits from a tenant-level pool

Don't put service principals on everything

Service principal ownership is for mission-critical and team-level flows. Personal productivity flows should stay with the user. Over-engineering governance for low-risk flows wastes time and licenses.

Want more governance playbooks?

I write about Power Platform governance, ALM pipelines, and enterprise automation strategy. Follow me on LinkedIn for weekly deep dives.

Connector Audit

Your inventory should tell you which connectors each flow uses. This matters for three reasons:

DLP compliance. Data Loss Prevention policies restrict which connectors can be used together. A flow that combines a SharePoint connector (business data) with a personal Dropbox connector (personal storage) might violate your DLP policy. Your inventory should flag these combinations.
External service exposure. Which flows connect to services outside your organization? HTTP connectors, custom connectors, and third-party connectors can send data anywhere. You need to know which flows use them and what data they transmit.
Premium connector licensing. Flows that use premium connectors require premium licenses. Your inventory should identify which flows use premium connectors so you can ensure license compliance.

The CoE Starter Kit's optional Flow Action Details flow captures connector and action details for every flow. This is resource-intensive to run but provides the deepest visibility.

Output Format

Where do you store the inventory?

Storage	Best For	Pros	Cons
Dataverse (via CoE Starter Kit)	Enterprise tenants, ongoing governance	Rich querying, Power BI integration, automated sync	Requires Dataverse capacity, CoE setup effort
SharePoint list	Small to medium tenants, simpler governance	Easy to set up, familiar interface, Power Automate integration	Limited to 5,000 item threshold for views, no complex queries
Excel / CSV	One-time audits, snapshots	Simple, exportable, shareable	No automation, stale immediately after creation

For ongoing governance, Dataverse via the CoE Starter Kit is the right answer. It gives you a continuously updated, queryable inventory with Power BI dashboards out of the box. For smaller organizations or initial assessments, a SharePoint list with a weekly sync flow is a pragmatic starting point.

Keeping It Current

An inventory that's accurate on the day you create it and wrong the next week isn't governance. It's a report.

Approach	Frequency	Effort	Accuracy
CoE Starter Kit automated sync	Daily	Zero (after initial setup)	High. Only misses items created since last sync
Scheduled PowerShell script	Weekly or monthly	Low (scheduled task)	Good. Depends on run frequency
Admin connector flow	Daily to weekly	Low (after flow is built)	Good. Customizable to your needs
Manual audit	Quarterly	High. Someone has to do it	Low. Outdated within days of completion

The CoE Starter Kit's incremental sync is designed for this. By default, it only updates objects modified since the last inventory run (configurable via the InventoryFilter_DaysToLookBack environment variable, default 7 days). If you need a full re-sync, set the Full inventory environment variable to Yes, run the driver flow, then set it back to No.

Quarterly manual audits are the baseline. If you do nothing else, run a PowerShell export once per quarter, compare it to the previous quarter, and flag new flows, orphaned flows, and flows that stopped running. It's not ideal, but it's infinitely better than not knowing what exists.

From Inventory to Action

An inventory isn't the end goal. It's the foundation for governance decisions:

Flows without naming convention compliance? Reach out to the makers, help them rename.
Loose flows that should be in solutions? Prioritize migration based on classification.
Orphaned flows? Fix or decommission based on business need.
Flows using unapproved connectors? Review, approve, or disable.
Flows that haven't run in 90 days? Candidate for decommission.
Flows owned by users without proper licenses? Fix licensing or reassign ownership.

The inventory gives you the data. Your governance process gives you the actions. Without the inventory, you are governing blind. With it, you are making informed decisions.

Start Here

If you're starting from zero, here's the pragmatic path:

Run a PowerShell export Use Get-AdminFlow across all environments. Export to CSV. This takes 30 minutes and gives you a baseline.
Count and categorize How many flows? How many environments? How many unique owners? How many are enabled vs disabled? Get the high-level numbers.
Identify orphans Cross-reference flow owners with your user directory. Flag flows owned by departed employees.
Classify the top 20 Take the 20 most-used flows (by run count or business impact). Classify them as business-critical, team, personal, or experimental.
Make the case for CoE Starter Kit Use the numbers from your audit to justify the investment in the CoE Starter Kit. 'We have 400 flows, 60 are orphaned, and we had no idea' is a compelling governance story.
Implement continuous sync Deploy the CoE Starter Kit or build your own admin connector flow. Move from point-in-time snapshots to continuous inventory.

The inventory is the foundation. Naming conventions tell you what a flow is. Environment strategy tells you where it lives. Solution awareness tells you how it deploys. But the inventory tells you what exists in the first place. Start there.

Power Automate Governance - The Enterprise Playbook

This article is part of a 10-part series:

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.

Living Documentation in Git - Why Your SharePoint Word Docs Are Dead

Alex Pechenizkiy — Fri, 18 Sep 2026 17:23:58 +0000

You open SharePoint. Navigate to the project folder. Find "Solution Design v3 FINAL (2).docx" from 8 months ago. Half the integrations described don't exist anymore. Three new ones aren't documented. The ERD shows tables that were renamed in sprint 4.

TL;DR

Put your living documentation in git next to your code. Markdown for text, Draw.io for diagrams. Docs update in the same commit as code changes, get reviewed in PRs, and never go stale in a forgotten SharePoint folder.

Nobody updated it because nobody opens SharePoint to update a Word doc after a deployment. The doc was accurate the day it was written. It started dying the day after.

This is how most Dynamics 365 and Power Platform projects handle documentation. And it's why most projects have no useful documentation at all.

Why Does Living Documentation in Git Beat SharePoint Word Docs?

Living documentation in git stays accurate because it versions alongside your code. SharePoint Word docs decay the moment they are saved, because they sit in a separate system that developers never touch during their normal workflow. Git-based docs get updated in the same pull request as the code change, reviewed by the same team, and tracked with the same history.

The Problem Is the Medium, Not the People

Your team isn't lazy. The documentation process is broken.

Word docs in SharePoint have three fatal flaws:

They're disconnected from the code. The solution ships from a git repo. The docs live in SharePoint. Nobody remembers to update both.
They don't diff. When someone edits a Word doc, you can't see what changed. Git shows you every line.
They're invisible. Developers live in VS Code and git. They never open SharePoint unless someone sends them a link.

The Fix: Docs Live Next to Code

Put your documentation in the same git repo as your solution. Markdown files. Draw.io diagrams generated with Claude. Committed alongside the code.

your-project/
  /docs
    architecture.md
    erd.drawio
    integration-map.drawio
    data-migration.md
  /pcf
    ... your PCF source
  /solution
    ... your Dataverse solution

When a developer changes the schema, the ERD is right there in /docs. When someone adds an integration, the architecture diagram is in the same pull request. When a new team member joins, they clone the repo and have everything.

What Goes in /docs

Not everything. Just the stuff that matters and changes with the code:

Document	Format	Why It Belongs in Git
Architecture overview	Markdown	Changes when integrations change
Entity Relationship Diagram	Draw.io XML	Changes when schema changes
Integration map	Draw.io XML	Changes when APIs change
Data flow diagrams	Draw.io XML	Changes when migration logic changes
Configuration reference	Markdown	Changes when config options change
Deployment runbook	Markdown	Changes when environments change

What does NOT belong in git: meeting notes, project plans, status reports, contracts. Those belong in SharePoint or your PM tool. Git is for technical documentation that describes the system.

What a /docs Folder Looks Like in Practice

A typical Power Platform / D365 project repo following this pattern has a /docs folder with:

architecture.md - ADRs (Architecture Decision Records) for every non-trivial choice
ERD diagrams generated from Dataverse schema exports
Integration maps showing system boundaries and data flows
Configuration reference for JSON web resources

The discipline is straightforward: when an entity is added, the ERD gets updated in the same commit. When an integration is added, the architecture doc gets a new ADR. The docs are never more than one commit behind the code.

The figures below are illustrative diagrams generated from the Draw.io + Claude pipeline. They show the kinds of artifacts that belong in /docs for a typical Power Platform engagement, not measurements from a specific client engagement. Names, role labels, and counts are illustrative.

Illustrative flow inventory. Green = deployed, yellow = in development, gray = planned. The pattern: one diagram, kept current with every sprint, lives in git.

An end-to-end process diagram in the same /docs folder might capture all roles, flows, and components in one visual:

Illustrative end-to-end process diagram. Roles and stack are example labels, not a specific engagement. The point: from setup through evaluation to archival, one diagram covers it.

And the integration architecture showing how systems connect:

Illustrative architecture diagram generated with Claude and Draw.io. Lives in /docs, versioned with the code.

This approach pairs naturally with a governance repo where your standards, review checklists, and inventories also live as code.

How to Start

You don't need to migrate everything at once. Pick one active project and do this:

Create a /docs folder in your repo If you don't have one, add it. One folder, committed to git.
Move your ERD there Export your current ERD (even if it's a screenshot) as a .drawio file or .md with a Mermaid diagram. Commit it.
Add architecture.md Write three sentences: what the system does, what it integrates with, and what the deployment looks like. That's your starting point.
Make it a habit Every PR that changes schema or integrations includes a docs update. Review it like you review code.

You don't need to write it all yourself

Claude can generate ERDs from schema exports, architecture docs from code structure, and integration maps from API specs. The AI generates the skeleton. You verify the specifics. More on this in the next articles in this series.

Want more architecture and documentation patterns for Power Platform? Follow Alex on LinkedIn for weekly deep dives on building systems that document themselves.

The Comparison

	SharePoint Word Docs	Docs in Git
Updated when code changes	Almost never	Same commit
Version history	SharePoint versions (hard to compare)	Git diff (line by line)
Discoverable by developers	Requires a link from someone	Right there when you clone
Reviewed in PRs	No	Yes
Works offline	SharePoint needs internet	Local clone
Searchable in IDE	No	grep / Ctrl+Shift+F

What's Next

This is the first post in a series on modern technical documentation for Power Platform and D365 projects. Next up: generating architecture diagrams with Draw.io and Claude - no Visio license required.

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.

Solution-Aware Power Automate Flows - Why Loose Flows Kill Your ALM

Alex Pechenizkiy — Thu, 17 Sep 2026 17:52:41 +0000

There are two kinds of Power Automate cloud flows. Solution-aware flows live inside a Dataverse solution. Non-solution flows - loose flows - live outside of solutions entirely. The difference determines whether you can govern, deploy, and manage the flow, or whether it's a one-off artifact tied to a single person in a single environment.

TL;DR

Solution-aware Power Automate flows can be exported, version-tracked, and deployed across environments. Loose flows cannot. Enable the "Create in Dataverse solutions" tenant setting and migrate existing loose flows using PowerShell or the manual add-to-solution method. Loose flows are technical debt waiting to break.

Most citizen-developer flows are loose. The maker clicked "Create" from the Power Automate home page, built the flow, saved it, and moved on. It works. It runs. It does what they need. But it exists outside of any solution, which means it exists outside of your ALM pipeline, outside of your governance model, and outside of your ability to manage it at scale.

What Makes a Flow Solution-Aware in Power Automate?

A solution-aware flow is a cloud flow that exists inside a Dataverse solution. This means it participates in the standard Power Platform ALM lifecycle: export, import, version tracking, connection references, and environment variables. Any flow created outside a solution is considered "loose" and lacks these capabilities entirely.

Solution-Aware vs Non-Solution Flows

Here's what you gain when a flow is solution-aware, and what you lose when it's not:

Capability	Solution-Aware Flow	Non-Solution (Loose) Flow
Export/import between environments	Yes, through solution transport	No. Must be manually recreated or use legacy zip export
Connection references	Yes. Connections abstracted for multi-environment deployment	No. Connections hardcoded to the maker's account
Environment variables	Yes. Config values change per environment	No. Values hardcoded in the flow definition
Managed solution deployment	Yes. Lock down the flow in production	Not available
Version history	Yes. Drafts and versioning GA since February 2025	No version history
Save as draft	Yes. Save incomplete work without publishing	No. Every save is live
Source control via solutions	Yes. Export solution, commit to git or Azure DevOps	Not possible
Dataverse-backed run history	Yes. Run history stored in Dataverse for richer reporting	Run history in legacy storage only
Admin visibility	Visible in solution explorer, easier to inventory	Harder to track, must use admin APIs or PowerShell
Owner leaves the organization	Can be managed through solution ownership and sharing	Flow becomes orphaned. May stop running.

The gap isn't subtle. A loose flow is a dead end for governance. You can't move it between environments through the standard ALM pipeline. You can't deploy it as part of a managed solution. You can't use connection references or environment variables. When the maker who built it leaves the organization, the flow becomes an orphan - still running (maybe), but nobody knows how to edit it because the connections are tied to a user account that no longer exists.

Why Loose Flows Are Dangerous

The orphan problem deserves its own section because it's the most common way loose flows cause real damage.

Here's the scenario. A maker builds a flow that sends daily sales reports to the VP. It uses the maker's Outlook connection to send the email and the maker's SharePoint connection to read the report data. The flow runs every morning at 7 AM. It works perfectly for 18 months.

Then the maker leaves the company. Their account is disabled. The Outlook connection fails because the user no longer exists. The SharePoint connection fails for the same reason. The flow starts failing silently. Nobody notices for two weeks until the VP asks why they stopped getting reports.

Now what? The flow isn't in a solution. You can't export it. You can't import it into another environment. The connections are dead. An admin can add a co-owner to the flow, but the new owner still needs to recreate every connection. If the flow is complex - branching logic, error handling, parallel branches - reconstructing it takes hours.

If the flow had been in a solution with connection references, the fix would have been: update the connection reference to point to a service account or another user's connection. Five minutes, no flow editing required.

Loose flows are technical debt

Every loose flow in your tenant is a future problem. It might work today. It will break when the owner leaves, when you need to move it to a new environment, or when you need to audit what it does. The only question is when, not if.

How to Make Existing Flows Solution-Aware

You have two options for migrating existing loose flows into solutions: manual (one at a time) or bulk (PowerShell).

Manual: Add to a Solution

Open Power Automate and navigate to Solutions Sign in to make.powerautomate.com. Select Solutions from the left navigation.
Open your target solution Select the solution where you want to add the flow. If you don't have one, create a new solution with your publisher prefix.
Add existing > Automation > Cloud flow Click Add existing, then Automation, then Cloud flow. You'll see two tabs.
Check the Outside Dataverse tab Non-solution flows appear on the Outside Dataverse tab. Solution-aware flows appear on the From Dataverse tab.
Select the flow and add it Select the flow you want to migrate and click Add. The flow is now solution-aware.

Not all loose flows can be added

Some non-solution cloud flows can't be added to a solution due to known limitations. Flows with certain connector types or configurations may not be compatible. Check Microsoft's current documentation on solution limitations if you encounter errors.

Bulk: PowerShell Add-AdminFlowsToSolution

For tenants with hundreds of loose flows, the manual approach doesn't scale. Use the Add-AdminFlowsToSolution PowerShell cmdlet to migrate many flows at once.

# Install the Power Apps admin module if not already installed
Install-Module -Name Microsoft.PowerApps.Administration.PowerShell

# Migrate flows to a solution
Add-AdminFlowsToSolution `
  -EnvironmentName "your-environment-id" `
  -SolutionId "your-solution-id"

The cmdlet accepts parameters to target flows by name or ID, so you can migrate in batches rather than all at once. This is the recommended approach for large-scale migrations.

Make All New Flows Solution-Aware by Default

This is the single most impactful tenant setting for Power Automate governance. When enabled, every new cloud flow is automatically created inside a Dataverse solution. No manual step required. No reliance on maker discipline.

Open Power Platform admin center Navigate to admin.powerplatform.microsoft.com.
Select the target environment Go to Environments and select the environment you want to configure.
Navigate to Settings > Product > Features Open the environment settings and find the Features section under Product.
Enable Cloud flows under 'Create new canvas apps and cloud flows in Dataverse solutions' Toggle the Cloud flows option to On. This ensures all new flows are solution-aware by default.
Repeat for every environment Apply this setting to all environments where makers create flows.

New environments have this enabled by default

As of the current Power Platform release, all new environments provisioned with a Dataverse database have the Cloud flows setting enabled by default. You only need to manually enable it on older environments that were created before this default changed.

Get more Power Platform governance insights

I share hands-on ALM patterns, solution architecture tips, and governance strategies for Power Platform teams. Follow me on LinkedIn for weekly deep dives.

Connection References and Environment Variables in Solutions

Solution-aware flows use connection references and environment variables to abstract authentication and configuration from the flow definition. The flow stays identical across dev, test, and prod -- only the connection mappings and variable values change per environment. See the environment strategy article for the full setup, naming conventions, and a worked example across three environments.

Managed vs Unmanaged Solutions

This is a common source of confusion. When should you use managed solutions, and when should you use unmanaged?

Aspect	Unmanaged Solution	Managed Solution
Editable in target	Yes. Anyone with access can modify	No. Components are locked down
Use in dev	Yes. This is your working copy	No. You don't import managed into dev
Use in test	Sometimes, for flexibility during UAT	Yes, for production-like testing
Use in prod	No. Too risky. Anyone can break it	Yes. This is the standard for production
Can be uninstalled	Components remain after removal	Clean uninstall removes all components
Version tracking	No formal versioning	Version numbers tracked on import

The standard pattern: develop in an unmanaged solution in your dev environment. Export as managed. Import managed into test and production. This ensures production flows can't be edited directly. Changes must go through the dev environment and the ALM pipeline.

Flow Drafts and Versioning

Since February 2025, solution-aware flows support drafts and versioning. This is a significant capability gap that loose flows don't have.

With drafts, you can save an incomplete flow without it going live. Make changes, save as draft, come back later. The published version continues to run while you iterate on the draft. When you're ready, publish the new version.

Version history shows every published version. You can review previous versions, see what changed, and understand the evolution of the flow over time. This is basic version control that every other software development discipline takes for granted. Power Automate now has it for solution-aware flows.

Loose flows have neither drafts nor versioning. Every save is immediately live. There's no way to save work in progress. There's no history of previous versions. If you save a broken change, it's immediately live and running.

Limitations and Known Issues

Solution-aware flows are the right choice, but they're not without limitations:

Some connectors have limited solution support. Check the connector documentation for solution awareness.
Migrating existing loose flows may require rework. Flows with certain trigger types or connector configurations may need adjustments after migration.
Connection references require planning. You need to set up connection references before deployment, not after.
Not all flow features work identically in solutions. Test thoroughly after migration.
Legacy zip export still works for loose flows but isn't recommended for production ALM.

Despite these limitations, the direction is clear. Microsoft is investing heavily in solution-aware flows. Drafts, versioning, Dataverse-backed run history, and the default creation setting all point toward solution-aware as the standard. Loose flows are the legacy.

The Migration Priority

You don't need to migrate every loose flow today. Prioritize:

Business-critical flows that support core processes. These need ALM and governance first.
Flows owned by people who might leave. Reduce orphan risk.
Flows that need multi-environment deployment. Solution awareness is a prerequisite.
Everything else. Work through the backlog over time.

For personal productivity flows that a single user runs for themselves, the risk of leaving them loose is low. Focus your effort on the flows that matter to the organization.

Power Automate Governance - The Enterprise Playbook

This article is part of a 10-part series:

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.

Power Automate Versioning and Source Control - Export Tag Track

Alex Pechenizkiy — Wed, 16 Sep 2026 17:53:26 +0000

You changed a Power Automate flow last Tuesday. Something broke in production on Thursday. You want to compare what the flow looked like before and after your change. You open the flow designer and see... the current version. That's it.

There is no "show me last Tuesday's version." There is no diff view. There is no blame history. Power Automate versioning and source control require you to get flow definitions out of the platform and into git. Solution versioning tracks the whole solution, not individual flows. If your solution has 30 flows and you changed one, the version history tells you the solution changed. Not which flow. Not what changed inside it.

This is the gap that kills teams at scale. You can't govern what you can't track.

TL;DR

Power Automate has no built-in version control for individual flows. Export flow definitions to git using Dataverse Git integration (Azure DevOps) or pac CLI (any git host). Once in git, you get branching, diffing, tagging, and pull request reviews. Use AI to summarize JSON diffs and even rewrite flow definitions for targeted improvements.

How Do You Version Control Power Automate Flows?

You export flow definition JSON from Dataverse into a git repository, either through the native Dataverse Git integration or the pac CLI. From there, every change becomes a commit, every release gets a tag, and you can diff any two versions to see exactly what changed inside a flow.

The State of Flow Versioning in 2026

Power Automate gives you a few things out of the box:

Run history. You can see past executions and their inputs/outputs. Useful for debugging, not for understanding what changed in the flow definition.
Solution versioning. Solutions have version numbers (1.0.0.0, 1.1.0.0). But the version applies to the entire solution, not individual components.
28-day auto-save. Cloud flows keep versions for 28 days in the designer. You can restore a previous version. But you can't compare two versions side by side. And after 28 days, they're gone.

None of this is source control. Source control means: every change is recorded, every version is retrievable, and you can compare any two versions line by line.

To get real source control for flows, you need to get the flow definitions out of Dataverse and into git.

Two Paths to Git

There are two approaches. Microsoft's built-in Dataverse Git integration (GA since April 2025) and the manual pac CLI workflow that teams have been using for years.

	Dataverse Git Integration	Manual pac CLI
Setup effort	Medium - requires Managed Environments, Azure DevOps	Low - just install pac CLI
Git provider	Azure DevOps only (no GitHub)	Any git host
Sync mechanism	Commit/push from maker portal or API	Manual export and unpack
Granularity	Individual component files	Individual component files (after unpack)
Automation	Can be triggered via API	Script it yourself
Requires Managed Environments	Yes	No
Best for	Orgs already on Azure DevOps with Managed Environments	Everyone else, or teams wanting full control

Both approaches end up in the same place: flow definitions as JSON files in a git repo, one file per flow, diffable and taggable.

Path 1: Dataverse Git Integration

Microsoft shipped Dataverse Git integration as GA in April 2025. It syncs solution components from a development environment to an Azure DevOps Git repo.

Here's how it works:

Enable Managed Environments Dataverse Git integration requires Managed Environments. Go to the Power Platform Admin Center, select your dev environment, and enable managed mode. This is a prerequisite you cannot skip.
Create an Azure DevOps repo Create a new repo in Azure DevOps (or use an existing one). This is where your solution components will land. GitHub is not supported natively as of March 2026.
Connect the environment to the repo In the Power Platform Admin Center, go to your environment settings and configure the Git integration. Choose the Azure DevOps org, project, repo, and branch. Pick a folder path for the solution files.
Choose a binding strategy You have two options. Environment binding ties the connection to the environment itself. Solution binding ties it to a specific solution. Environment binding is simpler for single-solution dev environments. Solution binding gives you more control when one environment has multiple solutions.
Commit from the environment From the maker portal (or via API), commit changes to the connected git repo. Each component gets its own file. Flows land as individual JSON definitions.
Pull changes back You can pull from git into the environment to sync changes made by other developers. This is how multi-developer scenarios work - each dev has their own environment, all syncing to the same repo.

Dev environments only

Dataverse Git integration is designed for development environments. You do not sync production or test environments to git. Those environments get updated through deployment pipelines. The flow is: dev environment syncs to git, pipelines deploy from git to test, then to production.

The big advantage: makers can commit directly from the Power Platform maker portal. No CLI. No scripts. The big limitation: Azure DevOps only. If your team uses GitHub, you'll need the pac CLI approach or a mirror setup.

Path 2: Manual pac CLI Workflow

The Power Platform CLI (pac) has been around longer and works with any git host. The workflow is more manual but gives you complete control.

The key commands:

# Export a solution as a ZIP file
pac solution export --name YourSolution --path ./exports/YourSolution.zip

# Unpack the ZIP into individual component files
pac solution unpack --zipfile ./exports/YourSolution.zip --folder ./src/YourSolution

# After making changes, re-pack for import
pac solution pack --folder ./src/YourSolution --zipfile ./exports/YourSolution.zip

# Generate deployment settings (connection references, env variables)
pac solution create-settings --solution-zip ./exports/YourSolution.zip --settings-file ./settings/dev-settings.json

When you unpack a solution, flows land in the Workflows/ folder as individual JSON files. Each flow has its own file named with its GUID and display name. The JSON contains the full flow definition - every action, every condition, every expression.

Your repo structure ends up looking like this:

your-solution-repo/
  src/
    YourSolution/
      Workflows/
        FlowA-{guid}.json
        FlowB-{guid}.json
        FlowC-{guid}.json
      Entities/
        ...
      PluginAssemblies/
        ...
      Other/
        Solution.xml
        Customizations.xml
  exports/
    YourSolution.zip
  settings/
    dev-settings.json
    test-settings.json
    prod-settings.json

The Git Workflow

Once your flow definitions are in git - whether through Dataverse Git integration or pac CLI - you treat them like any other code artifact.

Branching. One branch per feature or change. If you're modifying the approval flow and the notification flow, that's one branch with changes to two JSON files.

Commits. Meaningful commit messages that describe what changed in business terms. Not "updated flow" but "Added retry logic to vendor approval flow - 3 attempts with exponential backoff."

Tags. Tag solution versions when you deploy. v1.0.0.0 matches solution version 1.0.0.0 in Dataverse. When something breaks in production, you can check out the exact version that's running.

# Tag a release
git tag -a v1.2.0.0 -m "Release 1.2.0.0 - added vendor approval retry logic"

# List tags
git tag -l "v1.*"

# Check out a specific version
git checkout v1.1.0.0

Pull requests. Every flow change goes through a PR. The reviewer sees the JSON diff. They can see that you added a new action, changed a condition, or modified an expression. It's not as readable as code, but it's infinitely better than "trust me, I changed the flow."

Following along with the governance series?

I publish new Power Platform governance patterns every week. Follow me on LinkedIn so you don't miss the next article in this 10-part series.

Diffing Flow Versions

Here's where it gets interesting. Flow definitions are JSON. JSON diffs in git.

When you compare two commits, you see exactly what changed:

// Before
"actions": {
  "Send_approval": {
    "type": "OpenApiConnectionWebhook",
    "inputs": {
      "parameters": {
        "approvalType": "First to respond"
      }
    }
  }
}

// After
"actions": {
  "Send_approval": {
    "type": "OpenApiConnectionWebhook",
    "inputs": {
      "parameters": {
        "approvalType": "Everyone must approve"
      }
    }
  }
}

You can see that someone changed the approval from "First to respond" to "Everyone must approve." In the designer, you'd have to open both versions (if you still have them) and click into each action to find the difference.

But raw JSON diffs of complex flows are hard to read. A flow with 40 actions produces a JSON file that's thousands of lines long. Finding the meaningful change in a 200-line diff is tedious.

This is where AI helps. Copy the diff output and ask an AI to summarize it:

Here is a git diff of a Power Automate flow definition (JSON).
Summarize the changes in plain English:
- What actions were added, removed, or modified?
- What conditions changed?
- What expressions were updated?
- Are there any potential issues with the changes?

The AI reads the JSON diff and gives you something like: "The approval action was changed from single-approver to all-must-approve. A new parallel branch was added for a notification to the requester. The error handling scope was extended to cover the new branch." That's a code review you can actually work with.

Rewriting Flows with AI

This is experimental but powerful. Export a flow's JSON definition, give it to an AI, and ask for specific improvements.

Things that work well:

Add error handling. "Wrap each HTTP action in a try-catch scope with retry policy and failure notification."
Rename variables. "Change all variables from Hungarian notation (strApproverEmail) to descriptive names (approver_email_address)."
Add comments. Flow JSON supports a description field on actions and scopes. Ask the AI to add descriptions explaining the business logic.
Optimize expressions. "Simplify this nested if/coalesce chain into a cleaner expression."

Always test in dev first

Importing modified flow JSON can break connection references. The flow JSON contains connection IDs that are environment-specific. If you modify the JSON and import it, connection references may not resolve correctly. Always import to a dev environment first. Reconnect any broken connections. Test the flow end to end before promoting to test or production.

The workflow for AI-assisted flow rewriting:

Export and unpack the solution (pac CLI or git sync)
Copy the specific flow's JSON file
Give it to the AI with specific instructions for what to improve
Review the output carefully. Check that connection references, trigger configuration, and environment-specific values weren't changed
Replace the flow JSON in your unpacked solution
Pack the solution and import to dev
Test every path. Especially error paths.
Once validated, commit to git and promote through your pipeline

This is not a "let AI rewrite everything" approach. It's targeted refactoring of specific flows where you know what you want to improve. The AI handles the tedious JSON manipulation. You handle the validation.

What This Looks Like in Practice

A government services team I worked with had 45 flows across 3 solutions. No version control. Changes went directly into the production environment. When something broke, the fix was "let me try to remember what I changed."

We set up pac CLI exports on a weekly schedule. Every Monday, an Azure DevOps pipeline ran pac solution export and pac solution unpack for each solution, committed the results to git, and tagged the version. Total automation effort: one afternoon.

Within two weeks, the team caught a flow modification that removed an error handling scope. The weekly diff showed the scope was gone. Without git, nobody would have noticed until a failure hit production.

Within a month, the team started doing manual exports before and after each change. Not because someone mandated it. Because they could see the value of tracking what changed.

Getting Started

Don't try to set up the full pipeline on day one. Start with this:

Install pac CLI: dotnet tool install --global Microsoft.PowerApps.CLI.Tool
Authenticate: pac auth create --url https://your-org.crm.dynamics.com
Export your most critical solution: pac solution export --name YourSolution --path ./YourSolution.zip
Unpack it: pac solution unpack --zipfile ./YourSolution.zip --folder ./YourSolution
Initialize a git repo: git init && git add . && git commit -m "Initial export of YourSolution v1.0.0.0"
Push to Azure DevOps or GitHub

You now have version control for your flows. Every export from this point forward is a new commit. Every commit is a diffable snapshot.

From there, add branching, PRs, tags, and automation as the team matures. The important thing is to start capturing the history.

Power Automate Governance - The Enterprise Playbook

This article is part of a 10-part series:

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.

Power Platform Pipelines - Moving Flows from Dev to Prod with Approvals

Alex Pechenizkiy — Tue, 15 Sep 2026 17:51:25 +0000

"How do you deploy flows to production?"

I ask this question in every governance workshop. The most common answer is still "export as managed, import manually, cross fingers." Sometimes they use Azure DevOps pipelines. Sometimes it is a SharePoint list with "ready to deploy" statuses and a person who runs imports on Tuesday mornings.

Microsoft shipped a first-party ALM tool called Power Platform Pipelines. It has been GA since mid-2025. It lives inside the platform itself. No Azure DevOps subscription needed. No YAML. No pipeline agents. And most organizations running Power Platform today do not know it exists.

TL;DR

Power Platform Pipelines give you built-in CI/CD for Dataverse solutions with approval gates, connection mapping, and solution validation. Configure once, then makers deploy from the maker portal with a single click. No YAML, no agents, no ZIP files.

What Pipelines in Power Platform Actually Are

Pipelines are Microsoft's built-in CI/CD for Dataverse solutions. They are not Azure DevOps Pipelines. They are not GitHub Actions. They are a native feature inside Power Platform that handles solution export, validation, approval, and import across environments.

The core idea: you configure a pipeline once (Dev to Test to Prod), and makers deploy from inside the maker portal by clicking a button. The system handles the export, validation, approval gates, connection mapping, and import. The maker never touches a ZIP file.

Not Azure DevOps

When someone says "Pipelines" in the Power Platform context, they mean the native deployment feature inside make.powerapps.com. This is completely separate from Azure DevOps Pipelines or GitHub Actions. Same word, different product.

The Architecture

Every pipeline setup has three parts:

Pipeline Host Environment. A dedicated environment (usually production type) that stores pipeline configuration, deployment history, and solution artifacts. Microsoft provides a default platform host, or you can create a custom one.
Development Environments. Where makers build. These are linked to the pipeline as source environments.
Target Environments. Test, QA, Production. These are the stages in your pipeline, deployed to sequentially.

The key constraint: you cannot skip stages. If your pipeline goes Dev to Test to Prod, you must deploy to Test first. The same solution artifact that passed through Test gets deployed to Prod. No re-export, no tampering, no "let me just make one more change before prod."

This is intentional. It prevents customizations from bypassing your QA process.

Setting Up Your First Pipeline

Create or identify your host environment Go to Power Platform admin center > Deployments > Pipelines. You can use the default Platform host or create a custom host environment. For most organizations, the Platform host is fine to start.
Open the Deployment Pipeline Configuration app In the host environment, open the Deployment Pipeline Configuration model-driven app. This is where you define pipelines, stages, and link environments.
Create a pipeline Name it something meaningful like 'Core Business Apps Pipeline.' Add your stages in order: Dev > Test > Prod. Each stage links to a target environment.
Link development environments Associate your development environments with the pipeline. Makers in these environments will see the pipeline when they open Solutions.
Configure target environments as Managed Environments All target environments must be Managed Environments. You can enable this manually or set it to auto-convert in the admin center under Deployments > Settings.
Test with a simple solution Create a small solution in your dev environment, navigate to Solutions, and look for the Pipelines option. Select Deploy, choose your target stage, and watch it work.

Managed Environments required

As of February 2026, Microsoft auto-enables Managed Environments for any pipeline target that is not already managed. If you have not reviewed your Managed Environment settings, do it now. Check Power Platform admin center > Deployments > Settings.

Approval Gates with Delegated Deployments

Out of the box, any maker with access can deploy. That is fine for dev-to-test. For production, you want approval gates. Pipelines handle this through delegated deployments.

When you enable delegated deployments on a pipeline stage, deployments require approval from an authorized identity before they proceed. The deployment runs under a service principal or a designated pipeline stage owner instead of the maker. This means makers can request deployments to production without having System Administrator access in the target environment.

How It Works

The pipeline extensibility model gives you three gated extension points. Think of them as stops on a train where you control whether it continues or not.

Pre-export step. Runs custom validation when a deployment request is submitted. The system will not export the solution from the dev environment until your logic marks this step complete. Use this for things like ensuring all flows are turned off or naming conventions are followed.
Delegated deployment (approval). The main approval gate. When enabled, the deployment pauses after export and waits for approval. You wire up a Power Automate cloud flow using the OnApprovalStarted trigger. Inside that flow, you can add an approval action, send it to the right people, and then call the UpdateApprovalStatus Dataverse action (20 = approved, 30 = rejected).
Pre-deployment step. An additional gate after approval but before the actual import. Useful for final sign-offs or automated checks.

All three can be used together or independently. For most organizations, the delegated deployment (approval gate) alone covers the core need.

Service Principal Setup

For production deployments, use a service principal as the deploying identity:

Create an enterprise application (service principal) in Microsoft Entra ID
Add it as a server-to-server user in the host and each target environment
Assign Deployment Pipeline Administrator role in the host, System Administrator in targets
On the pipeline stage, check "Is delegated deployment," select "Service Principal," and enter the Client ID
Create a cloud flow in the host environment using the OnApprovalStarted trigger
Add your approval logic, then call UpdateApprovalStatus using the service principal's connection

The service principal approach means flows deployed to production are owned by a service identity, not by "Karen from accounting who left six months ago." This solves the single biggest ALM headache in Power Platform.

Building a Power Platform governance practice? Follow Alex on LinkedIn for architecture patterns, ALM strategies, and governance deep dives every week.

Deployment Settings: Connection References and Environment Variables

Connection references and environment variables hold different values per environment -- your dev SharePoint site isn't the same as production. See the environment strategy article for the full explanation and a worked example.

Pipelines handle the mapping with deployment settings. During deployment, the system prompts for connection references and environment variables. For delegated deployments, admins can preconfigure these values using deployment settings files (JSON) generated with the Power Platform CLI.

pac solution create-settings --solution-zip MySolution.zip --settings-file deploymentSettings.json

This generates a JSON file with placeholders for connection IDs and environment variable values. Fill in the target environment specifics, and the pipeline uses them during import. No manual post-deployment configuration.

Admins can even preconfigure certain connections that get used automatically, so makers don't need to provide connection details at all.

Solution Checker Validation

Before a solution reaches your target environment, it runs through the solution checker. In Managed Environments, you control this with two settings:

Warn: solution imports with a warning if there are critical issues, and an email goes to admins
Block: solution import is canceled if there are critical issues

The recommended configuration:

Environment Type	Solution Checker	Send Emails
Default	Block	Yes
Developer	Warn	No
Sandbox / Test	Warn	No
Production	Block	Yes

This catches known anti-patterns: deprecated API usage, security issues, web resource problems, and accessibility violations. It does not, however, review the quality of your Power Automate flows. A flow with zero error handling, hardcoded URLs, and naming violations passes solution checker without a warning. That gap is real, and we will cover it in the AI-powered flow review article.

Pipelines vs Azure DevOps vs Manual

Capability	Pipelines in Power Platform	Azure DevOps / GitHub Actions	Manual Export/Import
Setup complexity	Low - config in admin center	High - YAML, agents, service connections	None
Approval gates	Built-in delegated deployments	Release gates, environment approvals	Email or Teams message
Connection mapping	Prompted during deployment	Deployment settings JSON in pipeline	Manual after import
Solution checker	Automatic in Managed Environments	Pipeline task (PAC CLI)	Manual or skipped
Artifact storage	Automatic in host environment	Pipeline artifacts or repo	Hopefully someone saved the ZIP
Maker experience	Click Deploy in maker portal	Makers don't touch it (pro dev owned)	Export ZIP, email it, import
Extensibility	Power Automate triggers, Dataverse events	Full YAML customization	None
Cross-tenant	No	Yes	Yes (manual)
Cost	Managed Environment licensing	Azure DevOps subscription + licensing	Free (but expensive in mistakes)

The sweet spot: use Pipelines for most deployments, and layer Azure DevOps or GitHub on top when you need source control integration, cross-tenant deployment, or complex branching strategies. Pipelines can be extended to integrate with both Azure DevOps and GitHub - they are not mutually exclusive.

Default Deployment Pipelines for Environment Groups

A newer capability: you can set a default deployment pipeline for environment groups. When a maker in a development environment tries to share their solution with users, the system prompts them to deploy through the pipeline first. This nudges makers toward the right process without blocking them outright.

Combined with the admin deployment hub in the Power Platform admin center, admins get visibility into all deployments across the tenant, can approve or reject requests, retry failures, and manage pipeline configuration from a single place.

Do Power Platform Pipelines Replace Azure DevOps?

Not entirely. Power Platform Pipelines cover the most common deployment scenarios without any external tooling, and they work well for teams that want maker-friendly CI/CD inside the platform. However, Azure DevOps and GitHub Actions still win for cross-tenant deployments, complex branching strategies, and full source control integration. Many enterprises use both together.

What Pipelines Do Not Cover

Pipelines move solutions reliably. They validate against solution checker rules. They handle approvals and connection mapping. But they have a blind spot.

Nobody reviews the actual content of the flows being promoted. The approval step is a rubber stamp if the approver does not open the solution and inspect every flow definition. And nobody does that for a solution with 15 flows.

Solution checker catches structural anti-patterns. It does not catch business logic problems: missing error handling, hardcoded values that should be environment variables, unapproved connectors, inconsistent naming, or scope nesting so deep that nobody can debug it.

That is the gap where AI-powered flow review fits in. We cover that in the third article in this series.

Power Automate Governance - The Enterprise Playbook

This article is part of a 10-part series:

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.

The Power Platform Governance Repo - Standards Reviews and Inventory in Git

Alex Pechenizkiy — Mon, 14 Sep 2026 18:58:19 +0000

A Power Platform governance repo is the missing single source of truth for every standard, checklist, and inventory report your platform team needs. Your governance documentation lives in three places. The naming conventions are in a Word doc on SharePoint. The flow inventory is in an Excel file on someone's OneDrive. The review checklist is in a Confluence page that hasn't been updated since 2024. The connector approval list is in someone's head.

When a new team member asks "what are our standards?", nobody gives the same answer. Because there is no single answer. There are fragments scattered across tools, inboxes, and memory.

Put it in git. One git repository. All governance artifacts. Version-controlled, searchable, and updated through pull requests like code.

TL;DR

Create a single git repository for all Power Platform governance artifacts: naming conventions, review checklists, flow inventory CSVs, exported solutions, and AI review reports. Use pull requests for changes, automate inventory exports, and start with just two files in week one.

What Is a Power Platform Governance Repo?

A Power Platform governance repo is a version-controlled git repository that centralizes all governance artifacts for your tenant. It holds naming standards, review checklists, connector approval lists, flow inventory data, exported solution files, and review reports in one searchable, auditable location with full change history through pull requests.

Why Git for Governance

This isn't about being trendy with git. It's about solving three real problems.

Problem 1: Nobody knows which version is current. SharePoint has "Standards v3 FINAL revised (Alex comments).docx" and "Standards v4 draft.docx" in the same folder. Which one is active? With git, main branch is always the current version. There's no ambiguity.

Problem 2: Changes happen silently. Someone updates the naming convention in the Word doc. Nobody knows. No notification. No review. With git, every change is a pull request. The team sees the diff, reviews it, and approves it before it merges.

Problem 3: History disappears. Why did we change the error handling standard last quarter? Who approved it? With git, git log and git blame tell you exactly when a line was added, who added it, and which PR it came from.

	SharePoint/Confluence	Git Repository
Single source of truth	Multiple versions in multiple folders	main branch is always current
Change tracking	Document version history (hard to compare)	Line-by-line diff on every change
Review process	Email someone and hope they read it	Pull request with required reviewers
Search	File-level search, limited text search	Full-text search across all files (grep)
Automation	Manual updates only	Pipelines can auto-commit inventory data
Offline access	Requires SharePoint access	Local git clone, works offline
History	Who last modified the file	Complete history of every line, every change, every reason

The Repository Structure

Here's the structure that works. Not a theoretical ideal. This is the structure I set up for D365 implementation teams and what actually gets maintained.

power-platform-governance/
  standards/
    naming-conventions.md
    error-handling-patterns.md
    review-checklist.md
    connector-approval-list.md
    environment-strategy.md
  inventory/
    flow-inventory.csv
    orphan-report.csv
    connector-audit.csv
  solutions/
    hr-evaluation/         (unpacked solution files via pac unpack)
    finance-approvals/
  reviews/
    hr-evaluation-v1.2-review.md   (AI-generated review)
    finance-approvals-v2.0-review.md
  reports/
    monthly-governance-report.md
  templates/
    flow-description-template.md
    new-flow-request-form.md

Let's walk through each folder.

standards/

This is the core of the repo. Plain Markdown files that define how your team builds on Power Platform.

naming-conventions.md - Your flow, environment, solution, connection reference, and environment variable naming patterns. See the naming conventions article for the full standard -- this file is the org-specific version committed to your repo.

error-handling-patterns.md - The standard error handling template. What scope structure to use. What to log. Where to send failure notifications. With actual examples from your environment, not generic guidance.

review-checklist.md - What to check before promoting a flow. Connection references configured? Error handling present? Run-after configured on all actions? Variables named descriptively? This checklist is what reviewers use during PR reviews.

connector-approval-list.md - Which connectors are approved, restricted, or blocked. Updated when DLP policies change. Links to the DLP policy configuration in the admin center.

environment-strategy.md - What environments exist, what they're for, who has access, and the promotion path. Dev to test to production. Which environments are managed. Which allow maker access.

inventory/

Data files that track what exists across your tenant. CSV format because it diffs well in git and opens in Excel when someone needs to filter.

flow-inventory.csv - Every flow: name, owner, environment, solution, status, connectors used, last run date. This is the master list. Updated automatically (more on that below) or manually after each sprint.

orphan-report.csv - Flows whose owners have left the org or been disabled. Updated weekly by automation or manual CoE export.

connector-audit.csv - Which connectors are in use, by which flows, in which environments. Cross-reference with the approval list in standards/.

solutions/

Unpacked solution files from pac CLI. Each solution gets its own subfolder. This is where you track the actual flow definitions, entities, and configuration across versions. See Power Automate Versioning and Source Control for the full export workflow.

reviews/

AI-generated and human-written review reports for specific solution versions. When you review a solution before promotion, the findings go here. Naming convention: {solution-name}-v{version}-review.md. These accumulate over time and become institutional knowledge.

reports/

Periodic governance reports. Monthly summaries, quarterly health checks, annual audits. Markdown with data pulled from the inventory files.

templates/

Reusable templates that makers and developers use when creating new flows or requesting new solutions. A description template ensures every flow has consistent documentation. A request form standardizes the intake process.

Who Maintains What

This is the critical question. A repo that nobody updates is worse than no repo because it creates false confidence. Here's the ownership model.

Platform team (manual commits):

standards/ - Updated when policies change. Every change is a PR reviewed by the CoE lead or governance owner.
templates/ - Updated when standards evolve.
reviews/ - Written or reviewed by a human after AI generates the first draft.

Automation (scheduled commits):

inventory/ - A scheduled pipeline exports data from Dataverse (CoE tables or admin connectors) and commits CSVs to the repo. Weekly or daily depending on org size.
solutions/ - A pre-deployment pipeline step runs pac solution export and pac solution unpack, committing the result before deploying. This captures the exact state of every deployment.
reports/ - Generated from inventory data by a pipeline or Power Automate flow.

AI (generates drafts for human review):

reviews/ - AI reads flow JSON from solutions/, generates review reports flagging issues, suggesting improvements. Human reviews and approves the PR.
reports/ - AI summarizes inventory data into readable monthly reports. Human verifies accuracy.

Start with standards, automate inventory later

You don't need the automation on day one. Create the repo, write your standards in Markdown, and commit them. That alone is a massive improvement over scattered Word docs. Add the automated inventory and solution exports once the team is comfortable with the repo.

How It Connects to Other Tools

The governance repo isn't a replacement for the CoE Starter Kit, DLP policies, or the admin center. It's the connective tissue.

Deployment pipelines. Add a pre-deployment step that exports and unpacks the solution to the governance repo. Before deploying v1.3.0.0 to test, the pipeline commits the unpacked solution to solutions/your-solution/. Now you have a git record of exactly what was deployed and when.

Center of Excellence (CoE) Starter Kit. The CoE Kit collects inventory data in Dataverse tables. A scheduled flow or pipeline exports that data as CSV and commits it to inventory/. The CoE remains the collection engine. Git becomes the archive and the diff engine.

Dataverse Git integration. If you're using the built-in Git integration for dev environments, the governance repo is a separate concern. Dev repos track solution source code. The governance repo tracks standards, inventory, and reviews across all solutions. They complement each other.

DLP policies. Your connector-approval-list.md in standards/ should mirror your actual DLP policies. When DLP policies change, update the Markdown. When the Markdown changes, someone should verify DLP policies match. The git history tells you when the standard changed and whether the policy was updated to match.

Want more governance patterns like this?

I share weekly breakdowns of Power Platform governance, automation architecture, and enterprise patterns. Follow me on LinkedIn to get them in your feed.

Setting Up the Initial Repo

Create the repository Create a new repo in Azure DevOps or GitHub. Name it power-platform-governance or similar. Make it accessible to your platform team, solution architects, and governance reviewers.
Create the folder structure Add the top-level folders: standards/, inventory/, solutions/, reviews/, reports/, templates/. Commit with a README.md that explains the purpose of each folder.
Write your naming conventions Start with standards/naming-conventions.md. Document how your org names flows, environments, solutions, and connection references. Be specific - include examples. This is usually the most-referenced document.
Add the review checklist Create standards/review-checklist.md. List every check that should happen before a flow is promoted. Error handling, connection references, variable naming, run-after configuration, documentation.
Export your current flow inventory If you have the CoE Kit, export the flow inventory from Dataverse as CSV. If not, use the admin connectors or the admin center to compile a list. Save as inventory/flow-inventory.csv.
Set up branch protection Protect the main branch. Require at least one reviewer for all pull requests to standards/. This ensures governance changes are reviewed, not silently edited.
Announce it to the team Send the repo link to your platform team, solution architects, and makers. Walk them through the structure. Show them how to find the naming conventions and checklist. Make it part of onboarding.

The Content of Each Standards File

Let me be concrete about what goes in these files. Generic "follow Microsoft best practices" documents don't help anyone.

naming-conventions.md

# Naming Conventions

## Cloud Flows
Pattern: {publisher-prefix}-{process}-{action}
Examples:
- contoso-vendor-approval-send-notification
- contoso-employee-onboarding-create-accounts
- contoso-invoice-processing-extract-data

## Solution Names
Pattern: {BusinessUnit}{Domain}
Examples:
- ContosoHROnboarding
- ContosoFinanceApprovals

## Environment Variables
Pattern: {publisher-prefix}_{CATEGORY}_{Name}
Examples:
- contoso_SMTP_SenderAddress
- contoso_API_BaseUrl
- contoso_FEATURE_EnableAutoApproval

## Connection References
Pattern: {publisher-prefix}_{ConnectorName}_{Purpose}
Examples:
- contoso_SharePoint_HRDocuments
- contoso_Outlook_Notifications
- contoso_Dataverse_MainConnection

review-checklist.md

# Flow Review Checklist

## Before Promotion to Test
- [ ] Flow is solution-aware (not a standalone flow)
- [ ] Error handling: Try/Catch scope wraps all external calls
- [ ] Connection references used (no hardcoded connections)
- [ ] Environment variables for all configurable values
- [ ] Variables have descriptive names (not var1, temp, x)
- [ ] Run-after configured on all actions (not just "is successful")
- [ ] Flow description filled in (what it does, who owns it, what triggers it)
- [ ] No premium connectors unless pre-approved
- [ ] Concurrency settings reviewed (parallel vs sequential)
- [ ] Large data: pagination enabled where applicable
- [ ] No hardcoded URLs, emails, or IDs
- [ ] Tested with both success and failure scenarios

These are living documents. When you find a new pattern that causes issues, add it to the checklist. When a naming collision happens, refine the naming convention. The git history shows the evolution of your standards over time.

Avoiding Over-Engineering

The biggest risk isn't building too little. It's building too much on day one.

One team I advised created a governance repo with 30 Markdown files, complex folder hierarchies, and automation pipelines before anyone has committed a single real standard. Two months later, the repo is abandoned because maintenance overhead exceeded the team's capacity.

Start small:

Week 1: standards/naming-conventions.md and standards/review-checklist.md. That's it. Two files.
Week 2-4: Use the checklist in actual reviews. Refine it based on what you find.
Month 2: Add inventory/flow-inventory.csv with a manual export. Add standards/error-handling-patterns.md.
Month 3: Automate the inventory export. Add solution exports for your most critical solutions.
Month 4+: Add AI reviews, monthly reports, and templates as the team matures.

Each step should feel lightweight. If it feels heavy, you're going too fast.

Governance is a habit, not a project

The repo is the tool. The habit is using it. Block 30 minutes per sprint to review and update standards based on what the team learned. Make it a standing agenda item. Without the habit, the tool rots.

Making It Searchable

One underrated benefit of Markdown in git: it's searchable from your IDE.

Clone the governance repo. Open it in VS Code. Ctrl+Shift+F to search across all files. Looking for the naming convention for environment variables? Search "Environment Variables." Want to know if a specific connector is approved? Search the connector name in connector-approval-list.md.

Compare that to opening SharePoint, navigating to the right folder, opening a Word doc, and using Ctrl+F inside the document. Multiply by 10 team members doing this 5 times a week.

For teams that live in the terminal, grep -r "approval" standards/ finds every mention of "approval" across all standards files in under a second.

Power Automate Governance - The Enterprise Playbook

This article is part of a 10-part series:

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.

The Weekly Power Automate Governance Digest - Automated Platform Health

Alex Pechenizkiy — Sun, 13 Sep 2026 17:10:00 +0000

A Power Automate governance digest is the single most effective way to keep your platform team informed without relying on dashboards nobody opens. You built a Power BI dashboard for governance. It shows flow counts, failure rates, orphan status, connector usage. It looks great. Nobody opens it.

This is the dashboard problem. Dashboards are pull-based. Someone has to remember to look. Someone has to navigate to the right report. Someone has to interpret the numbers and decide if action is needed. In practice, someone remembers to check the dashboard the week after something breaks. Then they forget again.

Governance that depends on people remembering to look at a dashboard is governance that doesn't work.

The fix: push the information. A weekly email that lands in the inbox of every platform admin, CoE lead, and IT manager. No login required. No navigation. No interpretation. Just a summary of what happened, what's broken, and what needs attention.

TL;DR

Build a scheduled Power Automate flow that queries new flows, broken flows, orphaned flows, and policy violations weekly, then emails a structured summary to your governance team. Start with two sections (new flows and failures) and expand from there.

What Is a Power Automate Governance Digest?

A Power Automate governance digest is a scheduled email report that summarizes platform activity for a defined period, typically one week. It covers new flows, failed runs, orphaned flows, policy violations, and platform stats, all delivered to stakeholders without requiring them to log into any dashboard or admin center.

Why Push Beats Pull

	Dashboard (Pull)	Email Digest (Push)
Requires action to see	Yes - open browser, navigate, log in	No - arrives in inbox
Regular cadence	Only when someone remembers	Automated weekly/monthly
Context without effort	Reader interprets raw charts	Pre-interpreted with recommendations
Reaches non-technical stakeholders	Rarely - they don't know where to look	Yes - email is universal
Creates accountability	No paper trail of who saw what	Delivered to a known audience
Works on mobile	Requires Power BI app or browser	Standard email client

Dashboards still have value for deep dives and ad-hoc analysis. But for regular governance check-ins, email beats a dashboard every time. The goal is awareness, not analytics.

What Goes in the Digest

The digest covers everything a platform owner needs to know about the past week. Not raw data. Summarized, categorized, and prioritized.

Section 1: New Flows Created This Week

Every flow that was created in the past 7 days. For each flow:

Flow name
Creator (maker)
Environment
Solution (or "standalone" if not solution-aware)
Connectors used
Premium connector flag

Why this matters: new flows that use premium connectors, access sensitive data, or run outside solutions need immediate attention. This section surfaces them before they become problems.

Section 2: Flows Modified This Week

Flows that were updated or had new versions created. For each:

Flow name
Modified by
Environment
What changed (new version, modified actions - if available from audit log)

Why this matters: unauthorized changes to production flows are a governance failure. This section catches them.

Section 3: Broken Flows

Flows that had failed runs, were suspended by the platform, or were manually disabled. For each:

Flow name
Owner
Environment
Failure type (run failure, suspended, turned off)
Last successful run
Consecutive failure count

Why this matters: a flow that fails silently is worse than no flow at all. Business processes depend on these flows running. This section is the early warning system.

Section 4: Orphaned Flows

Flows whose owners have been disabled or removed from the tenant. For each:

Flow name
Former owner
Environment
Last run date
Impact assessment (is it still running? Is it critical?)

Why this matters: orphaned flows are governance debt with interest. See the flow inventory article for the full orphan detection and remediation process.

Section 5: Policy Violations

Flows that violate DLP policies, use blocked connectors, or bypass approval requirements. For each:

Flow name
Violation type
Owner
Environment
Severity

Why this matters: DLP policies block connector combinations at runtime. But makers can still build flows that will fail when they hit the policy boundary. This section catches flows that are configured to do things they're not allowed to do.

Section 6: Platform Stats

High-level numbers for context:

Total flows (active, inactive, suspended)
Solution-aware vs standalone flows
Flows by environment
Top 10 connectors by usage
Flows created this month vs last month (trend)

Section 7: Upcoming Deadlines

Review cycles, compliance dates, license renewals, environment refresh schedules. Anything time-sensitive that the governance team needs to act on.

Data Sources

You need data to build the digest. Here's where it comes from.

Center of Excellence (CoE) Starter Kit Dataverse tables. If you have the CoE Kit installed, this is the richest data source. The Kit's sync flows populate Dataverse tables with flow metadata, maker information, connector usage, and environment details. Query these tables with Dataverse connectors in Power Automate.

Admin connectors. The "Power Automate Management" and "Power Automate for Admins" connectors provide direct access to flow metadata across environments. No CoE Kit required. Less data than the CoE tables but sufficient for the core digest sections.

Microsoft Purview audit logs. For change tracking and compliance. Purview captures who created, modified, deleted, or shared a flow. Use the Office 365 Management Activity API or the audit log search to pull recent events.

Data Source	Data Available	Setup Effort	Best For
CoE Starter Kit	Full inventory, maker data, connectors, environments, app usage	High (install and configure CoE)	Orgs with 100+ flows that need deep visibility
Admin connectors	Flow metadata, run history, environment list	Low (just add the connectors)	Smaller orgs or quick-start without CoE
Purview audit logs	Create/modify/delete events, user activity	Medium (API setup, permissions)	Compliance-focused orgs, change auditing

Most teams start with admin connectors and add CoE data later. Don't wait for a perfect CoE installation to start sending digests.

Building the Digest Flow

Create a scheduled cloud flow Trigger: Recurrence. Set to run every Monday at 8 AM (or whatever day works for your team). Run it in a managed environment with appropriate admin permissions.
Query new flows created in the past 7 days Use the Power Automate for Admins connector - List Flows as Admin. Filter by created date >= 7 days ago. For each flow, capture: name, creator, environment, connectors.
Query failed flow runs Use the Power Automate Management connector - List Flow Runs. Filter for failed runs in the past 7 days. Group by flow to get failure counts and last success date.
Query orphaned flows Cross-reference flow owners with Azure AD (Entra ID). If the owner's account is disabled or deleted, flag the flow. Use the Office 365 Users connector to check account status.
Check DLP policy compliance Compare each flow's connector list against your approved connector list. Flag any flow using restricted or blocked connectors. Reference your governance repo's connector-approval-list.md.
Compile the HTML email Build an HTML body with sections for each category. Use tables for structured data. Color-code severity: red for critical (orphans, policy violations), yellow for warnings (failures), green for informational (new flows, stats).
Send to the governance team Use the Outlook connector to send the email to your distribution group: platform admins, CoE lead, IT manager. Include a link to the governance repo for standards reference.

Keep the first version simple

Don't try to build all 7 sections in the first iteration. Start with new flows and broken flows. Those two sections alone provide more visibility than most teams have. Add orphan detection, policy checks, and stats in later versions.

Want more governance patterns like this?

I share weekly breakdowns of Power Platform governance, automation architecture, and enterprise patterns. Follow me on LinkedIn to get them in your feed.

The Email Format

Structure matters. A wall of text gets skimmed and closed. A well-structured email gets read and acted on.

Here's the format that works. Example digest body. The names and counts below are illustrative, not from a real tenant.

Subject: Power Platform Weekly Digest - Mar 10-17, 2026

SUMMARY
- 4 new flows created (1 uses premium connector)
- 2 flows with repeated failures
- 1 orphaned flow (owner left org Feb 28)
- 0 policy violations

---

NEW FLOWS (4)
| Name | Creator | Environment | Connectors | Flag |
| Vendor invoice OCR | jsmith | Production | AI Builder, SharePoint | Premium |
| Team standup reminder | mjones | Dev | Outlook | - |
| Contract renewal alert | klee | Production | Dataverse, Outlook | - |
| Data export to SFTP | jsmith | Production | SFTP, Dataverse | Review needed |

---

BROKEN FLOWS (2)
| Name | Owner | Environment | Failures (7d) | Last Success |
| Nightly data sync | agarcia | Production | 14 | Mar 8 |
| Customer feedback digest | rchen | Test | 3 | Mar 14 |

---

ORPHANED FLOWS (1)
| Name | Former Owner | Environment | Last Run | Status |
| Budget approval routing | tlee (disabled Feb 28) | Production | Mar 15 | Still running |

---

PLATFORM STATS
- Total flows: 187 (142 active, 28 inactive, 17 suspended)
- Solution-aware: 134 (72%)
- Standalone: 53 (28%)
- New this month: 12
- Trend: +8% vs last month

The summary at the top is critical. A busy IT manager reads the first 4 lines and knows whether to keep reading. "0 policy violations, 1 orphan" takes 3 seconds to process. If something is red, they dig into the details below.

AI Enhancement

Raw data is useful. Interpreted data is actionable.

Feed the digest data to an AI before sending it. Ask for:

A plain-English summary of the platform's health this week
Risk flags with severity ratings
Specific recommendations for each issue
Trend analysis compared to the previous digest

Instead of just listing "Nightly data sync - 14 failures," the AI-enhanced version says: "The Nightly data sync flow in Production has failed 14 consecutive times since March 8. This flow is owned by agarcia and processes customer records for the data warehouse. Recommendation: investigate immediately. The data warehouse is likely 9 days behind."

That's the difference between information and intelligence.

You can implement this by adding a step in your digest flow that calls Azure OpenAI (or any AI endpoint) with the compiled data and a prompt asking for a summary with recommendations. Append the AI summary to the top of the email, above the raw data sections.

Review AI summaries before sending

If you add AI-generated summaries, review them for the first few weeks. AI can misinterpret data, exaggerate risks, or make incorrect recommendations. Set up the flow to send a draft to the CoE lead first, then forward the approved version to the broader team. Once you trust the output, you can automate the full send.

Escalation Triggers

Some issues shouldn't wait for the weekly digest. Set up real-time alerts for critical governance events:

Production flow owned by departed employee. The moment HR disables an account, check if that user owns any production flows. If yes, alert the platform team immediately. Don't wait until Monday.

Flow using blocked connector. If a new flow or flow modification introduces a connector that's on the blocked list, flag it the same day. DLP policies will block it at runtime anyway, but the maker needs to know before they waste more time building on it.

High-impact flow failure. Define which flows are business-critical (revenue-impacting, compliance-required, customer-facing). If any of these fail, send an immediate notification. Don't let them accumulate until the weekly digest.

Spike in new flows. If the number of new flows this week is 3x the average, something is happening. Maybe a new team started building on Power Platform without going through the intake process. Flag it for review.

These escalation triggers run as separate flows, not part of the digest. The digest is for routine awareness. Escalations are for things that can't wait.

Cadence and Audience

Not every org needs a weekly digest.

100+ flows, multiple teams: Weekly digest. Enough activity to justify the cadence. Send to platform admins, CoE lead, IT manager.

30-100 flows, small team: Biweekly. Less noise, still useful. Send to the platform owner and IT lead.

Under 30 flows: Monthly. Or even quarterly. At this scale, you might know every flow by name. The digest is more of a health check than a monitoring tool.

Who gets it:

Platform admins (required). They act on the issues.
CoE lead (required). They track trends and set policy.
IT manager (recommended). They need visibility without logging into the admin center.
Solution architects (optional). They benefit from seeing what's being built and how.

Don't send it to every maker. The audience is governance stakeholders, not the entire organization. Makers get feedback through the review process, not the digest.

Connecting to the Governance Repo

The digest becomes more powerful when it links to your governance repo.

New flow uses a connector? Link to standards/connector-approval-list.md.
Flow fails a review check? Link to standards/review-checklist.md.
Orphaned flow detected? Link to standards/environment-strategy.md for the escalation procedure.
AI review generated? Link to the review report in reviews/.

The email is the notification. The repo is the documentation. Together, they form a governance loop: detect issues (digest), reference standards (repo), take action, update standards if needed (PR to repo).

See The Power Platform Governance Repo for the full repo setup.

Getting Started in One Afternoon

You don't need all 7 sections to start. Here's the minimum viable digest:

Create a scheduled flow (Recurrence - weekly)
Query new flows created in the past 7 days (Power Automate for Admins - List Flows as Admin)
Query failed runs (Power Automate Management - List Flow Runs, filter status = Failed)
Format a simple HTML email with two tables: new flows and failures
Send to yourself first. Review it. Adjust the queries. Then add your team.

That's 2-3 hours of work for a flow that runs forever. Every Monday, your inbox tells you what happened on your platform. No dashboards to check. No reports to pull.

From there, add orphan detection in week 2, policy checks in week 3, and AI summaries in month 2. Each addition is incremental. Each one makes the digest more useful.

Power Automate Governance - The Enterprise Playbook

This article is part of a 10-part series:

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.

Notification Architecture That Cannot Break Your Business Logic

Alex Pechenizkiy — Sat, 12 Sep 2026 16:40:08 +0000

A signing workflow processes evaluations through a multi-step chain. When a Power Automate notification flow fails, business impact is zero. When a business flow fails, the chain stops. These two outcomes are possible only because notification flows and business flows share nothing. Not a trigger. Not a variable. Not a solution import cycle.

Every notification flow in this pattern follows one rule: read Dataverse, send email, never write back. That rule is non-negotiable. It is the single architectural decision that makes the entire notification layer disposable without risk to the business.

TL;DR

Separate Power Automate notification flows from business logic entirely. Notification flows should only read Dataverse and send emails. Use daily digests instead of real-time triggers, one flow per email template, and boolean tracking flags for idempotent delivery.

The Temptation

Every maker hits this moment. A flow creates an evaluation record, assigns ownership, configures access teams, and advances the signing chain. At the end of that sequence, the natural thought is: "I should send an email to let the signer know." So a SendEmailV2 action goes at the bottom of the flow.

It works. The signer gets the email. Ship it.

Here is what just happened. Notification logic was coupled to business logic. If the Outlook connector throttles, the business flow retries. If the email action throws an error, the flow's error handling must now account for a notification failure in the middle of a signing chain operation. Editing the email template means editing a flow that manages business-critical state transitions. One wrong click breaks the signing chain, not the email.

This is how it starts. One email action inside one business flow. Then another. Then a condition block: "If status = Rejected, send this email. If status = Approved, send that one." The business flow grows. The email logic grows inside it. Testing the email means running the entire business flow. Disabling the email means disabling the business flow. The two concerns are permanently fused.

This pattern shows up across many production environments. It always ends the same way: a notification change breaks business logic, and nobody understands why the signing chain stopped advancing.

The Separation Principle

Notification flows never write to Dataverse. Full stop.

This is not a best-practice recommendation. It is a structural constraint. Business flows (REV, EVL, STP series in the tag-based architecture) handle all write operations: creating records, assigning ownership, managing access teams, advancing the signing chain. Notification flows (NTF series) handle one thing: querying Dataverse and sending emails.

The separation happens at the flow level, not at the action level. There is no shared flow that branches between "do business logic" and "send notification." Each concern lives in its own flow with its own trigger, its own run history, its own deployment cycle. To visualize this separation, architecture diagrams generated from text descriptions make the boundary obvious: business flows on one side, notification flows on the other, a wall between them.

What this means in practice:

A notification failure never breaks the signing chain. The business flows do not know notification flows exist.
Notification flows can be disabled without risk. The product owner can turn off "Signer Heads-Up" emails (NTF04) without affecting a single business operation.
Testing is independent. Notification flows are tested by verifying email content and recipient logic. There is no risk of accidentally advancing signing steps or reassigning record ownership.
Deployment is independent. Notification flows ship in their own solution import cycle. Email wording can be updated without touching the business solution.

The one exception to 'never write'

When boolean notification tracking flags (covered below) are added, the notification flow writes exactly one field per record: setting app_notified_assigned from false to true. This is still separated. A tracking flag failure cannot break the signing chain. It can only cause a duplicate email on the next run.

Should Notifications Be Real-Time or Daily Digest?

In most cases, daily digests win. Real-time notifications cause email floods during bulk operations, training users to ignore them entirely. Batching notifications into a single daily email per recipient and reserving real-time delivery only for events that are rare, urgent, and triggered by a deliberate human action gives a better recipient experience.

Here is the scenario that argues against real-time delivery.

A product owner opens a review cycle for an entire department. The review-cycle flow fires and bulk-creates dozens of evaluation records, one for each employee. Each creation triggers the evaluator-assignment flow, the access-team flow, and the signing-step setup flow. The entire batch completes in under two minutes.

With real-time notifications, dozens of "Form Assigned" emails fire within seconds. A division director supervising eight employees receives eight separate emails. A senior manager overseeing three team leads receives notifications for every indirect report. The email flood trains users to ignore notification emails entirely, which is the opposite of what notifications are supposed to do.

Microsoft's own guidance warns about this. The event-driven pattern documentation explicitly calls out the need to "prevent multiple updates from causing rapid, repeated notifications" and to "prepare a mitigation plan for unexpected spikes in event frequency."

The daily digest is the mitigation plan.

At a fixed time on weekdays, each notification flow runs on a scheduled recurrence. It queries Dataverse for records modified in the last 24 hours, groups results by recipient, and sends one email per person. A supervisor with 8 new assignments receives a single email: "You have 8 new forms assigned" with a summary table and deep links to each record. One email. Scannable. Actionable.

The flow uses FetchXML to query and sort results by recipient, then iterates with recipient change detection to build per-person HTML bodies using Select and Create HTML Table. Every email is sent from a shared mailbox using SharedMailboxSendEmailV2, not SendEmailV2. Microsoft recommends shared senders over personal accounts for formalized notifications. The recipient sees the application name as the sender, not a developer's personal email. For details on how the FetchXML queries work, see FetchXML in Power Automate.

The Exception: Rejection

Not every notification belongs in a digest.

When a signer rejects an evaluation, three things are true: it is rare (typically one at a time, never in bulk), it is urgent (the author needs to revise immediately), and it is always a deliberate human action. A person clicked "Reject," typed a reason, and submitted. This is not a bulk operation that floods inboxes.

NTF05 and NTF06 are the only event-driven flows in the notification layer. NTF05 notifies the author that their form was rejected. NTF06 notifies all previous signers whose signatures are now invalidated by the rejection. Both trigger on the signing step status changing to "Rejected" and fire immediately.

This exception is not a crack in the architecture. It is proof that the architecture is honest. Blanket rules like "always batch notifications" ignore reality. The right rule is: batch by default, real-time only when the event is rare, urgent, and human-initiated.

One Flow Per Email Template

The pattern uses one notification flow per email type, not a monolithic flow with conditional branches.

Each flow sends exactly one type of email. NTF01 sends "Form Assigned" digests. NTF02 sends "Ready for Signature" digests. NTF05 sends rejection alerts. No flow contains conditional logic that selects between email templates based on input.

Why this matters:

Monitoring. Each flow's run history shows exactly one email type. If "Ready for Signature" emails stop working, the right flow to inspect is NTF02. There is no scrolling through a monolithic flow's run history trying to filter by which branch executed.
Debugging. A failed run points to a specific notification scenario. The flow name tells the problem domain before opening it.
Management. When the product owner wants to disable "Signer Heads-Up" notifications during a pilot, NTF04 is turned off. Nothing else changes. There is no risk of a condition block accidentally suppressing a different email type.
Naming. The tag-based naming convention makes every flow discoverable: <App> | [NTF04] Signer Heads-Up - Daily Digest. The tag tells you what it does before you open it.

Many small flows are easier to build, test, monitor, and maintain than one large flow with many branches. The monolithic approach fails the moment two email types share a partial query and someone edits the shared part without understanding both branches.

Designing notification flows?

Follow Alex on LinkedIn for Power Automate architecture patterns and notification design.

Notification Tracking

Every scheduled notification flow needs to answer one question: which records have already been notified about?

V1: 24-Hour Lookback (Simple, Fragile)

The simplest implementation uses modifiedon with a last-x-hours 24 FetchXML filter. The flow runs at 8:00 AM, queries for records modified in the last 24 hours, and sends digest emails. Simple to build. No schema changes required.

The weakness is obvious. If the flow fails at 8:00 AM Tuesday and nobody notices until Wednesday, the Tuesday records fall outside the 24-hour window. They are never notified. Microsoft documents this behavior: polling triggers do not retroactively catch missed windows when restarted.

For a launch with monitoring in place, this is acceptable. It is not resilient.

V2: Boolean Tracking Flags (Idempotent, Resilient)

The improved pattern adds boolean fields to each notifiable table. The illustrative schema below uses an app_* placeholder prefix.

Table	Field	Purpose
`app_personnelevaluation`	`app_notified_assigned`	Author notified of assignment
`app_personnelevaluation`	`app_notified_complete`	Author notified of completion
`app_evaluationsigningstep`	`app_notified_awaiting`	Signer notified of activation
`app_evaluationsigningstep`	`app_notified_created`	Signer notified of assignment
`app_personnelreviewcycle`	`app_notified_launched`	Participants notified of launch
`app_personnelreviewcycle`	`app_notified_closed`	Participants notified of close

The flow queries for records where the flag is false, sends the notification, then sets the flag to true. If the flow fails mid-run, the unprocessed records still have false flags. The next run picks them up. No gap. No missed notifications. Microsoft recommends idempotent design exactly for this reason.

The worst case with boolean flags is a duplicate email: the flow sends the email, crashes before setting the flag, and the next run sends it again. A duplicate email is inconvenient. A missed notification during a performance review cycle is a compliance problem.

Build v1 for launch. Plan v2 from day one. Do not over-engineer the first release, but do not pretend the weakness does not exist.

Sample Flow Inventory

Here is a sample notification layer for a hypothetical performance management application, illustrating the pattern. The point is structure, not the specific flow set.

Scheduled Flows (Daily, Weekdays)

Tag	Flow Name	Table Queried	Recipient	Priority
NTF01	Form Assigned	`app_personnelevaluation`	Author	P1
NTF02	Ready for Signature	`app_evaluationsigningstep`	Signer (non-self)	P1
NTF07	Evaluation Complete	`app_personnelevaluation`	Author	P1
NTF10	Author Reminder	`app_personnelevaluation`	Author	P1
NTF11	Author Past Due	`app_personnelevaluation`	Author	P1
NTF12	Supervisor Escalation	`app_personnelevaluation`	Author's supervisor	P1
NTF08	Cycle Launched	`app_personnelreviewcycle`	All participants	P3
NTF09	Cycle Closed	`app_personnelreviewcycle`	All participants	P3

Real-Time Flows (Event-Driven, Immediate)

Tag	Flow Name	Trigger	Recipient	Priority
NTF05	Rejection to Author	Step status changed to Rejected	Author	P1
NTF06	Rejection to Previous Signers	Step status changed to Rejected	Previous signers	P1

Priority Tiers

P1 flows are must-have for go-live. Core signing workflow notifications.
P2 flows are important but informational. They can follow shortly after go-live.
P3 flows are nice-to-have. Cycle-level broadcasts can be deferred without impacting individual evaluations.

The NTF tag prefix is deliberately simple. It accepts a channel suffix (NTF-EMAIL, NTF-INAPP, NTF-TEAMS) when multi-channel delivery is added. The naming convention is ready before the channels exist.

Embedded vs Separated

Dimension	Embedded (SendEmail inside business flow)	Separated (Independent NTF flows)
Failure impact	Notification failure can break business flow execution. If SendEmail throws an error mid-flow, the signing chain may halt.	Notification failure has zero business impact. The signing chain continues regardless.
Testing	Must test notifications and business logic together. Email testing triggers real state changes.	Test notifications independently. No risk of advancing signing steps or reassigning ownership.
Deployment	Business flows and notifications deploy together. A template change requires retesting the signing chain.	Notification flows ship in their own solution. Update email wording without touching business flows.
Bulk operations	A single bulk operation creating dozens of records triggers an embedded email per record. Inboxes flood.	Scheduled digest batches all records into one email per recipient at the next run.
Monitoring	Run history mixes business actions and email sends. Hard to isolate notification failures.	Each NTF flow shows exactly one notification type. Failure points to a specific scenario.
Disabling	Cannot disable notifications without disabling the business flow.	Disable any single notification type without affecting business operations.

Every dimension favors separation. The only argument for embedding is convenience: it is faster to add one SendEmail action than to build a separate flow. That convenience evaporates the moment you need to debug, deploy, or disable independently.

What Makes This Work

Three environment variables drive notification flows in this pattern:

app_EnvironmentURL for the base URL of deep links (changes per environment)
app_NotificationsMailbox for the shared mailbox address used by SharedMailboxSendEmailV2
app_AppID for the Model-Driven App identifier used in record deep links

Every email includes a direct link to the relevant record: {EnvironmentURL}/main.aspx?etn=app_personnelevaluation&id={recordId}&pagetype=entityrecord&appid={AppID}&forceUCI=1. The appid parameter opens the record in the correct app. The forceUCI=1 parameter forces the Unified Client Interface. The user clicks the link and lands on the exact record that needs attention.

The shared mailbox is critical. Microsoft explicitly recommends sending formalized notifications from a shared sender, not from the flow owner's personal email. Recipients know the message came from automation, and IT can manage the mailbox independently of any individual user's account.

Build Separated or Build Twice

Most teams build notifications embedded in business flows the first time, then rebuild them separated the second time. The separation principle is the kind of decision you only need to learn once.

Notification flows read. Business flows write. The two share nothing. When one breaks, the other continues. When one deploys, the other is untouched. That is the architecture.

Spec-Driven Power Platform Series

This article is part of a series on building Power Automate solutions with specs, governance, and AI:

Tag-Based Flow Architecture - How 3-letter prefixes make a flow set manageable
Spec-First Development - Why specs should exist before the designer opens
Notification Architecture - Notifications that cannot break business logic
FetchXML in Power Automate - When OData $filter is not enough
Building Solution ZIPs - The undocumented packaging guide
What AI Gets Wrong - And why human correction is the point
Spec-Driven Power Automate - The full story

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.

Tag-Based Flow Architecture in Power Automate

Alex Pechenizkiy — Fri, 11 Sep 2026 17:27:04 +0000

Open a production Power Automate flow list. Twenty, maybe thirty flows. Can a new team member tell which ones handle reviews, which handle evaluations, which are notification flows, which fire on signing step changes?

If the answer takes longer than five seconds, the flows do not have an architecture. They have a list.

This pattern is what turns a list into a system. Three-letter entity-area tags group flows by the Dataverse table they operate on. Every flow gets a tag prefix, a sequence number, and a type suffix. The result is a small set of tag groups that map cleanly to ADO work items, source control, architecture diagrams, and AI agent batches.

This builds on the naming conventions that govern individual flow names. Naming tells you WHAT a flow does. Tags tell you WHERE it belongs in the architecture.

TL;DR

Three-letter entity-area tags (REV, EVL, STP, NTF) group Power Automate flows by the Dataverse table they operate on. Every flow gets a tag prefix, a sequence number, and a type suffix. The result is a navigable architecture that maps to ADO work items, source control, diagrams, and AI agent batches.

The Problem with Flat Flow Lists

A flat list looks like this:

AssignEvaluator-Author
AssignFirstSigner
Author Past Due
Author Reminder
ChainAdvance
CreatePersonnelEvaluations
Cycle Closed
Cycle Launched
Evaluation Complete
Form Assigned
Ready for Acknowledgment
Ready for Signature
Rejection to Author
ResolveSigner
Signer Heads-Up
Signer Past Due
StepAwaiting
StepRejected

Names in alphabetical order. No hierarchy. No grouping. There is no way to tell which flows touch the same table, which are notifications versus business logic, or which fire on a schedule versus in real time.

When a notification requirement lands and a flow count doubles overnight, a flat list collapses fast. In Flow Inventory, the argument is that discovery without classification is just a list. Tags are the classification layer.

The Tag System

Four three-letter tags organize flows by entity area. The illustrative example below uses a performance management application built on three core Dataverse tables, plus a notification layer.

Tag	Entity Area	Example Flow Count	Dataverse Table
REV	Review Cycle	2	app_personnelreviewcycle
EVL	Evaluation	5	app_personnelevaluation
STP	Signing Step	3	app_evaluationsigningstep
NTF	Notification	14	Read-only across all tables

Each tag maps to exactly one Dataverse entity area. REV flows only touch app_personnelreviewcycle. EVL flows only touch app_personnelevaluation. STP flows only touch app_evaluationsigningstep. NTF flows query across tables but never write to any of them.

This is a strict rule, not a guideline. A flow tagged STP only does signing step logic. If a flow needs to touch two entity areas, it calls a child flow. The tag stays clean.

The Naming Pattern

Every flow follows this structure:

<App> | [{TAG}{##}] {Description} - {Type}

Examples:

Northwind | [REV01] CreatePersonnelEvaluations - Business Logic
Northwind | [EVL03] EvalAccessTeam - Business Logic
Northwind | [STP01] ChainAdvance - Business Logic
Northwind | [NTF01] Form Assigned - Daily Digest

This builds on the foundational naming pattern from Naming Conventions That Scale. That article covers the base layer: project prefix, descriptive names, consistent formatting. Tags are the next layer up. They add architectural grouping on top of individual flow names.

Channel Suffixes for Notifications

The NTF tag accepts a channel suffix to future-proof for multi-channel delivery:

NTF-EMAIL for email notifications
NTF-INAPP for in-app notifications
NTF-TEAMS for Microsoft Teams adaptive cards

Designing the naming structure for channels that do not exist yet pays off later. When a Teams integration ships, NTF-TEAMS-01 slots in. No renaming. No restructuring.

Microsoft agrees on prefixes

Microsoft's own coding guidelines recommend categorizing components with prefixes or tags to "help team members quickly identify the role of each component within the flow." Their examples use component-level prefixes like "Trg_" for triggers. Entity-area tags are the next level up. Same principle, applied to entire flows instead of individual actions.

How Tags Map to Everything

Tags are not a naming trick. They are an organizational primitive that maps to every tool in the development lifecycle.

Artifact	How Tags Appear	Example
Power Automate	[TAG##] prefix in display name	Northwind \| [EVL01] AssignEvaluator-Author
Azure DevOps	Tag in work item title	EVL01: Assign evaluator on Draft status
Architecture diagrams	Labeled boxes per tag group	REV group, EVL group, STP group, NTF group
Source control	Tag-based file naming	flows/Northwind-EVL01-AssignEvaluator.json
AI agent batches	Grouped by tag for parallel generation	Agent 1: NTF01, NTF10, NTF11 (author-facing)
Priority tiers	Tags define deployment phases	REV/EVL/STP = Phase 1, NTF P1 = Phase 2

When an ADO work item is titled "EVL01: Assign evaluator on Draft status," the exact flow it maps to, the exact table it touches, and the exact solution it lives in are all determined. When a file in source control is named Northwind-EVL01-AssignEvaluator.json, the same is true. One tag, one concept, across every tool. This only works when flows are solution-aware. Loose flows cannot be grouped or governed this way.

Sample Inventory

Here is a sample inventory using the four-tag taxonomy on a hypothetical performance management application. The point is to show structure, not to prescribe a specific flow set.

Business Logic Flows

Tag	Flow Name	Trigger	Purpose
REV01	CreatePersonnelEvaluations	Review status set to Open	Creates evaluation records from template roles
REV02	ReviewAccessTeam	Review created	Adds reviewee, supervisor, coach to review access team
EVL01	AssignEvaluator-Author	Evaluation status set to Draft	Resolves evaluator by role, assigns ownership
EVL02	AssignFirstSigner	Evaluation status set to Submitted	Finds step 1, assigns first signer, sets Signing Off
EVL03	EvalAccessTeam	Evaluator field populated	Adds evaluator to access teams, creates Step 0 (Authoring)
EVL04	StampSigningConfig	Evaluation created	Parses template signing config JSON, creates signing step rows
EVL05	ResolveSigner	Signer role changed	Role-based signer resolution from organizational hierarchy
STP01	ChainAdvance	Step status set to SignedOff	Advances to next signer or sets Fully Signed Off
STP02	StepAwaiting	Step status set to Awaiting	Adds signer to evaluation and review access teams
STP03	StepRejected	Step status set to Rejected	Resets evaluation to Draft, reassigns ownership to author

Look at the tag column. Without reading anything else, the structure is visible: 2 review flows, 5 evaluation flows, 3 signing step flows. Each group maps to one Dataverse table. Each flow performs exactly one logical operation.

Building something similar?

Follow Alex on LinkedIn for Power Platform governance patterns and architecture deep dives.

Notification Flows (Scheduled)

A scheduled batch runs daily on weekdays. Each flow handles exactly one notification type.

Tag	Description	Table Queried	Recipient
NTF01	Form Assigned	app_personnelevaluation	Author
NTF02	Ready for Signature	app_evaluationsigningstep	Signer (non-self)
NTF03	Ready for Acknowledgment	app_evaluationsigningstep	Employee (self-signer)
NTF04	Signer Heads-Up	app_evaluationsigningstep	Signer (future)
NTF07	Evaluation Complete	app_personnelevaluation	Author
NTF08	Cycle Launched	app_personnelreviewcycle	All participants
NTF09	Cycle Closed	app_personnelreviewcycle	All participants
NTF10	Author Reminder	app_personnelevaluation	Author
NTF11	Author Past Due	app_personnelevaluation	Author
NTF12	Author Past Due Supervisor Escalation	app_personnelevaluation	Author's supervisor
NTF13	Signer Past Due	app_evaluationsigningstep	Signer
NTF14	Signer Past Due Supervisor Escalation	app_evaluationsigningstep	Signer's supervisor

Notice the numbering gap: there is no NTF05 or NTF06 in this table. Those are real-time flows, listed below. The numbers are stable identifiers, not sequential counters. Gaps are fine. Renumbering is not.

Notification Flows (Real-Time)

Tag	Description	Trigger	Recipient
NTF05	Rejection to Author	Step status changed to Rejected	Author
NTF06	Rejection to Previous Signers	Step status changed to Rejected	Previous signers (all with SignedOff status and lower stepOrder)

These two flows fire immediately on rejection events. Everything else is batched into daily digests. That is a deliberate design choice. If a supervisor escalation flow fired in real time, a supervisor with 15 overdue evaluators would receive 15 emails in seconds. A daily digest produces one email per supervisor. Tags make this distinction visible at the inventory level.

Priority tiers matter for deployment

Not every notification flow ships at once. P1 flows are must-have for go-live. NTF04 (signer heads-up) is often P2, nice to have, ships after launch. Cycle broadcasts (NTF08, NTF09) are typically P3 and deferrable. Tags let you define these tiers without a separate tracking document.

Why Tags Enable AI-Assisted Development

Tags are more than an organizational nicety. They are an architectural requirement for AI-assisted development. Because each tag maps to one Dataverse table and one functional area, you can hand an AI agent a scoped batch of flows with only the context it needs. No cross-table confusion, no conflicting patterns, no prompt bloat from unrelated flows.

A reasonable batching strategy for the notification layer above:

Agent	Tag Group	Flows	Why This Batch
Agent 1	Author-facing	NTF01, NTF10, NTF11	Same table, same recipient type
Agent 2	Signer-facing	NTF02, NTF03, NTF04	Same table, same recipient type
Agent 3	Event + completion	NTF05, NTF06, NTF07	Event-driven triggers, distinct from scheduled
Agent 4	Escalation + broadcast	NTF08, NTF09, NTF12, NTF13, NTF14	Supervisor resolution pattern, cycle queries

Flows within a tag group share the same Dataverse table, the same query patterns, and the same recipient resolution logic. The author-facing batch only needs context about app_personnelevaluation and author-facing email templates. The signer-facing batch only needs context about app_evaluationsigningstep and signer-facing templates.

Without tags, a single AI agent would need full context on all notification flows simultaneously. With tags, each agent thread operates on a focused batch. The patterns (variable initialization, FetchXML queries, Apply-to-each loops, SharedMailboxSendEmailV2 actions) are documented in a spec. Tags define the batches. Specs define the patterns. The AI executes.

This is the value of tags that nobody else is writing about. Naming conventions are not just for humans reading flow lists. They are grouping signals for AI systems building flows in parallel.

Implementing Tags in a Project

You do not need a complex application to use tags. Here is how to start.

Step 1: Identify entity areas. Look at the Dataverse tables. Group flows by the primary table they trigger from or operate on. Each group gets a 3-letter tag. For an Accounts, Contacts, and Opportunities domain, the tags might be ACC, CON, OPP.

Step 2: Number sequentially within each tag. ACC01, ACC02, CON01, CON02. Numbers indicate creation order, not priority or importance.

Step 3: Add channel suffixes for multi-channel flows. If notification flows could span email, Teams, and in-app, use NTF-EMAIL, NTF-TEAMS, NTF-INAPP. If only email exists today, still use NTF-EMAIL. The convention is ready before the channels exist.

Step 4: Use the same tags everywhere. ADO work items, architecture diagrams, file names, solution XML. One tag, one concept, across all tools. If EVL01 means "assign evaluator" in Power Automate, it means "assign evaluator" in the ADO backlog, the architecture diagram, and the source control folder.

Step 5: Document the tag dictionary. A reference table mapping every tag to its entity area, Dataverse table, and flow count. Keep it in solution documentation. Update it when flows are added. This is the single source of truth.

Start small

Six flows is enough to benefit from tags. Even at six, tags tell you which entity area each flow belongs to. The system pays for itself the first time someone asks "which flows touch the evaluation table?" and the answer comes in two seconds instead of after opening each flow individually.

Microsoft recommends codifying naming conventions in a style guide so all team members follow the same standards. Your tag dictionary is that style guide. Pin it. Put it in the repo README.

The Difference Tags Make

Side by side, before and after:

Without Tags	With Tags
AssignEvaluator-Author	Northwind \| [EVL01] AssignEvaluator-Author - Business Logic
Form Assigned	Northwind \| [NTF01] Form Assigned - Daily Digest
ChainAdvance	Northwind \| [STP01] ChainAdvance - Business Logic
Author Past Due Supervisor Escalation	Northwind \| [NTF12] Author Past Due Supervisor Escalation - Daily Digest
ReviewAccessTeam	Northwind \| [REV02] ReviewAccessTeam - Business Logic

The left column is a list. The right column is an architecture. You can sort by tag, filter by type, group by entity area, and batch for AI generation. Same flows. Different level of control.

Tags are not overhead. They are the cheapest architectural decision on a Power Platform project. Four three-letter codes turn an unrelated set of flows into a system that can be explained in one table.

To see tags applied as visual documentation, Architecture Diagrams with Draw.io MCP shows how to generate flow inventory diagrams directly from tag-based inventories like this one.

Spec-Driven Power Platform Series

This article is part of a series on building Power Automate solutions with specs, governance, and AI:

Tag-Based Flow Architecture - How 3-letter prefixes make a flow set manageable
Spec-First Development - Why specs should exist before the designer opens
Notification Architecture - Notifications that cannot break business logic
FetchXML in Power Automate - When OData $filter is not enough
Building Solution ZIPs - The undocumented packaging guide
What AI Gets Wrong - And why human correction is the point
Spec-Driven Power Automate - The full story

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.

FetchXML in Power Automate: When OData $filter Is Not Enough

Alex Pechenizkiy — Thu, 10 Sep 2026 17:25:27 +0000

OData $filter is the default tool for filtering rows in a Power Automate List rows action. For simple single-table queries it is the right tool. For the kind of queries notification and digest flows actually need, it runs out of capability fast.

Three failure modes show up over and over in production flows: temporal filters with no native operator, joins across more than one related table, and IN-style filters across multiple GUIDs. FetchXML handles all three cleanly. This article walks the patterns and where each one is worth reaching for.

TL;DR - Three things OData cannot do cleanly

Temporal operators like last-x-hours and olderthan-x-days have no OData equivalent. You must compute cutoff dates manually.

Linked entity joins across multiple tables are fragile with $expand and break beyond one level.

IN with multiple GUIDs requires verbose or chains in OData but is clean XML in FetchXML.

Where $filter Runs Out

OData $filter works well for simple queries. statuscode eq 1. name eq 'Contoso'. revenue gt 1000000. For single-table, single-condition filtering, it is the right tool.

It stops being the right tool in four situations.

Temporal operators. "Find records modified in the last 24 hours." OData has no last-x-hours. You would need a Compose action to calculate addHours(utcNow(), -24), then string-interpolate the result into a $filter expression. It works, but it is brittle and ugly. FetchXML gives you operator="last-x-hours" value="24" as a first-class operator, documented in the FetchXML condition operators reference.

Linked entity joins. You need an evaluator's name, a form name, and a reviewee's full name that lives two relationships away. OData $expand can follow one lookup. Nested $expand syntax across multiple levels is inconsistently supported across Dataverse connector versions.

Multi-value IN filters. "Find records in status A or status B or status C." OData requires (status eq 'guid1' or status eq 'guid2' or status eq 'guid3'). FetchXML gives you operator="in" with child <value> elements. Cleaner, and it scales to any number of values.

Ordering combined with complex filtering. OData supports $orderby, but when you combine it with multi-condition filters and expansions, the query string becomes unreadable. FetchXML keeps ordering, filtering, and joins in a structured XML hierarchy.

Capability	OData $filter	FetchXML
Simple equality	Compact one-liner	Works but verbose
Temporal: last N hours	Manual date math	last-x-hours operator
Temporal: older than N days	Manual date math	olderthan-x-days operator
Temporal: on or before date	Must compute or hardcode	on-or-before with dynamic expression
IN with multiple GUIDs	Verbose or-chains	operator="in" with child values
Multi-table joins	$expand, fragile nested	link-entity, up to 10 levels
Ordering + complex filters	Readable for simple cases	Structured XML hierarchy
Built-in pagination	$top / $skip / nextLink	Manual paging required
Readability for simple queries	Winner	XML verbosity

FetchXML Fundamentals in Power Automate

FetchXML queries go into the Fetch Xml Query field of the List rows action in the Microsoft Dataverse connector, under Advanced Options.

Add a List rows action Use the Microsoft Dataverse connector, not the legacy Common Data Service connector. Select your target table.
Expand Advanced Options Look for the 'Fetch Xml Query' field. When you populate this, it overrides the Row Filter field entirely.
Paste your FetchXML The query starts with and contains an element matching the table you selected. Include only the elements you need.
Handle pagination yourself The List rows pagination toggle does NOT work with FetchXML. If you expect more than 5,000 rows, you must implement paging using the page and paging-cookie attributes in your FetchXML.

Pagination does not work with FetchXML

The "Pagination" toggle in List rows settings is ignored when you use a Fetch Xml Query. This means your query returns up to the default page size unless you implement paging. If you need more, manage paging manually using the page and paging-cookie attributes on the <fetch> element. For most notification flows the default page is more than enough. For bulk-processing flows, plan for this. See the List rows reference for the relevant note on aggregation and FetchXML behavior.

Every FetchXML query in a solution-aware flow should use connection references, not hardcoded connections. The List rows action itself references a Dataverse connection reference. The FetchXML inside it can contain dynamic expressions like @{utcNow()} that Power Automate evaluates at runtime.

Temporal Operators: The Killer Feature

This is where FetchXML earns its place. Dataverse exposes a full library of temporal condition operators that OData does not surface.

last-x-hours: Daily Digest Lookback

Consider a daily digest scheduled at 8:00 AM that needs all records assigned in the previous 24 hours. The query against an app_personnelevaluation table looks like this:

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">
  <entity name="app_personnelevaluation">
    <attribute name="app_personnelevaluationid" />
    <attribute name="app_name" />
    <attribute name="app_evaluationduedate" />
    <attribute name="app_evaluator" />
    <filter type="and">
      <condition attribute="app_personnelevaluationstatus"
                 operator="eq"
                 value="00000000-0000-0000-0000-000000000000" />
      <condition attribute="app_evaluator" operator="not-null" />
      <condition attribute="modifiedon" operator="last-x-hours" value="24" />
    </filter>
    <order attribute="app_evaluator" />
  </entity>
</fetch>

Three conditions that would each require a workaround in OData: the status check is fine, but the null guard and the temporal lookback are not. FetchXML handles all three in a single readable block.

To do this in OData you would need a Compose action with addHours(utcNow(), -24), then reference that output inside the $filter string. It works, but now you have flow logic split across two actions instead of one self-contained query.

olderthan-x-days: Past Due Escalation

A supervisor escalation flow needs records that have been past due for more than 7 days. The olderthan-x-days operator finds records that have been sitting in an overdue state:

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">
  <entity name="app_personnelevaluation">
    <attribute name="app_personnelevaluationid" />
    <attribute name="app_name" />
    <attribute name="app_evaluationduedate" />
    <attribute name="app_evaluator" />
    <filter type="and">
      <condition attribute="app_personnelevaluationstatus"
                 operator="in">
        <value>00000000-0000-0000-0000-000000000001</value>
        <value>00000000-0000-0000-0000-000000000002</value>
      </condition>
      <condition attribute="app_evaluationduedate"
                 operator="olderthan-x-days"
                 value="7" />
      <condition attribute="app_evaluator" operator="not-null" />
    </filter>
    <order attribute="app_evaluator" />
  </entity>
</fetch>

GUIDs are illustrative placeholders. Notice the operator="in" with child <value> elements. This checks two statuses (past due and overdue) in a single condition. The OData equivalent would be (app_personnelevaluationstatus eq 'guid1' or app_personnelevaluationstatus eq 'guid2'). Add the olderthan-x-days equivalent (which does not exist natively) and you are looking at a query string nobody can debug.

on-or-before: Past Due Reminders

A signing-step reminder flow finds steps that are past due. The step must be in "Awaiting" status AND the due date must be on or before right now:

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">
  <entity name="app_evaluationsigningstep">
    <attribute name="app_evaluationsigningstepid" />
    <attribute name="app_duedate" />
    <attribute name="app_steporder" />
    <attribute name="app_signer" />
    <attribute name="app_evaluation" />
    <filter type="and">
      <condition attribute="app_stepstatus"
                 operator="eq"
                 value="691090001" />
      <condition attribute="app_duedate"
                 operator="on-or-before"
                 value="@{utcNow()}" />
    </filter>
    <link-entity name="app_personnelevaluation"
                 from="app_personnelevaluationid"
                 to="app_evaluation"
                 link-type="inner"
                 alias="eval">
      <attribute name="app_name" />
      <attribute name="app_evaluator" />
    </link-entity>
    <order attribute="app_signer" />
  </entity>
</fetch>

The @{utcNow()} expression is evaluated by Power Automate before the query runs. The on-or-before operator captures everything past due, regardless of whether it is one day or one year overdue.

Working with complex Dataverse queries?

Follow Alex on LinkedIn for FetchXML patterns and Power Automate deep dives.

Linked Entity Joins: One Query Instead of Five

A daily digest notification often needs more than the primary record. Suppose the email body needs the evaluator's name, the form name, and the reviewee's full name. The reviewee lives on the app_personnel table, which connects through app_personnelreview. That is two joins from the evaluation record.

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">
  <entity name="app_personnelevaluation">
    <attribute name="app_personnelevaluationid" />
    <attribute name="app_name" />
    <attribute name="app_evaluationduedate" />
    <attribute name="app_evaluator" />
    <link-entity name="app_personnelreview"
                 from="app_personnelreviewid"
                 to="app_review"
                 link-type="inner"
                 alias="review">
      <attribute name="app_name" />
      <link-entity name="app_personnel"
                   from="app_personnelid"
                   to="app_personnel"
                   link-type="inner"
                   alias="reviewee">
        <attribute name="app_fullname" />
      </link-entity>
    </link-entity>
    <filter type="and">
      <condition attribute="app_personnelevaluationstatus"
                 operator="eq"
                 value="00000000-0000-0000-0000-000000000000" />
      <condition attribute="modifiedon" operator="last-x-hours" value="24" />
    </filter>
    <order attribute="app_evaluator" />
  </entity>
</fetch>

All three tables in one query. Results come back flat with aliased columns: review.app_name for the review cycle name and reviewee.app_fullname for the person being reviewed. No secondary "Get a row by ID" actions. No nested Apply to each loops.

Without FetchXML, this flow would need a List rows to get evaluations, then a Get row for each evaluation's review, then another Get row for each review's personnel record. That is 1 + N + N API calls. With FetchXML, it is 1.

Dataverse supports up to 10 levels of link-entity nesting per query, and additional link-entities can be added at the same level. In practice, three is usually plenty. If you are nesting deeper than that, the data model probably needs attention before the query does.

Ordering for Recipient Grouping

This pattern is non-obvious and saves a lot of flow run actions.

Look at the <order attribute="app_evaluator" /> in every example above. That is not for display. It is the engine of the daily digest pattern.

The flow needs to send one email per evaluator containing all their assigned records. Without ordering, you would: get all rows, extract unique evaluator GUIDs, then loop through each GUID and filter the rows. That is O(n^2) in Power Automate actions.

With ordering, results arrive grouped by evaluator GUID. The flow iterates through the list once. When the evaluator GUID changes from the previous row, it knows: finalize the current email body, send it, start building the next one. One pass. O(n) actions.

The savings are significant for any digest flow that fans out to multiple recipients. The exact action count depends on the recipient count and average rows per recipient, but the pattern reliably collapses nested-loop work into a single pass and reduces action consumption against the Power Platform request limits.

When Should You Use FetchXML Instead of OData?

If your Power Automate flow needs temporal operators like last-x-hours, joins across multiple Dataverse tables, or IN filters with several GUIDs, use FetchXML. OData $filter works for simple single-table queries, but production notification and reporting flows almost always hit at least one limitation that only FetchXML can solve.

A practical decision framework:

Use OData $filter when:

The query filters on a single table with simple conditions
You need built-in pagination ($top / $skip)
The query fits in one readable line
You are building a quick prototype and do not need temporal logic

Use FetchXML when:

You need temporal operators (last-x-hours, olderthan-x-days, on-or-before, last-week)
You need joins across two or more related tables
You need IN with multiple values, especially GUIDs
You need ordering combined with complex filtering
The query will be maintained by a team and structured XML is easier to read than a long filter string

A reasonable workflow is to prototype with OData and switch to FetchXML the moment you hit a limitation. For notification flows, that moment usually comes on flow number one.

Validate before deploying

FetchXML queries are powerful but easy to get wrong. A mistyped attribute name returns zero rows with no error. Before promoting FetchXML-heavy flows to production, run the query in XrmToolBox's FetchXML Builder to verify the results. For automated validation, see AI-powered flow review gates that can catch query issues before they reach production.

Performance Tips

A few practical guardrails that show up across most production FetchXML in Power Automate.

Select only the attributes you need. Avoid all-attributes. Every extra column is data transferred from Dataverse to Power Automate. In a flow that runs daily across hundreds of records, this adds up. The official guidance is in FetchXML performance optimizations.

Use exists link-types when you do not need columns from the joined table. If you are filtering by a related record's status but do not need any of its fields in the output, link-type="exists" skips the join in the result set.

Avoid leading wildcards. like '%Smith' forces a table scan. like 'Smith%' can use an index. This applies in FetchXML the same way it applies in SQL.

Test your row counts. List rows with FetchXML caps at the default page size without manual paging. If your notification flow could plausibly match more, either add tighter filters or implement paging with page and paging-cookie.

Spec-Driven Power Platform Series

This article is part of a series on building Power Automate solutions with specs, governance, and AI:

Tag-Based Flow Architecture - How 3-letter prefixes make a flow inventory manageable
Spec-First Development - Why specs should exist before the designer opens
Notification Architecture - Notifications that cannot break business logic
FetchXML in Power Automate - When OData $filter is not enough
Building Solution ZIPs - The undocumented packaging guide
What AI Gets Wrong - And why human correction is the point
Spec-Driven Notification Flows - The full story

Power Automate Governance - The Enterprise Playbook

This article is part of a 10-part series:

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.