Spec-Driven Power Platform: The Complete Series

I built 14 Power Automate notification flows in one session. No designer. No copy-paste. Specs in git, AI agents generating flow JSON in parallel, packaged into a Dataverse solution ZIP, imported and running.

This series documents the entire process - the architecture, the methodology, the tools, and the honest mistakes. It is not a tutorial series. It is a practitioner’s account of what happens when governance meets AI on a real project.

The Thesis

Governance is not overhead. It is the prerequisite that makes AI-assisted development possible at scale.

Without tags, AI has no grouping signal. Without specs, AI makes wrong assumptions. Without solution packaging knowledge, the flows stay in JSON files on your laptop. Every “boring” governance practice - naming conventions, documentation in git, solution-aware flows - became a force multiplier when AI entered the picture.

The Series

Start Here

The 10-Minute Build: How Specs and AI Produced 14 Power Automate Flows

The hero article. The full story from requirement to production. A product owner submitted a work item on Monday morning. By lunch, 14 notification flows were built, packaged, and imported. This article explains what made that possible and links to every deep dive below.

Architecture and Governance

Tag-Based Flow Architecture: REV, EVL, STP, NTF - 24 Flows, Zero Confusion

How four 3-letter prefixes turned a flat list of 24 flows into a navigable architecture. Tags map to ADO work items, architecture diagrams, source control, and AI agent batches. The complete 24-flow inventory is the centerpiece.

Builds on: Naming Conventions That Scale

Spec-First Development: Why Your Flow Specs Should Exist Before the Designer Opens

We wrote 14 flows without opening the designer. The specs were precise enough that AI generated flow JSON directly from them. This article covers what a machine-readable spec looks like - not a Word doc, but markdown in git with flow inventories, trigger definitions, and FetchXML queries.

Builds on: Living Documentation in Git | The Governance Repo

Notification Architecture That Cannot Break Your Business Logic

The strongest opinion article in the series. Notification flows never write to Dataverse. They read and send email. Period. This article covers the separation principle, daily digest vs real-time, one-flow-per-template, and the complete 14-flow notification inventory with priority tiers.

Builds on: Solution-Aware Flows | Environment Strategy

Technical Deep Dives

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

OData breaks the moment you need temporal queries, linked entity joins, or multi-value filters. FetchXML handles all three. Four real production queries from the notification flows, a full comparison table, and the recipient grouping pattern that cut flow actions by 65%.

Building Dataverse Solution ZIPs Programmatically: The Undocumented Guide

Microsoft documents solution export via UI. They do not document the internal ZIP structure. This article does. PA Editor format vs solution export format. Deterministic UUIDv5 GUIDs. The forward-slash trap that causes silent import failures. Complete Node.js packaging pipeline.

Builds on: Versioning and Source Control | Pipelines

AI Collaboration

What AI Gets Wrong About Power Platform (And Why That Is the Point)

Three architectural mistakes in the first 10 minutes. Real-time triggers when I needed digests. Embedded emails in business flows. Generic naming. All wrong. And yet, 14 production-ready flows by the end. This article is the honest assessment - what AI gets wrong, how human correction works, and why the 6-7x multiplier is real but not free.

Builds on: AI-Powered Flow Review

How This Connects to the Governance Series

This series is the proof layer for the 10-part Power Automate Governance series published earlier on az365.ai. The governance series teaches the theory. This series shows what happens when you apply it.

Governance Series (Theory)	Spec-Driven Series (Proof)
Naming Conventions That Scale	Tag-Based Flow Architecture (24 flows using the convention)
Flow Inventory	Full 24-flow inventory with tags, triggers, and purposes
Living Documentation in Git	Spec-First Development (specs in git, not Word docs)
Solution-Aware Flows	Notification Architecture (separate solutions for separate concerns)
Versioning and Source Control	Building Solution ZIPs (version-controlled flow JSON in git)
AI-Powered Flow Review	What AI Gets Wrong (honest AI collaboration assessment)
Pipelines - Dev to Prod	Solution ZIP packaging and import pipeline

The governance articles say “you should do this.” The spec-driven articles say “we did this, and here is what happened.”

The Case Study

All articles reference the same project: Meridian Performance Management at Apex Federal Solutions - a custom performance review system on Dataverse with a multi-step signing workflow. 24 Power Automate flows. 14 notification emails. 3 PCF controls. Built by one architect with AI assistance.

Reading Order

If you want the full story: Start with the Pillar, then read in any order.

If you want to implement this yourself: Tags first, then Specs, then the technical deep dives.

If you want the AI angle: Start with What AI Gets Wrong, then read the Pillar for full context.

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