Retry Failed Dataverse Operations via Queue

Overview

FlowLibs - Retry Failed Dataverse Operations via Queue is a scheduled Power Automate Cloud Flow that drains an Azure Storage Queue (the "retry queue") of payloads representing previously-failed Dataverse writes, attempts each one again, and applies a retry-counter-bounded escalation strategy when a write keeps failing. Successful retries are recorded into the configured Dataverse table (default tasks) and the message is removed from the queue. Failed retries are re-queued with an updated retry counter until the configured maximum is reached, at which point the payload is escalated to an Operations email and removed from the queue. A run-summary email is always sent at the end of every poll cycle, even when the queue is empty.

The flow ships in the Off state and uses Recurrence (built-in trigger, every 15 minutes, Eastern Standard Time) so that turning it on in a real environment requires only authorizing the three connection references and (optionally) overriding the five environment variable defaults.

Use Case

This flow is the consumer side of a "circuit-breaker plus retry queue" pattern that is increasingly common in mid-tier Power Platform integrations. The producer side — typically another Power Automate flow, a Logic App, or a custom application — pushes a JSON payload onto the configured Azure Storage Queue whenever a Dataverse write fails for a transient reason (HTTP 429 throttling, plug-in deadlock, brief connectivity loss, or a temporary Dataverse 5xx). Rather than failing the producer flow outright, the producer captures the payload (including the original error) and walks away; this consumer then transparently retries the work without coupling the producer to retry logic.

Concrete scenarios the flow is designed for: (a) high-volume Dataverse imports where a small percentage of records hit transient throttling and need to be tried again, (b) integration flows that push to Dataverse on a strict SLA where the producer cannot afford to wait for a successful write but the data must still land eventually, (c) any architecture where Dataverse writes are "fire-and-eventually-confirm" rather than synchronous, and (d) generic dead-letter retry pipelines where the dead letter queue isn't strictly terminal — most messages can succeed on a second or third attempt before genuine escalation.

The flow is ideal for teams that:

• High-volume Dataverse imports where a small percentage of records hit transient throttling and need to be tried again
• Integration flows that push to Dataverse on a strict SLA where the producer cannot afford to wait for a successful write but the data must still land eventually
• Architectures where Dataverse writes are "fire-and-eventually-confirm" rather than synchronous
• Generic dead-letter retry pipelines where the dead letter queue isn't strictly terminal

Flow Architecture

Environment Variables

Connectors & Connections

Note — All connections are referenced as solution connection references; the flow is portable between environments as long as a connection is mapped at import time.

Customization Guide

Almost every realistic variant of this flow can be implemented by changing environment variable values. A few cases require small edits inside the flow definition — those are called out explicitly below.

Different target table

Change flowlibs_RetryDataverseTableName to the entity-set (plural) name of your real table (e.g., accounts, contacts, flowlibs_orders). You will also need to edit the item/* slash-path parameters inside Retry_Create_Record so they match the columns of your target table — tasks exposes subject, description, scheduledend, prioritycode; your table will have its own. The env var binding is documentation-only; the action's entityName is hardcoded to tasks because variable-driven entity names produce false-positive Flow Checker errors. To switch table, also update the hardcoded entityName value in Code view.

Different polling cadence

Edit the Recurrence trigger's frequency and interval. For higher-throughput queues (>100 messages/hour), drop to Minute × 5; for low-volume retry queues, raise to Hour × 1.

Different retry budget

Adjust flowlibs_MaxRetryAttempts. Setting it to 1 disables retries entirely (every failed write escalates after one attempt). Setting it to 10 is reasonable for queues where Dataverse throttling is the dominant failure mode.

Key Expressions

The flow is intentionally light on Power Fx / WDL gymnastics — the heaviest expressions are the branch-name concatenation and the approval outcome check. They are listed below in the order they appear in the flow.

@coalesce(body('Get_Pending_Retry_Messages')?['QueueMessagesList']?['QueueMessage'], createArray())

@json(coalesce(items('For_Each_Pending_Message')?['MessageText'], '{}'))

@add(coalesce(body('Parse_Retry_Payload')?['retryCount'], 0), 1)

@equals(result('Try_Retry_Dataverse_Write')[0]['status'], 'Succeeded')

@greaterOrEquals(outputs('Compose_Current_Attempt_Number'), variables('varMaxRetryAttempts'))

@coalesce(result('Try_Retry_Dataverse_Write')[0]?['error']?['message'], '(no error captured)')