What it does

Run history is the per-flow list of executions in the maker portal, with the inputs and outputs of every action available for inspection. Resubmit takes a previous run and executes the flow again with the same trigger data.

Key facts

• The portal shows a 28-day run history per flow. That's the window you get in the maker experience.
• Separately, solution cloud flows can write run records to the FlowRun elastic table in Dataverse, where retention is controlled by FlowRunTimeToLiveInSeconds on the Organization table. The admin centre offers 28 days (default), 14, 7 or Disabled; custom values can be set directly on the field.
• The Dataverse copy is a summary — start, end, duration, status, trigger type, error code and message, owner, workflow, parent run ID — not the full inputs and outputs.
• The Dataverse stream isn't transactional and isn't lossless. The portal's own run history is transactional and is the authoritative view.
• You can resubmit or cancel up to 20 runs at a time from the Run history page.
• Users can always resubmit their own runs from instant triggers. Letting them resubmit runs started by other users needs the Power Automate flow run resubmission tenant setting turned on in the admin centre.
• Bulk cancel handles everything in Running or Waiting state at once. Runs move Waiting → Canceling → Canceled, and the process can take up to 24 hours.
• If a flow is turned off, pending cancellations stay in Waiting and the queue doesn't clear until it's turned back on.
• If the flow is throttled, the queue stays stuck until capacity is added — Process licences add capacity per flow and can be stacked.
• You can add trigger-output columns to the run history view so you can identify the run you want without opening each one.

When to use / skip

Run history is your first stop for any single failure and it's usually enough. Resubmit is the right move for transient failures — 500s, 502s, an expired connection you've just repaired — and the wrong move for anything that already did half its work. The honest test before you click it: if this flow ran twice from the same trigger data, what would exist twice at the end? If you can't answer that quickly, don't resubmit, fix forward instead.

Configuration decisions

• Whether run history in Dataverse is on, and at what retention, weighing audit value against Dataverse storage consumption.
• Whether the tenant allows cross-user resubmission of instant-trigger runs, which is a real permission grant, not a convenience toggle.
• Which trigger outputs you surface as columns on the run history view, decided per flow at build time.
• Whether flows are designed to be safely resubmittable — idempotency keys, existence checks before create — or explicitly aren't.
• Where the long-term audit record lives if 28 days isn't enough, which usually means Dataverse, Application Insights, or your own logging.

Gotchas

• Resubmit replays the original trigger data against the current flow definition. Fix the flow, resubmit an old run, and you're running new logic against stale inputs — which is often exactly what you want and occasionally a disaster.
• There's no partial resubmit. It runs from the top. Everything before the failing action happens again.
• The number of runs you can resubmit is bounded by the connectors' API call limits, so a bulk resubmit can throttle itself.
• Runs that exceeded the concurrency limit sit in Waiting alongside Canceling runs during a bulk cancel. That's expected, not a stuck queue, and it looks identical to one.
• FlowRun records are owned by the flow's primary owner and need that owner to have read access to the FlowRun table. No access, no record — and the only signal is an event code in the FlowEvent table.
• Elastic table partitions are per user with a documented size limit. A single high-volume owner can hit it and silently stop recording.
• Don't point a Dataverse row-change trigger at the FlowRun or FlowLog tables. Every flow run writes to them, so you've built an infinite loop.

Consultant notes

• Design for resubmission from the start on anything that touches money or creates records. Retrofitting idempotency after the first duplicated invoice run is a bad conversation.
• Tell the client plainly that portal run history is 28 days. Most assume it's forever, and discover otherwise during an audit.
• If they need longer retention, decide early between Dataverse FlowRun and Application Insights. Dataverse is easier to query with what they already know; Application Insights is more complete and deeper.
• Warn support staff about the cross-user resubmission setting. It sounds like a helpdesk convenience and it's actually the ability to re-run someone else's business process.

---

Revisit if the 28-day portal window changes, or if partial resubmission from a failed action ever arrives.