Tag-Based Flow Architecture in Power Automate

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.

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.

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.

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.

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

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.

Notification Flows (Scheduled)

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

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)

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.

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:

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.

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:

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:

1. Tag-Based Flow Architecture - How 3-letter prefixes make a flow set manageable
2. Spec-First Development - Why specs should exist before the designer opens
3. Notification Architecture - Notifications that cannot break business logic
4. FetchXML in Power Automate - When OData $filter is not enough
5. Building Solution ZIPs - The undocumented packaging guide
6. What AI Gets Wrong - And why human correction is the point
7. 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.