What it does

Action-by-action logs of a desktop flow run, stored in Dataverse and viewable from Monitor > Desktop flow runs in the Power Automate portal. There are two storage versions with different capacity and retention behaviour, plus optional screenshots on failure for diagnosing unattended runs nobody was watching.

Key facts

• Activation status at environment level has three settings: Enabled (default), On run failure, or Disabled. "On run failure" captures nothing for successful runs but gives you the full log — successful and failed actions — for any run that errors.
• Logs V1 (default) stores logs in the AdditionalContext field of the FlowSession table, as a blob, consuming Dataverse file capacity. It has a documented 32 MB ceiling, roughly 50,000 to 80,000 action log entries. Past that, further actions simply aren't recorded.
• Logs V2 stores logs in the FlowLogs elastic table, consuming Dataverse log capacity. Minimum 100,000 actions, up to around 10 million depending on the run. It also gives near-real-time progressive logging while the flow is still running.
• V2 retention is set by FlowLogs entity time to live in minutes, from one day up to 365 days, with 0 meaning forever. V1 has no automatic retention control.
• TTL changes only apply to records created after the change. Existing logs keep their original TTL — cut retention from 90 days to 7 and the old records still sit there for 90.
• Only V2 supports Dataverse auditing, Azure Synapse Link and advanced reporting. V1's blob field can't be parsed or synced.
• Verbosity levels apply to V2: Full (default), Debug, Custom, Warning, Error. Set as an environment default, overridable per flow — but a maker can only choose a level equal to or higher than the environment default, and the effective level is always the higher of the two.
• Logs V2 is only available for desktop flow runs started from a cloud flow through the desktop flow connector. Flows launched inside the Power Automate for desktop designer don't collect action logs at all.
• On error Add screenshot to logs in flow properties captures screenshots automatically when an action errors. Admins can block screenshot capture entirely with a machine registry entry, so confidential screen content never reaches Dataverse.
• Auto refresh on the desktop flow runs list only supports up to 50 runs. Load more and live updates switch off.

When to use / skip

Leave logs on and use V2 for anything running unattended in production — the V1 ceiling is genuinely reachable on a long RPA run, and hitting it means the log stops exactly when the interesting part happens. "On run failure" is a sensible middle setting for a high-volume estate where you're paying for capacity you never read. Turn screenshots on for unattended flows during stabilisation and think hard about leaving them on afterwards, because a screenshot of a failure is often a screenshot of customer data.

Configuration decisions

• V1, V2 or both. "Both" exists for debugging and consumes file and log capacity simultaneously, so it isn't a resting state.
• The V2 TTL, balanced against Dataverse log capacity — Microsoft's own sizing guide assumes roughly 3 KB per action.
• Environment default verbosity versus what individual flows need, remembering makers can only go higher, never lower.
• Whether screenshots on failure are allowed, and whether that's decided per flow or blocked at machine level by registry.
• Whether logging is Enabled, On run failure, or off, per environment.

Gotchas

• Switching log versions doesn't migrate anything. Old logs stay where they were, in the old format.
• The V1 32 MB ceiling fails silently. The run looks logged, the log just stops partway. On a long unattended flow that's exactly the wrong half.
• The TTL-only-applies-to-new-records behaviour catches people trying to reclaim capacity in a hurry. Cutting retention doesn't delete anything you already have.
• Bulk delete jobs aren't supported on the Flow Log table, and you can't view flow log records in the maker portal table browser, so cleaning up is awkward.
• Verbosity is a floor, not a ceiling. If the environment default is Full, a maker can't turn their noisy flow down.
• Don't point a Dataverse row-change trigger at FlowLog or FlowRun. Records are written every run, so you've built an infinite loop.
• Screenshots land in Dataverse and are visible in run details to anyone who can see the run. That's a data classification question, not a diagnostics one.

Consultant notes

• Move clients to V2 as part of any serious RPA engagement, and do the capacity sizing before you flip it. Dataverse log capacity is a different meter from file capacity and their entitlement may not cover it.
• Set the environment verbosity default low and let specific flows raise it. Full everywhere on a busy estate is an expensive way to store noise.
• Screenshots are the fastest way to diagnose an unattended failure and the fastest way to leak a customer record into Dataverse. Get a decision from the client's data protection owner, in writing.
• Remind the client that designer-launched runs produce no action logs. Testers reporting "no logs" are usually just running it locally.

---

Revisit when Dataverse long-term retention support lands for logs V2 — it's marked planned.