Configuring Dataverse Table Queues and Routing Rules in Model-Driven Apps: Managing Work Assignment, Queue Item Lifecycles, and Team-Based Record Distribution

Introduction

Picture this: your customer service team has 200 open cases, three regional support teams, and zero visibility into who's working on what. Agents are stepping on each other's toes, high-priority tickets are aging in the inbox, and the team lead is manually reassigning records in a spreadsheet at 5 PM every Friday. This is the exact problem Dataverse queues were built to solve — and when configured correctly, they transform chaotic shared inboxes into structured, auditable work pipelines.

Queues in Dataverse are more than a holding pen for records. They're a full work management system: records enter a queue as queue items, agents pick them up explicitly (marking ownership and preventing double-handling), and the lifecycle of each item is tracked from arrival to resolution. Combined with routing rules, you can automatically direct incoming records to the right queue based on any combination of field values — no manual sorting required. Layer on team-based distribution and you have a complete, scalable assignment engine built entirely within Power Apps.

By the end of this lesson you'll have the knowledge and hands-on experience to design and configure a queue-based work distribution system for a real-world scenario. We'll use a customer support case management context throughout — relatable to nearly every organization — but the patterns apply equally to field service work orders, loan applications, IT incidents, or any high-volume record processing flow.

What you'll learn:

• How Dataverse queues work, what queue items are, and which tables can be queue-enabled
• How to create and configure queues, including private vs. public access and email integration settings
• How to build routing rules that automatically assign records to queues based on field logic
• How to manage queue item lifecycles: pick-up, reassignment, release, and removal
• How to design team-based queue structures that distribute work fairly across organizational units

---

Prerequisites

You should be comfortable with model-driven app fundamentals before diving in. Specifically:

• You understand Dataverse tables, columns, and relationships well enough to recognize how tables relate to each other
• You've built or navigated a model-driven app and can find your way around the Power Apps maker portal
• You have a working understanding of Dataverse security roles, business units, and teams, because queue access is entirely security-role-driven
• You have a System Administrator or System Customizer role in your environment to follow along with configuration steps

---

Understanding Queues and Queue Items

Before touching any configuration, let's establish exactly what's happening under the hood. This distinction matters because most queue-related frustrations come from misunderstanding the data model.

The Queue Table and the Queue Item Table

Dataverse has two separate system tables at play:

Queue (queue) — This is the container. Think of it like a mailbox or tray. It has a name, an owner, a type (public or private), and optionally an email address for inbound routing. A queue doesn't hold records directly.

Queue Item (queueitem) — This is the wrapper. When a record (like a Case) is added to a queue, Dataverse creates a Queue Item record that links the queue to that record. The Queue Item is where all the work-state metadata lives: which worker picked it up, when it was created, and what its current status is.

This distinction is crucial. The underlying Case record doesn't change ownership when it enters a queue. The Queue Item is the ephemeral assignment mechanism. You can have the same Case record appear as a queue item in multiple queues simultaneously (though this is generally inadvisable in practice — more on that in the troubleshooting section).

Which Tables Can Be Queue-Enabled?

Out of the box, certain system tables are already queue-enabled: Case (Incident), Activity types (Email, Phone Call, Task, etc.), and a few others. For custom tables, you need to explicitly enable queue support in the table settings.

To enable a custom table for queues:

1. Open make.powerapps.com and navigate to Tables in the left panel
2. Open your target table (for example, a custom Support Request table)
3. Select the table and choose Properties from the command bar
4. Under Advanced options, locate the Queues section and check Can be added to a queue
5. Save the table

Once a table is queue-enabled, you'll see a Add to Queue button appear on records of that type in model-driven apps, and Power Automate flows can route records to queues programmatically.

---

Creating and Configuring Queues

Now let's build some queues. We'll use a scenario: a software company with three support tiers — Tier 1 (general inquiries), Tier 2 (technical issues), and Tier 3 (enterprise escalations). Each tier has a team of agents and needs its own queue.

Queue Types: Public vs. Private

When you create a queue, the first meaningful decision is its type:

• Public queues are visible to anyone with queue read privileges. Agents can see the queue, browse its items, and pick up work. This is the right choice for shared team queues.
• Private queues are visible only to the queue owner and those explicitly added as queue members. This suits personal queues or manager-review queues that shouldn't be browsed by the whole team.

For team-based work distribution, you almost always want public queues.

Creating a Queue Step by Step

Navigate to your model-driven app, then to Settings > Advanced Settings > Service Management > Queues — or alternatively through the Customer Service Hub if your environment has it. In some environments, you'll find queues in the Service module of the classic interface.

A cleaner path for makers is directly through the maker portal:

1. Open make.powerapps.com
2. Go to Solutions, open your working solution
3. Select New > More > Queue (if available in your solution context)

Or via the model-driven app runtime:

1. Open a model-driven app that includes the Queues area (Customer Service Hub has this natively)
2. Navigate to Service > Queues
3. Select New from the command bar

Fill in the queue form:

Field	Tier 1 Queue Example	Notes
Name	Tier 1 - General Support	Descriptive, includes the tier
Type	Public	Visible to all agents with queue access
Owner	Tier 1 Support Team	Can be a team or user
Incoming Email	tier1@support.contoso.com	Optional — enables email routing
Description	General inquiries, billing, account access	Helps agents know what belongs here

Repeat this for Tier 2 and Tier 3 queues, adjusting ownership to the appropriate team record in your environment.

Adding Members to a Queue

For public queues, membership determines who gets notified and who can pick items from the queue when using certain routing configurations. To add members:

1. Open a queue record
2. Look for the Queue Members subgrid (may require scrolling or navigating a tab, depending on your form layout)
3. Use Add Existing User to add individual agents, or reference a team

In practice, for team-based distribution you'll typically assign queue ownership to an owner team in Dataverse rather than adding individual members — this way, when team membership changes (someone joins or leaves), the queue doesn't need reconfiguration. Team ownership is the more maintainable pattern at scale. If you need a refresher on how Dataverse teams are structured, see the article on Dataverse Security: Business Units, Security Roles, and Teams.

---

Building Routing Rules

A routing rule is the mechanism that automatically moves records into queues when certain conditions are met. Without routing rules, agents or flows must manually add records to queues — which works for simple scenarios but doesn't scale.

Anatomy of a Routing Rule Set

Routing in Dataverse is organized as Routing Rule Sets, each containing one or more Rule Items. The structure looks like this:

Routing Rule Set: "Case Routing - Standard"
├── Rule Item 1: Enterprise accounts → Tier 3 Queue
├── Rule Item 2: Technical issues, severity High → Tier 2 Queue
├── Rule Item 3: All remaining cases → Tier 1 Queue

Rule items are evaluated in order, and processing stops at the first matching rule. This means you put your most specific rules first and your catch-all rule last — just like a series of if/else if statements.

Only one Routing Rule Set can be active at a time per entity. If you need different routing logic for different scenarios (e.g., business hours vs. after-hours), you'll need to activate/deactivate rule sets via Power Automate or handle the branching within a single rule set using conditions.

Creating a Routing Rule Set

Navigate to Settings > Service Management > Routing Rule Sets (in the classic interface), or find it under Customer Service Hub > Service Management.

1. Select New
2. Give the rule set a meaningful name: Case Routing - Tier Assignment
3. Set the Entity (table) to Case (or your queue-enabled custom table)
4. Save the record — this activates the Rule Items subgrid

Adding Rule Items

Select Add Rule Item from the subgrid or command bar. Each rule item has:

• Name — descriptive label for this rule
• Conditions — the filter logic that triggers this rule
• Route To — which queue this record should go to
• Assign To — optionally assign to a specific user or team as well

Let's configure our three rules:

Rule Item 1: Enterprise Accounts → Tier 3

Conditions:

Account: Customer Type = Enterprise
OR
Case Priority = Critical

Route To Queue: Tier 3 - Enterprise Escalations Order: 1

Rule Item 2: Technical Issues, High Severity → Tier 2

Conditions:

Case Type = Technical Issue
AND
Case Priority = High

Route To Queue: Tier 2 - Technical Support Order: 2

Rule Item 3: Catch-All → Tier 1

Conditions: (leave empty — matches everything)

Route To Queue: Tier 1 - General Support Order: 3

Activating the Routing Rule Set

Once your rule items are saved, return to the Routing Rule Set record and select Activate from the command bar. You'll see the status change to Active. Only one rule set per entity can be active — activating a new set automatically deactivates the previous one.

To trigger routing, you can:

• Use the Apply Routing Rule button that appears on individual Case records
• Configure the system to automatically apply routing when a case is created (via a Power Automate flow or a classic workflow that calls the ApplyRoutingRule action)
• Use the Automatic Record Creation and Update Rules feature if you're routing email-originated cases

---

Queue Item Lifecycles: Pick, Release, and Remove

Understanding the queue item lifecycle is what separates a well-run queue system from one that just feels like another record list. The lifecycle has four key states:

1. Entry — Record Added to Queue

When a record is routed to a queue, Dataverse creates a Queue Item record. At this point:

• Worked By field is empty (unassigned)
• Status is active
• The queue item appears in the queue's view for any member to pick up

2. Pick — Agent Claims the Item

An agent navigates to the queue, finds the item, and selects Pick from the queue item record or the queue view. When an item is picked:

• The Worked By field is set to the picking agent's user record
• The item is effectively "claimed" — other agents can see it's being worked
• The underlying Case record ownership does not automatically change (this is configurable, but off by default)

This explicit pick mechanism is what prevents two agents from unknowingly working the same case — a critical safeguard in any shared queue environment.

3. Release — Agent Returns the Item

If an agent picks an item and then realizes they can't handle it (wrong expertise, needs escalation, etc.), they can Release it. Releasing:

• Clears the Worked By field
• Returns the item to the unassigned pool for others to pick
• Does not remove the item from the queue

4. Remove — Item Leaves the Queue

When work is complete (or the record is resolved/closed), the queue item should be removed. This happens:

• Automatically when the underlying record's status changes to a "resolved" state (for Cases, closing a case removes it from queues)
• Manually via the Remove button on the queue item
• Via Power Automate when custom business rules determine the item's lifecycle is complete

Viewing Queue Items in the App

To expose queues and queue items in your model-driven app, you need to add the Queues area to your site map. In the site map editor:

1. Add a Group for "Work Management" or similar
2. Add a Subarea with entity type Queue, or use the built-in Queues subarea if you're working within the Customer Service Hub

Configure a view that shows queue items filtered to the current user's queues. This is usually done with a "My Work" style view using the Worked By (Me) and queue membership filters.

For a well-designed queue management experience, you typically want three views:

• All Items in My Queues — everything unworked across all queues the user belongs to
• Items I'm Working — items where Worked By = Current User
• All Items in [Specific Queue] — a manager view showing all items in a queue regardless of assignment

---

Team-Based Queue Distribution

Individual queues are useful, but the real power comes from structuring queues around owner teams in Dataverse. This enables several patterns that individual user assignment simply can't match.

Pattern 1: One Queue Per Team (Tier-Based)

This is the pattern we've been building: each functional team owns a queue. Work is routed to the queue, and any team member can pick items. This model:

• Scales naturally as teams grow (add members without touching queue config)
• Gives managers a single place to see all unworked items for their team
• Allows cross-team visibility for escalations without reassigning records

Pattern 2: Round-Robin Distribution via Power Automate

Dataverse doesn't have a native round-robin assignment engine, but you can build one. When a queue item is created in the Tier 1 queue:

1. A Power Automate flow triggers on Queue Item creation
2. The flow retrieves all active members of the Tier 1 team
3. It looks up a custom counter column (or uses a formula-based approach) to identify the next agent in rotation
4. It sets the Worked By field on the queue item directly via the Dataverse connector's Update Row action
5. It increments the counter

// Simplified Power Automate expression for round-robin index
// Assuming 'agentList' is an array of user IDs from team members
// And 'currentIndex' is stored in a configuration table

mod(outputs('Get_current_index')?['body/cr_roundrobinindex'], length(variables('agentList')))

This is more reliable than trying to balance by record count in real time, and it's auditable.

Pattern 3: Skill-Based Routing with Team Subsets

For organizations with complex routing needs, you can extend the routing rule approach by creating skill-specific queues and mapping agents to queues based on their certifications or product expertise.

Example: Within Tier 2 Technical Support, you have agents who specialize in Product A vs. Product B. Create sub-queues:

• Tier 2 - Product A
• Tier 2 - Product B

Add a custom column to your Case table: Product Area (choice column with values Product A, Product B, Other). Then add routing rule items that branch on this column before the general Tier 2 rule.

This is also where model-driven app security roles and team-based access intersect with queue design. Product A specialists should only see Product A queue items by default — configure their default views and security appropriately.

Pattern 4: Geographic or Business Unit Distribution

If your organization is structured regionally, you can route based on account geography. Add a lookup to a Region table on your Case, or use the related Account's address fields:

Routing rule conditions:

Related Account: Region = "North America"  → North America Support Queue
Related Account: Region = "EMEA"           → EMEA Support Queue
Related Account: Region = "APAC"           → APAC Support Queue

This pairs naturally with Dataverse's business unit structure. If each region is its own business unit, teams and queues align cleanly with the organizational hierarchy. For background on how that hierarchy works, revisit Dataverse Security: Business Units, Security Roles, and Teams.

---

Surfacing Queue Management in the Model-Driven App

Configuration is only half the job. Your agents need a usable interface to interact with queues daily.

Forms: Adding Queue Information to Case Forms

On the Case main form, add a Queue Item quick view form or a label showing the current queue. Since the queue item is a separate table, you can't add it as a simple field on the Case form natively — but you have two good options:

1. Quick View Form: Create a quick view form for the Queue Item table and add it to the Case form in a "Work Assignment" section. This requires a relationship between Case and Queue Item, which exists as a system relationship (queueitem.objectid → incident.incidentid).

2. Subgrid: Add a Queue Items subgrid to the Case form showing related queue items. This gives the agent and manager full context: which queues the case is in, who's working it, and when it was added.

For form design guidance, the article on designing model-driven forms with sections, tabs, subgrids, and quick view forms covers the mechanics of adding these components.

Views: Building the Queue Worklist

A queue worklist view should be the agent's primary daily interface. Configure it as follows:

• Table: Queue Item
• Columns: Case Title (from related Case), Priority, Customer (from related Account), Date Entered Queue, Worked By, Age (calculated as days since queue entry)
• Default sort: Priority descending, then Date Entered ascending (oldest high-priority items first)
• Filter: Queue = [specific queue or queue membership of current user]

For the Age column, use a calculated column on the Queue Item table that computes Today() - Created On in days. This gives agents and managers instant visibility into SLA risk without manual calculation.

Dashboards: Queue Health at a Glance

Build a dashboard that shows:

• Queue volume by queue (bar chart: Queue Name vs. Count of Active Queue Items)
• Average age by queue (useful for SLA monitoring)
• Items worked by agent this week (encourages throughput transparency)
• Unworked items by priority (identify stuck high-priority cases)

This kind of operational visibility is exactly what makes a queue system valuable to leadership — not just the agents using it day to day.

---

Hands-On Exercise

Let's build a working queue configuration from scratch. This exercise takes approximately 45–60 minutes in a developer environment.

Scenario

You work for a software company called Contoso Solutions. The customer support team is split into two tiers. Tier 1 handles billing and account issues; Tier 2 handles technical product problems. Cases come in via email and the web portal. You need automatic routing and a clean agent worklist.

Step 1: Enable the Case Table for Routing (It's already enabled by default, but verify)

1. Open make.powerapps.com → Tables → Case (Incident)
2. Verify that in table properties, the queue option is enabled. For Cases, it is — skip to Step 2.

If you're using a custom table instead, enable queues in table properties as described earlier.

Step 2: Create Two Teams

1. Open the model-driven app in your environment (Customer Service Hub or any app with the Teams area)
2. Navigate to Settings → Security → Teams (classic interface) or find Teams in your admin area
3. Create Tier 1 Support Team — type: Owner team, business unit: your root BU
4. Create Tier 2 Technical Team — same setup
5. Add at least two users to each team (or add yourself to both for testing)

Step 3: Create the Queues

Create two queues:

• Name: Tier 1 - Billing & Account, Type: Public, Owner: Tier 1 Support Team
• Name: Tier 2 - Technical, Type: Public, Owner: Tier 2 Technical Team

Step 4: Create the Routing Rule Set

1. Navigate to Settings → Service Management → Routing Rule Sets
2. Select New
3. Name: Case Tier Routing, Entity: Case
4. Save and add two rule items:
   • Rule 1: Condition Case Type = Question OR Case Type = Request, Route To: Tier 1 - Billing & Account, Order: 1
   • Rule 2: (no condition — catch-all), Route To: Tier 2 - Technical, Order: 2
5. Activate the rule set

Step 5: Create a Test Case and Apply Routing

1. Create a new Case: Title = "Cannot access billing portal", Case Type = Question
2. Save the case
3. From the command bar, select Apply Routing Rule (or look for Add to Queue if routing rules aren't surfaced)
4. Verify a Queue Item appears in the Tier 1 - Billing & Account queue

Step 6: Pick the Queue Item

1. Navigate to Service → Queues → Tier 1 - Billing & Account
2. Select the queue item
3. Click Pick from the command bar
4. Verify your user appears in the Worked By column

Step 7: Build the Worklist View

1. Open the Views area for the Queue Item table in the maker portal
2. Create a new view: My Active Queue Items
3. Add columns: Subject (from related record), Queue Name, Date Entered, Worked By, Priority
4. Add filter: Worked By = Current User AND Status = Active
5. Save and publish

Congratulations — you now have a functional, routed, assigned queue system.

---

Common Mistakes & Troubleshooting

Mistake 1: Forgetting to Activate the Routing Rule Set

Symptom: Creating cases and expecting automatic routing, but records aren't appearing in queues.

Cause: The routing rule set is in Draft status.

Fix: Open the rule set and select Activate. Verify status shows Active before testing.

Mistake 2: Routing Rules in Wrong Order

Symptom: Enterprise cases are routing to Tier 1 instead of Tier 3.

Cause: The catch-all rule (no conditions) is listed before the specific rules.

Fix: Reorder rule items so catch-alls are always at the highest order number. Rule items with no conditions match every record, so they must come last.

Mistake 3: Same Record in Multiple Queues

Symptom: The same Case appears in both Tier 1 and Tier 2 queues, confusing agents.

Cause: Routing was triggered twice, or manual "Add to Queue" was used in addition to automatic routing.

Fix: Understand that Dataverse allows a record in multiple queues simultaneously — there's no system enforcement of single-queue membership. If your business rules require single-queue assignment, add a Power Automate flow that removes queue items from other queues when one is picked. Alternatively, build a business rule or server-side logic to prevent the second addition.

Mistake 4: Security Roles Not Granting Queue Access

Symptom: Agents can't see queues or queue items despite being team members.

Cause: The security role assigned to agents doesn't include privileges on the Queue and Queue Item tables.

Fix: In the security role editor, ensure the role has at least Read access to Queue (at Business Unit or Organization level) and Read/Write/Create access to Queue Item. The default Customer Service Representative role in Dynamics 365 environments handles this correctly — use it as a reference. More on this in the model-driven app security article.

Mistake 5: Routing Rules Not Re-Triggering on Record Update

Symptom: A case priority changes to Critical but doesn't move to the Tier 3 escalation queue.

Cause: Routing rules only fire when explicitly triggered — not on record updates by default.

Fix: Build a Power Automate cloud flow triggered on "When a row is modified" for the Case table, filtered to when Priority changes. Include a Dataverse action to call the ApplyRoutingRule message, passing the Case record ID. This automates re-routing on significant field changes.

Mistake 6: Queue Items Not Cleaning Up After Case Resolution

Symptom: Resolved cases still show as active queue items, polluting the worklist.

Cause: For system tables like Case, Dataverse automatically deactivates queue items when the case is resolved. For custom tables, this isn't automatic.

Fix: For custom queue-enabled tables, add a Power Automate flow that removes (deactivates) queue items when the record reaches its terminal status. Use the Remove Queue Item Dataverse action or update the Queue Item's status to Inactive directly.

---

Summary & Next Steps

Queues and routing rules are genuinely one of the most underutilized features in the Power Platform ecosystem. When configured well, they give your organization:

• Structured work assignment with explicit pick mechanics that prevent double-handling
• Automatic routing that removes the manual triage burden from team leads
• Auditable history of every record's journey through your queues
• Team-based scalability where adding people to a team automatically extends queue access

The key mental model to internalize: queues hold queue items, not records. The queue item is the assignment artifact — it's what agents pick, release, and complete, while the underlying record follows its own lifecycle independently.

From here, consider these logical next steps:

Extend with Power Automate: Build flows that re-route on field changes, implement round-robin assignment, and send notifications when high-priority items age beyond SLA thresholds.

Add Business Process Flows: Queue-based work pairs beautifully with business process flows that guide agents through the steps required to resolve each type of queue item. Link the BPF stage to queue item state for a seamless guided experience.

Build Analytics: Create queue health dashboards showing volume trends, agent throughput, and SLA adherence. The Queue Item table's history makes this straightforward with standard chart and list components.

Consider Unified Routing: If you're in a Dynamics 365 Customer Service environment, explore Unified Routing — Microsoft's newer, more powerful routing engine that builds on the queue concepts here with ML-based skill matching, capacity management, and analytics. It uses the same queue tables but extends the routing logic significantly beyond what rule sets can do.

The patterns you've configured in this lesson form the conceptual foundation for that entire tier of functionality. Master this, and unified routing's additional capabilities will make immediate sense.