Deploying Unattended Desktop Flows at Enterprise Scale: Machine Group Load Balancing, Queue Management, and Run Concurrency Strategies in Power Automate

Introduction

Picture this: your RPA team has built thirty unattended desktop flows that process invoices, synchronize SAP records, and generate compliance reports across three business units. Everything works beautifully in your dev environment with two machines. Then you push to production. Suddenly flows are queuing for forty minutes, two bots are thrashing the same shared folder simultaneously, and your Finance VP is asking why the month-end close report that used to finish by 7 AM isn't done by noon.

This is the scaling problem. And it's not really a technical problem — it's an architectural one. Most Power Automate teams learn the individual pieces (machine registration, flow triggers, connection references) without understanding how those pieces interact under concurrent load. When you have five machines and fifty flows competing for them, the decisions you made during development — queue priority, concurrency limits, group membership, session management — stop being abstract settings and start being the difference between an RPA program that delivers business value and one that becomes a political liability.

By the end of this lesson, you'll understand exactly how Power Automate Desktop's unattended execution engine distributes work across machine groups, how queue management controls flow scheduling at runtime, and how to design concurrency strategies that prevent conflicts without sacrificing throughput. You won't just know what the settings do — you'll know why they exist, where they break down, and how to design around their limits.

What you'll learn:

• How machine group load balancing works internally and what "available machine" actually means to the dispatcher
• How to structure desktop flow queues, priorities, and timeout policies for predictable SLA delivery
• Concurrency strategies for flows that share resources (files, applications, database connections, licensed seats)
• Session isolation patterns to prevent one flow's failures from cascading into another
• How to monitor queue depth, machine utilization, and run duration at scale to detect drift before it becomes an outage

---

Prerequisites

This is an expert-level lesson. You should be comfortable with:

• Creating and running desktop flows in Power Automate Desktop — if you're newer to this, start with Attended vs Unattended RPA: Choosing a Run Mode and Configuring Machines in Power Automate first
• Registering machines and machine groups — covered in Managing Machines and Machine Groups for Scalable Unattended Automation in Power Automate
• Triggering desktop flows from cloud flows and understanding the parent-child relationship — see Triggering Desktop Flows from Cloud Flows: Passing Inputs and Returning Outputs
• Basic familiarity with Power Automate environments, connections, and solution-aware flows

---

How Machine Group Load Balancing Actually Works

Before you can design a good queuing strategy, you need to understand what happens in the milliseconds between "a flow run is triggered" and "a bot starts executing on a machine." Most documentation glosses over this, which is why most enterprise RPA deployments eventually hit scaling problems they can't diagnose.

The Dispatcher's Decision Logic

When a cloud flow triggers a desktop flow with Run Mode = Unattended, Power Automate's backend dispatcher does the following, in order:

1. Resolves the target. The trigger specifies either a machine or a machine group. If it's a machine group, the dispatcher considers all machines in that group.
2. Evaluates availability. A machine is "available" if it has the Power Automate machine runtime agent running, is connected to the Power Platform environment, has at least one open session slot (more on this shortly), and hasn't been put in maintenance mode.
3. Applies load balancing. Among available machines, the dispatcher selects the one with the fewest currently active runs. This is a simple least-connections algorithm — not CPU-based, not memory-based, just run count. If multiple machines tie on active runs, the selection is effectively random among them.
4. Queues if no capacity exists. If no machine in the group has capacity, the run enters the queue for that group. It waits there until a machine becomes available.
5. Applies queue timeout. If the run has been queued longer than the configured timeout (the "run queued" timeout), it fails with a timeout error before it ever executes.

Session Slots: The Real Capacity Constraint

Each machine can host multiple simultaneous unattended sessions. On Windows Server (which you should be running for production RPA), each Remote Desktop session can run one unattended flow simultaneously. The practical session limit depends on:

• Windows Server licensing mode (per-user CALs vs. per-device CALs)
• Machine RAM — each session carries overhead; 8–12 GB RAM per concurrent session is a conservative baseline for flows that drive heavy desktop applications
• Application licensing — if your flow opens SAP GUI, Microsoft Excel, or another licensed application, you may only be allowed a fixed number of simultaneous instances on a given machine
• Power Automate machine runtime configuration — the agent respects the session limit you configure in machine settings

The machine runtime agent manages sessions by creating or reusing Windows user sessions. When a flow run arrives:

• If a session for the configured Windows account already exists and is idle, the agent reuses it
• If no session exists, the agent creates a new one (RDP or console)
• If all allowed sessions are busy, the machine reports itself as at-capacity to the dispatcher

Machine Group Membership and Session Configuration

Practical machine group design follows a few non-obvious principles:

Homogenous groups work better than heterogeneous ones. If you put a 4-CPU/16GB VM alongside a 16-CPU/64GB VM in the same group, the dispatcher will distribute runs to them equally — meaning the smaller machine gets overloaded while the larger one sits comparatively idle. The dispatcher has no concept of machine weight.

Group by application dependency, not just by throughput. If Flow A requires SAP GUI and Flow B requires a legacy Oracle Forms application, putting both in the same machine group only makes sense if all machines in that group have both applications installed and licensed. If some machines have SAP and others have Oracle, you'll get intermittent "application not found" failures that look like selector errors but are actually availability mismatches.

Don't mix attended and unattended machines in the same group. A machine that's actively being used by a human (attended mode) will still register as "available" to the dispatcher for unattended runs if it has open session slots. This causes unattended flows to compete for resources on machines where humans are working, which creates obvious problems.

---

Designing Queue Policies That Honor Business SLAs

The queue is where your capacity planning meets your business requirements. Most teams configure the minimum viable queue settings — a 30-minute timeout, default priority — and then wonder why high-priority runs get stuck behind low-priority ones during peak periods.

Understanding Priority Levels

Power Automate desktop flow queues support four priority levels: High, Normal (default), Low, and First (available in some tenant configurations). Priority affects the order in which queued runs are dispatched to available machines. A High priority run queued 5 seconds after a Normal priority run will be dispatched first when a machine becomes available.

What priority does not do: it doesn't preempt running flows. If all three machines in your group are busy executing Normal priority runs, a High priority run arriving at that moment still has to wait. True preemption doesn't exist in Power Automate's desktop flow scheduler.

Practical priority assignment strategy:

Flow Category	Priority	Rationale
Time-critical financial closes, regulatory filing	High	Missing SLA has direct compliance or financial impact
Customer-facing order processing, SLA-bound workflows	High	External commitments
Standard operational processing (invoice matching, data sync)	Normal	Internal SLAs with some tolerance
Batch reporting, archival, non-urgent data loads	Low	Run when capacity is available
Maintenance flows, data cleanup, log rotation	Low	Background, no SLA

Run Queued Timeout vs. Run Execution Timeout

These two settings are conceptually distinct but frequently confused:

Run Queued Timeout (configured in the cloud flow trigger action): How long a run will wait in the queue for a machine to become available. If the run doesn't get dispatched within this period, it fails before execution even begins. The error type is FlowQueuedTimeout. This setting protects against unbounded queue growth — without it, a capacity shortage can create a queue that backs up for hours while every new run succeeds in being queued but no run actually completes.

Run Execution Timeout (configured in the machine runtime or enforced via cloud flow): How long a flow is allowed to run once it starts executing. A flow that hangs (waiting for an unresponsive UI element, stuck in a loop, holding a lock) will eventually be killed when this timeout expires.

Getting these settings right requires knowing your flow's performance profile:

1. Measure median and 95th percentile run durations for each flow over a two-week baseline period. Use the run history in Power Automate portal or pull data from the Dataverse flowsession table.
2. Set execution timeout to 3–4x the 95th percentile duration. This accommodates legitimate slowdowns (network latency, application startup spikes) without letting hung flows hold machine capacity indefinitely.
3. Set queued timeout based on your SLA, not on intuition. If your SLA says invoice processing must complete within 2 hours of trigger, and the median execution time is 20 minutes, your queued timeout must be under 100 minutes to guarantee the SLA can be met even in worst-case scenarios.

Handling Queue Overflow with Retry Logic

When a run fails due to queue timeout, the failure propagates back to the cloud flow as a run failure. Your cloud flow's error handling determines what happens next. The naive approach — letting the parent cloud flow fail — creates gaps in processing. The production approach uses explicit retry logic at the cloud flow level.

A robust pattern:

// Cloud Flow structure for queue-overflow-resilient triggering:

Trigger: [Your business trigger — Recurrence, HTTP, SharePoint item created, etc.]

Initialize Variable: RetryCount = 0
Initialize Variable: MaxRetries = 3
Initialize Variable: FlowSucceeded = false

Do Until: FlowSucceeded = true OR RetryCount >= MaxRetries
  
  Scope: Try Run Desktop Flow
    Run Desktop Flow (Unattended)
      Machine Group: [Invoice Processing Group]
      Desktop Flow: [Process Invoice]
      Priority: High
      Queued Timeout: 45 minutes
      
    Set Variable: FlowSucceeded = true
    
  Scope: Catch
    Condition: Error code contains 'QueuedTimeout' OR 'Capacity'
      
      Set Variable: RetryCount = RetryCount + 1
      
      Condition: RetryCount < MaxRetries
        Delay: 15 minutes  // Back off before retrying
        
      Else:
        // Send alert to operations team
        // Log failure to SharePoint / Dataverse
        // Consider fallback processing path

Condition: FlowSucceeded = false AND RetryCount >= MaxRetries
  Post Teams message: "Invoice [InvoiceID] could not be processed - manual intervention required"

The 15-minute delay between retries is deliberate. If the queue is overloaded because of a burst in trigger volume, retrying immediately just adds more pressure. A backoff gives the queue time to drain before your retry arrives.

---

Concurrency Strategies for Shared Resources

This is where unattended RPA at scale gets genuinely complex. Every concurrent execution path is a potential conflict. Let's work through the most common shared resource patterns and how to handle each.

File System Conflicts

If multiple flows read from and write to the same directory — especially if they generate files with predictable names like Output_[Date].xlsx or read from a shared input folder — concurrent execution will cause overwrites, locks, and corrupt outputs.

The pattern that works at scale is per-flow working directories with a handoff mechanism:

// At flow start, create an isolated working directory:
Get Current Date and Time → CurrentTimestamp
Get Environment Variable: COMPUTERNAME → MachineName
Set Variable: WorkingDir = "\\FileServer\RPA\InvoiceProcessing\Working\" + 
              MachineName + "_" + CurrentTimestamp.ToString("yyyyMMddHHmmss") + 
              "_" + FlowRunID

Create Folder: %WorkingDir%

// All file operations within this flow use %WorkingDir%
// At flow end, move outputs to a known pickup location and clean up:
Move Files from %WorkingDir% to "\\FileServer\RPA\InvoiceProcessing\Completed\"
Delete Folder: %WorkingDir%

The combination of machine name, timestamp, and flow run ID makes directory names unique across all concurrent executions even on the same machine. FlowRunID is passed in as an input variable from the parent cloud flow — if you're triggering from cloud, the cloud flow's run ID (available via @{workflow().run.name}) is a perfect unique identifier.

For flows that process items from a shared input folder, use a claim-and-lock pattern: the flow renames the input file by prepending PROCESSING_[MachineName]_ before working on it. If the flow fails, the operations team can see which files are stuck mid-processing and on which machine. Files whose claim prefix indicates a machine that's no longer running can be reclaimed.

Application Session Conflicts

For applications with limited licensing — SAP GUI, legacy ERP systems, specialized engineering software — you may have a hard cap on concurrent sessions across your entire RPA estate. If you have 10 SAP GUI licenses allocated to your RPA user accounts and 15 machines in your group, you can't run 15 flows simultaneously without exceeding your license agreement.

The solution lives in the cloud flow, not the desktop flow. Set the concurrency control on the trigger or on the scope containing the desktop flow run action:

For scheduled flows, configure the trigger concurrency in the trigger settings:

• Navigate to the trigger in your cloud flow
• Open Settings
• Enable "Limit the number of concurrent runs"
• Set the degree of parallelism to your license ceiling

For flows triggered by events (SharePoint item created, Dataverse row created), use a different approach: configure the cloud flow to place items into a Dataverse queue (or SharePoint list), and have a separate scheduled "dispatcher" cloud flow that processes queue items one (or N) at a time. This decouples trigger rate from execution rate, which is often what you actually want.

For a deeper look at how to structure the SAP-specific flow logic that these sessions will execute, see Automating SAP GUI Interactions with Power Automate Desktop: Navigating Transactions, Extracting Table Data, and Handling Session Errors.

Database and SharePoint Throttling

If your flows write results to SharePoint or query a shared database, concurrent runs will hit throttling limits. SharePoint Online enforces a limit of 600 requests per minute per site collection (with nuances around server-side throttling). A database with inadequate connection pooling will queue or reject connections under load.

For SharePoint, the mitigation is batching and jitter:

• Have each flow write results to a local file during execution, then make a single SharePoint write operation at the end
• Add a random delay (1–10 seconds) before the SharePoint write to spread out concurrent writes that happen to finish at the same time

// Add jitter before SharePoint write to prevent thundering herd:
Generate Random Number between 1 and 10 → JitterSeconds
Wait: %JitterSeconds% seconds
Write results to SharePoint list

For databases, use connection strings that specify a connection timeout and max pool size, and ensure your flow handles the Connection refused or Timeout expired errors gracefully with retry logic. The Error Handling in Desktop Flows: On Block Error, Retry Policies, and Recovery Screenshots lesson covers the mechanics of building that retry logic within the desktop flow itself.

---

Run Concurrency Architecture Patterns

Now that you understand the individual conflict types, let's look at how to assemble concurrency controls into a coherent architecture. There are three patterns you'll encounter in enterprise deployments, each appropriate for different scenarios.

Pattern 1: Machine Group as Capacity Pool (High Volume, Low Interdependency)

Use this when: your flows process independent items (individual invoices, individual customer records, individual PDF files) and don't share application-level resources beyond standard infrastructure.

Architecture:

• Single machine group sized for peak throughput
• Cloud flow trigger dispatches directly to machine group
• Concurrency control lives purely in machine group capacity (number of machines × sessions per machine)
• Queue acts as buffer during load spikes
• Flows write to isolated working directories as described above

This is the simplest pattern and works well for high-volume document processing, web automation pipelines, and multi-application workflows where each flow instance operates on entirely separate data.

Scale calculation:

Required Machines = CEILING(
  (Peak Hourly Trigger Volume × Average Run Duration in Hours) / 
  Sessions Per Machine
)

Buffer Factor = 1.3  // 30% headroom for spikes and reruns
Recommended Machines = Required Machines × Buffer Factor

For example: 120 invoice triggers per hour, 8-minute average run time (0.133 hours), 2 sessions per machine:

Required = CEILING((120 × 0.133) / 2) = CEILING(7.98) = 8 machines
Recommended = 8 × 1.3 = 10.4 → 11 machines

Pattern 2: Segmented Groups by Flow Type (Mixed Workloads)

Use this when: you have multiple flow types with different resource requirements, different SLAs, and different volume profiles that shouldn't compete for the same capacity.

Architecture:

• Multiple machine groups, each dedicated to a specific flow category
• Machines are assigned to groups based on installed software and allocated licenses
• Cloud flows target specific machine groups based on their category
• Each group is sized independently for its workload

A practical example:

Group Name	Machines	Applications Installed	Flows Served	Session Config
SAP-Processing-Group	4	SAP GUI, Excel	SAP data extraction, GL reconciliation	2 sessions/machine, 1 SAP account/session
Web-Scraping-Group	6	Chrome, Edge, Firefox	Competitor pricing, market data pulls	3 sessions/machine
Legacy-Systems-Group	3	Oracle Forms, custom apps	Legacy data migration, archive exports	1 session/machine (app constraint)
Reporting-Group	2	Excel, Word, SharePoint	Report generation, document assembly	2 sessions/machine

This pattern is more complex to manage but gives you precise capacity allocation. SLA-sensitive flows (SAP-Processing) don't compete with lower-priority web scraping runs. You can scale each group independently without overprovisioning everywhere.

Pattern 3: Priority Queues with Dedicated Surge Capacity

Use this when: you have predictable peak periods (month-end close, quarter-end reporting, regulatory deadlines) where you need to guarantee throughput for specific flows without permanently maintaining the infrastructure for those peak loads.

Architecture:

• Baseline machine group runs 24/7 at steady-state capacity
• "Surge" machines are pre-registered in the group but normally in maintenance mode
• A monitoring cloud flow (or Azure Logic App) watches queue depth in the baseline group
• When queue depth exceeds a threshold, the monitor brings surge machines out of maintenance mode via the Power Platform API
• After queue drains, surge machines return to maintenance mode

The queue depth monitoring uses the Dataverse flowsession table. A scheduled cloud flow runs every 5 minutes:

// Monitor flow - runs every 5 minutes:
List Rows from Dataverse: flowsession table
  Filter: statecode eq 2 AND statuscode eq 5  // Queued status
  Filter: _machinegroup_value eq [GroupID]
  
Count: QueuedRuns = length(body('List_Rows')?['value'])

Condition: QueuedRuns > 10  // Threshold for surge activation

  Yes:
    // Call Power Automate Management connector to remove surge machines from maintenance
    Send HTTP Request to Power Platform API:
      PATCH /api/data/v9.2/flowmachines([SurgeMachine1ID])
      Body: { "statecode": 0 }  // Set to active
    
    // Log surge activation to operational dashboard

  No:
    // Check if surge machines are active and queue has drained
    Condition: QueuedRuns < 2 AND SurgeMachinesAreActive
      // Return surge machines to maintenance mode

This pattern requires more orchestration investment upfront but can significantly reduce infrastructure costs by not running surge machines at full cost 24/7.

---

Session Isolation and Failure Containment

One of the underappreciated dimensions of enterprise unattended RPA is how failures in one flow run can affect other flows running concurrently on the same machine. If a flow crashes leaving an application in a bad state — a modal dialog open, a file locked, a database transaction uncommitted — the next flow that runs in the same session may inherit that broken environment.

Designing for Session Hygiene

Every unattended flow should begin with a session cleanup sequence before its main logic. This is not optional in production. The cleanup sequence:

1. Close all unexpected application windows. Use "Close Application" or "Kill Process" for any application your flow will open, ensuring you start fresh.
2. Clear temporary files from your flow's working directory from any previous runs.
3. Verify environment readiness. Check that required network shares are accessible, required applications are launchable, required credentials are valid.
4. Log the session state. Write a startup log entry that includes machine name, Windows user account, session ID, and flow parameters. This is invaluable for diagnosing failures post-hoc.

// Standard flow preamble - include in every unattended flow:
Get Environment Variable: COMPUTERNAME → MachineName
Get Environment Variable: USERNAME → ServiceAccount
Get Current Date and Time → FlowStartTime

Write Text to File:
  File Path: \\LogServer\RPA\Logs\%FlowName%_%MachineName%_%FlowStartTime%.log
  Text: "Flow started | Machine: %MachineName% | Account: %ServiceAccount% | 
         Input: %InputParameter% | Time: %FlowStartTime%"

// Clean up residual application state:
Kill Process: saplogon.exe → If Running
Kill Process: excel.exe → If Running  
Kill Process: chrome.exe → If Running

// Verify prerequisites:
If Not File Exists \\FileServer\RPA\Config\flow_config.json
  Write to log: "FATAL: Config file not found"
  Exit Flow with Error

Handling credentials in these preambles requires care — see Handling Credentials Securely in Desktop Flows: Sensitive Variables and Azure Key Vault for patterns that don't expose service account passwords in flow logs.

Isolating Failure Blast Radius

Even with good session hygiene, a flow that fails mid-execution can leave state behind. The key design principle is minimizing the blast radius of any single run failure:

Use subflows to encapsulate risky operations. A subflow that encounters a fatal error fails the subflow scope, not necessarily the entire flow. The main flow can catch that error, log the failure, clean up the partial state, and exit gracefully without leaving the session in an unknown state. The lesson on Subflows and Reusable Logic in Power Automate Desktop covers subflow error propagation in detail.

Always close applications in error handlers. If your flow opens SAP or Excel and then hits an error, your error handler must close those applications before exiting. A flow that exits while leaving applications open is a session pollution risk for the next flow.

Use error-safe file operations. Write to temp files first, then rename/move when the operation is complete. If your flow crashes mid-write, the incomplete file has a temp extension and won't be mistaken for completed output.

// Safe file write pattern:
Write Data Table to CSV:
  Data Table: %ProcessedData%
  File Path: %WorkingDir%\output_TEMP.csv

// Rename only after successful write:
Rename File:
  File Path: %WorkingDir%\output_TEMP.csv
  New Name: output_FINAL.csv

---

Monitoring Queue Health and Machine Utilization at Scale

You cannot manage what you don't measure. At enterprise scale, the RPA queue and machine utilization data that Power Automate generates needs to be surfaced in operational dashboards and tied to alerting thresholds — not just reviewed manually in the portal.

Data Sources for RPA Operations Monitoring

Power Automate stores run data in Dataverse. The key tables:

• flowsession: Every desktop flow run — status, start time, end time, machine, error details. This is your primary operations table.
• flowmachine: Registered machines and their current status.
• flowmachinegroup: Machine groups and their configuration.
• workflow: The flow definitions themselves.

You can query these tables directly via Dataverse connector in Power Automate cloud flows, or via OData from Power BI.

A Power BI-based operational dashboard should show at minimum:

Queue Health:

• Current queue depth by machine group (count of flowsession rows with statecode = 2, statuscode = 5)
• Average queue wait time over the last 24 hours (time between created and start of execution)
• Queue wait time percentiles (P50, P90, P95) by flow type and by hour of day
• SLA breach rate (percentage of runs where queue wait exceeded threshold)

Machine Utilization:

• Sessions in use vs. available by machine, updated every 5 minutes
• Machine uptime percentage over rolling 7-day window
• Runs completed per machine per day (to identify imbalanced dispatching)
• Machines currently in maintenance or error state

Run Performance:

• Success rate by flow and by machine group over 24h/7d/30d windows
• Run duration trend (a flow that's getting slower over time indicates a problem)
• Failure mode distribution (timeout vs. selector error vs. application error vs. queue timeout)

For the detailed mechanics of setting up this kind of monitoring infrastructure, see Monitoring and Troubleshooting Desktop Flow Runs at Scale.

Setting Up Operational Alerts

Build alerting into a scheduled cloud flow that runs every 15 minutes. Key alert conditions:

// Alert conditions to monitor:

1. Queue depth > [N] for > [threshold minutes]
   → "Machine group [X] queue is backing up. Current depth: [N] runs"
   
2. Any machine in group is in Error or Disconnected state for > 30 minutes
   → "Machine [MachineName] has been offline for 35 minutes. Manual check required."
   
3. Run duration for [FlowName] exceeds 2× baseline median
   → "Flow [FlowName] on [Machine] has been running for [duration] - possible hang"
   
4. Failure rate for any flow exceeds 20% over rolling 2-hour window
   → "Elevated failure rate detected for [FlowName]: 7/30 recent runs failed"
   
5. No successful runs of [CriticalFlow] in [expected_interval × 2] period
   → "Silence alert: [CriticalFlow] has not completed a successful run since [LastSuccess]"

Alert #5 — the "silence alert" or "dead man's switch" — is frequently overlooked and critically important. A flow that isn't running at all (because its trigger stopped firing, because the machine is down, because a configuration change broke the connection) is just as bad as a flow that's failing. You won't see failures in your failure rate monitoring because there are no runs to fail.

---

Hands-On Exercise: Building a Scalable Invoice Processing System

Let's synthesize everything from this lesson into a concrete architecture design exercise. You're the RPA architect for a financial services firm that needs to process up to 500 vendor invoices per business day. Each invoice arrives as a PDF in a SharePoint document library, needs to be opened, data extracted, validated against a lookup in a legacy system, and the results written back to SharePoint and a SQL database.

Given constraints:

• 3 Windows Server VMs available (VM1: 16GB RAM, VM2: 32GB RAM, VM3: 16GB RAM)
• Legacy system requires a licensed desktop client, 4 licenses allocated to RPA
• SharePoint throttling is a concern (previous incidents at 200 requests/hour)
• SLA: every invoice processed within 90 minutes of upload
• Business hours: 8 AM to 6 PM, Monday-Friday, with a peak at 9–11 AM (60% of daily volume)

Step 1: Size the machine group

Baseline metric collection (first week of deployment):

• Average run duration: 6 minutes
• 95th percentile run duration: 14 minutes
• Peak hourly volume: ~125 invoices in the 9–10 AM hour

Required capacity at peak:
  125 invoices × (6/60 hours per invoice) = 12.5 machine-hours needed per peak hour
  
Available sessions: VM1 (2 sessions) + VM2 (4 sessions) + VM3 (2 sessions) = 8 sessions
Legacy system license constraint: 4 concurrent sessions maximum

Effective capacity: min(8 sessions, 4 legacy licenses) = 4 concurrent sessions
Throughput at 4 concurrent: 4 × (60/6) = 40 invoices/hour sustained

At peak: 125 invoices in hour 1, clearing at ~40/hour → 
  Hour 1: 40 processed, 85 queued
  Hour 2: 40 processed, 45 queued  
  Hour 3: 40 processed, 5 queued → all clear by 11:10 AM

Max queue wait: arrives at 9 AM, processed by ~11:10 AM = 130 minutes
This VIOLATES the 90-minute SLA.

Step 2: Redesign to meet SLA

Option A: Get 2 additional legacy system licenses (cheapest if software cost < infrastructure cost) Option B: Add a fourth VM with 2 sessions and 2 additional licenses Option C: Reduce run duration through flow optimization (parallelizing the legacy lookup)

For this exercise, pursue Option C + partial Option A: optimize the flow to 4-minute average duration AND add 1 additional license (5 total concurrent):

Revised throughput: 5 sessions × (60/4 minutes) = 75 invoices/hour

Hour 1: 75 processed, 50 queued
Hour 2: 75 processed → all clear by 10:40 AM

Max queue wait: ~100 minutes for last item queued at 9 AM → 
Still misses SLA by 10 minutes.

Need either: 6 concurrent sessions OR reduce to 3.5-minute average duration.

This iterative capacity modeling is the real work of enterprise RPA architecture. The math is simple; the lesson is that you must do it before deployment, not after your SLA is in breach.

Step 3: Configure the cloud flow

// SharePoint trigger: When a file is created in /Invoices library

// Concurrency control on trigger: limit to 5 concurrent cloud flow runs
// (matching our 5 legacy system license ceiling)

Parse Invoice Filename → InvoiceID

Run Desktop Flow (Unattended):
  Machine Group: Invoice-Processing-Group
  Desktop Flow: Process Invoice - Unattended
  Priority: High
  Run Queued Timeout: 75 minutes  // 90-min SLA - 14-min max execution = 76 min headroom
  Inputs:
    SharePointFileURL: triggerOutputs()?['body/Path']
    InvoiceID: variables('InvoiceID')
    RunID: workflow().run.name

// Handle results:
Condition: Desktop flow run succeeded
  Update SharePoint item: Status = "Processed", ProcessedAt = utcNow()
  
Condition: Desktop flow run failed
  Update SharePoint item: Status = "Failed", FailureReason = result
  Post to Teams: Operations channel with failure details

Step 4: Implement monitoring

Create a Power Automate cloud flow (scheduled, every 15 minutes) that:

1. Queries Dataverse flowsession for queue depth on Invoice-Processing-Group
2. Calculates current queue wait time based on oldest queued run's created timestamp
3. Alerts via Teams if queue wait > 45 minutes (gives 45 minutes of runway before SLA breach)
4. Checks for silence: if no successful run completed in the last 30 minutes during business hours, alert the operations team

---

Common Mistakes and Troubleshooting

"My flows queue correctly but then fail immediately when dispatched"

This usually indicates the machine appeared available to the dispatcher but couldn't actually start the session. Check:

• The machine agent service is running on the target machine (Power Automate machine runtime in Windows Services)
• The Windows user account for the unattended session has "Log on as a batch job" rights
• The machine agent's local configuration hasn't lost its environment connection (re-register if needed)
• The RDP port (3389) is not blocked between the Power Platform backend and the machine — if your VMs are in a private subnet, this is a common firewall issue

"Queue depth builds up even though machines show available"

The dispatcher may be seeing machines as available but their sessions as in-use. Use the Power Automate portal's machine detail view to see actual session allocation. If sessions are shown as consumed by flows that aren't actively running, you likely have zombie sessions. Clear them by:

1. Killing the UIFlowService process on the machine
2. Restarting the Power Automate machine runtime service
3. Signing out all RDP sessions associated with RPA user accounts

"Load balancing is not working — all runs go to the same machine"

If your machine group has machines that registered at very different times, or if one machine was recently restored from maintenance mode, the dispatcher may favor the machine with the longest "available" track record. This is a known behavioral tendency in the dispatcher's machine selection. Mitigation: restart the machine runtime agent on under-utilized machines to reset their availability state in the dispatcher's view.

"Flows work fine individually but fail when running concurrently"

This is almost always a shared resource conflict. Enable verbose logging in your flows (write to log at every major step) and run two instances simultaneously, then compare timestamps to find where they start interfering. Common culprits: same temp file paths, same Excel workbook opened by multiple instances, UI automation targeting windows by title when multiple windows of the same application are open. The UI Elements and Selectors in Power Automate Desktop: Building Automations That Don't Break lesson covers selector strategies that remain stable under concurrent execution.

"My machines drift — some accumulate failures over time while others stay clean"

Machine-specific failure accumulation suggests that machine's environment has diverged from the baseline (Windows updates applied, application version different, disk space low, temp folder full). Implement a maintenance window policy: weekly, take each machine out of the group for 30 minutes, run a PowerShell housekeeping script (temp folder cleanup, log rotation, disk health check, application version verification), and put it back in rotation. Automate this with a maintenance cloud flow that uses the Power Platform API to cycle through machines.

---

Summary and Next Steps

Deploying unattended desktop flows at enterprise scale is fundamentally an architectural discipline. You've now built a mental model of how the dispatcher selects machines, how the queue manages runs when capacity is saturated, and how concurrency conflicts at the file, application, and database level require different mitigation strategies.

The key principles to take away:

• The load balancer is capacity-blind. It distributes by run count, not by resource consumption. Application-level concurrency controls must live in your cloud flow architecture.
• Queue timeouts are SLA contracts. Set them based on your business requirements and measured performance baselines, not defaults.
• Session hygiene prevents cascading failures. Every unattended flow must clean up before and after itself, and your error handlers must release resources before exiting.
• Monitoring is not optional. Queue depth, machine utilization, run duration trends, and silence alerts are the operational foundation that lets you know you're within SLA before your stakeholders notice you're not.

For your next steps, go deeper on the operational side with Monitoring and Troubleshooting Desktop Flow Runs at Scale, and then look at how solution-aware flow deployment across environments interacts with machine group registration in Deploying and Managing Power Automate Solutions Across Environments. If your flows involve complex parallel processing patterns at the cloud layer that feed into your unattended execution, Implementing Parallel Branching and Concurrency Control in Power Automate will help you design the upstream orchestration layer that pairs with everything covered here.

The robots are ready. Make sure the architecture is too.