Nightly Reconciliation Split Between Cloud and Desktop

API calls belong in the cloud flow, not in the desktop flow. The custom connector handles OAuth token acquisition and refresh, respects the connector's throttling, and keeps credentials out of the interactive session. A desktop flow making raw HTTP calls would bypass the approved connector and the DLP control.

Boundary design:

• The scheduled cloud flow authenticates, pages through the 300 orders within the 100 calls/minute limit (use pagination and modest concurrency; 300 orders is well inside the budget), and writes one Dataverse row per order with status Pending. This is the durable work list and the audit trail in one artifact.
• The desktop flow is invoked per batch (or per item) to consume Pending rows, enter the adjustment into the warehouse client, and update each row to Posted or Failed with an error message.
• Keep the desktop flow's unit of work small so a failure loses one order, not the night.

If the cloud flow must call the desktop flow many times, prefer one call that processes a bounded batch over 300 separate calls - each invocation has overhead and a timeout, and 300 sequential desktop invocations will not finish by 03:00.

Write status to Dataverse as the single source of truth, and build the dashboard on that table.

• Every state transition updates the order row (Pending, Claimed, Posted, Failed, with AttemptCount, LastError, UpdatedOn). Because it is Dataverse, Power BI can read it with the Dataverse connector and refresh on a schedule for the 08:00 view.
• Add a near-real-time alert alongside the batch dashboard: a cloud flow triggered on row create/modify (Dataverse trigger with a filter on Status = Failed) posts to the operations Teams channel. That gives Finance same-night visibility without asking the desktop flow to send notifications itself - desktop flows should record state and let messaging be a cloud responsibility.
• Add a heartbeat: the scheduled flow writes a run record at start and finish; a separate flow alerts if no heartbeat appears by 04:00. That catches the failure mode where the flow never starts at all, which per-row status never reveals.

Do not send an email per order: 300 notifications is noise, and mailbox throttling becomes a new failure source. Aggregate the dashboard, alert on exceptions only.

Detect the pattern, not just the individual error. If three consecutive items fail with the same error code, the desktop flow should stop consuming new items rather than burn through the remaining 200 and mark them all failed - that would destroy the signal about which orders are genuinely bad.

Design:

• The desktop flow wraps the processing loop so that a systemic failure sets a circuit-breaker state on the queue (a Dataverse row or flag) and exits cleanly. Remaining rows stay Pending.
• Items already Posted are untouched, and because each row carries the order reference and the warehouse entry carries it as a reference too, the re-run checks for an existing adjustment before entering one. That is the duplication guard.
• The cloud flow uses a scope with Configure run after to implement try/catch: the catch branch records the error, notifies the operations channel, and schedules a retry. A Terminate with a failed status marks the run honestly instead of showing as succeeded.
• The morning re-run is just the same scheduled flow: it picks up remaining Pending rows, and the circuit breaker is reset explicitly by an operator after the warehouse system is confirmed healthy - not automatically, so a genuine system outage is not silently retried all night.

The judgement being tested: fail loudly and stop, rather than maximising items attempted.