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

Open your production Power Automate flow list right now. You have 20, maybe 30 flows. Can you tell which ones handle reviews? Which handle evaluations? Which are notification flows? Which fire on signing step changes?

If you can’t answer those questions in under five seconds, your flows don’t have an architecture. They have a list.

I built 24 cloud flows for a federal performance management system called Meridian at Apex Federal Solutions. Ten business logic flows. Fourteen notification flows. Three Dataverse entities. Two trigger types. Without a tagging system, this would have been unmanageable by flow twelve. With tags, every flow is findable, groupable, and batchable for AI generation.

This builds on the naming conventions I covered earlier. Naming tells you WHAT a flow does. Tags tell you WHERE it belongs in the architecture.

The Problem with Flat Flow Lists

Here’s what 24 flows look like without any organizational system:

• AssignEvaluator-Author
• AssignFirstSigner
• Author Past Due
• Author Past Due Supervisor Escalation
• Author Reminder
• ChainAdvance
• CreatePersonnelEvaluations
• Cycle Closed
• Cycle Launched
• EvalAccessTeam
• Evaluation Complete
• Form Assigned
• Ready for Acknowledgment
• Ready for Signature
• Rejection to Author
• Rejection to Previous Signers
• ResolveSigner
• ReviewAccessTeam
• Signer Heads-Up
• Signer Past Due
• Signer Past Due Supervisor Escalation
• StampSigningConfig
• StepAwaiting
• StepRejected

Twenty-four items in alphabetical order. No hierarchy. No grouping. You can’t tell which flows touch the same table, which are notifications vs. business logic, or which ones fire on a schedule vs. in real time.

When Sarah Chen, our Director of Talent Operations, submitted requirements for email notifications across the signing workflow, we went from 10 flows to 24 overnight. I knew immediately that a flat list would kill us. In Flow Inventory, I argued that discovery without classification is just a list. Tags are the classification layer.

The Tag System

Four three-letter tags organize all 24 flows by entity area:

Each tag maps to exactly one Dataverse entity area. REV flows only touch mrd_personnelreviewcycle. EVL flows only touch mrd_personnelevaluation. STP flows only touch mrd_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. Period. 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:

Meridian | [{TAG}{##}] {Description} - {Type}

Real examples from production:

• Meridian | [REV01] CreatePersonnelEvaluations - Business Logic
• Meridian | [EVL03] EvalAccessTeam - Business Logic
• Meridian | [STP01] ChainAdvance - Business Logic
• Meridian | [NTF-EMAIL-01] 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. If naming conventions tell you WHAT a flow does, tags tell you WHERE it belongs in the system.

Channel Suffixes for Notifications

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

• NTF-EMAIL - Email notifications (current, 14 flows)
• NTF-INAPP - In-app notifications (planned)
• NTF-TEAMS - Microsoft Teams adaptive cards (planned)

This wasn’t an afterthought. I designed the naming structure for channels that don’t exist yet. When the Teams integration ships, NTF-TEAMS-01 slots right 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 I open an ADO work item titled “EVL01: Assign evaluator on Draft status,” I know the exact flow it maps to, the exact table it touches, and the exact solution it lives in. When I open source control and see Meridian-EVL01-AssignEvaluator.json, same thing. One tag, one concept, across every tool. This only works when flows are solution-aware. Loose flows can’t be grouped or governed this way.

The Full Inventory

This is the complete Meridian flow inventory. Twenty-four flows, four tag groups, zero ambiguity.

Business Logic Flows (10 flows)

Look at the tag column. Without reading anything else, you can see the structure: 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 (12 flows)

All 12 run daily at 8:00 AM Eastern, weekdays only.

Notice the numbering gap: there is no NTF-EMAIL-05 or NTF-EMAIL-06 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 (2 flows)

These two flows fire immediately on rejection events. Everything else is batched into daily digests. That’s a deliberate design choice. If NTF-EMAIL-12 (supervisor escalation) fired in real time, a supervisor with 15 overdue evaluators would get 15 emails in the span of seconds. Daily digest, 8 AM, one email per supervisor. Tags make this distinction visible at the inventory level.

Why Do 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, and no prompt bloat from unrelated flows.

I built the 14 notification flows using parallel AI agent threads. Each agent received a batch of 3-4 flows from the same functional tag group:

Flows within a tag group share the same Dataverse table, the same query patterns, and the same recipient resolution logic. Agent 1 only needed context about mrd_personnelevaluation and author-facing email templates. Agent 2 only needed context about mrd_evaluationsigningstep and signer-facing templates.

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

This is the unique 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 Your Project

You don’t need a federal performance management system to use tags. Here’s how to start.

Step 1: Identify entity areas. Look at your Dataverse tables. Group flows by the primary table they trigger from or operate on. Each group gets a 3-letter tag. If you have flows for Accounts, Contacts, and Opportunities, your 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 you have notification flows that could span email, Teams, and in-app, use NTF-EMAIL, NTF-TEAMS, NTF-INAPP. If you only have email, still use NTF-EMAIL. You’ll thank yourself when the Teams channel arrives.

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 your ADO backlog, your architecture diagram, and your source control folder.

Step 5: Document the tag dictionary. Create a reference table that maps every tag to its entity area, Dataverse table, and flow count. Keep it in your solution documentation. Update it when you add flows. This is your 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. Print it. Pin it to your Teams channel. Put it in your repo README.

The Difference Tags Make

Here is the before and after, side by side:

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 24 flows. Completely different level of control.

Tags are not overhead. They are the cheapest architectural decision you will make on a Power Platform project. Four three-letter codes turned 24 unrelated flows into a system I can explain in one table.

If you want to see these tags in action 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 24 flows 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. 14 Flows in 10 Minutes - The full story

---

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