Does Power Automate Remember Between Runs? Variables Do Not, Records Do

A scheduled Power Automate flow runs every morning, checks a list of new orders, and sends a summary. One morning the summary repeats yesterday's orders. The next morning it skips a batch entirely. Nothing in the flow changed, and the trigger fired on time.

The flow is not broken. It is forgetful in a very specific way, and that distinction decides how to fix it.

The short answer

Power Automate does not remember variables between runs. A variable set during one run is cleared when that run ends, and the next run starts with a clean slate. If a flow needs to know what happened yesterday, that knowledge has to live somewhere the next run can read: a table, a list, a Dataverse record, or a shared memory layer.

What Power Automate does keep is a run history. Each execution is logged with its inputs, outputs, and status, and cloud flow run history is retained for 28 days by default. That history is useful for troubleshooting. It is not memory. A run cannot easily ask the history what it decided last Tuesday, and after the retention window the record is gone.

So the honest answer has two parts. The platform remembers that runs happened. It does not remember, inside the flow itself, what those runs learned.

Why variables reset

A cloud flow is built around a single execution. The trigger fires, actions run in order, variables hold values while the run is alive, and then the run ends. The next run is a fresh execution, not a continuation of the last one. The cost of that independence shows up in scheduled work. A daily flow that counts new records, tracks a threshold, or follows a multi-day sequence needs a starting point. Without one, it re-reads the whole source every time, reprocesses items it already handled, or misses items that arrived while the previous run was still working.

Power Platform community answers make the same point plainly: a second run of a flow cannot read data from a previous run unless that data was stored somewhere else first. Variables are working memory for one run. They were never meant to be the record between runs.

Three things that look like memory but are not

Run history is the first lookalike. It shows what happened, action by action, but it is a log for a human to inspect, not a store the next run queries for decisions. Searching 28 days of run logs for "which customers were already contacted" is not a workflow step. It is detective work.

Trigger outputs are the second. A trigger hands the run the item that started it, a new row, a new file, a form response. That item is current. It says nothing about the items before it, the decisions made about them, or the follow-ups still open. A flow that only reads its trigger is always meeting the present for the first time.

The source system itself is the third. A SharePoint list or a Dataverse table holds the current state of records, and a flow can query it. That works for facts that belong in the source system, such as an order status. It works less well for the agent's own working knowledge: which items it already processed, which approach it already tried and rejected, which customer correction it already applied. Storing that in the business system mixes the agent's notebook into the business data, and the next person to clean up the list has no way to tell which rows were real records and which were the agent's private notes.

What a scheduled flow actually needs to remember

A useful memory for a scheduled flow is short, specific, and written before the run ends. It answers the questions the next run will ask first:

• Which items were already processed, by item ID, not by timestamp alone? A timestamp checkpoint has a known gap: items that arrive while a run is working fall between the query time and the checkpoint time, and no later run ever sees them.
• What was decided, and why? A correction, a routing rule, or a threshold change is worth more than the raw output it produced.
• What is still open? A follow-up that needs a reply, a case waiting on a document, a batch that only half finished.
• What failed, and what should not be retried blindly? A run that crashes halfway through a batch needs the next run to skip the completed half, not redo it or skip the rest.

The usual fixes, and where each one stops

The standard fix is an external store the flow owns: a SharePoint list, a Dataverse table, or a SQL table where the flow writes a row at the end of each run and reads it at the start of the next. For one flow with a simple checkpoint, that works. The flow writes "last processed ID" or "items handled today" and the next run picks up from there.

That approach starts to strain when the work spreads out. A second flow needs the same checkpoint. A chat assistant that answers questions about the same customers needs the same corrections. A coding agent that maintains the workflow needs the same decisions. Each new consumer needs its own query, its own schema, and its own copy of the truth, and the copies drift.

One memory the flow, and everything else, can share

The cleaner pattern is to move memory out of the flow entirely and give every tool one shared store to read and write. The flow reads at the start of a run, writes what it learned at the end, and every other tool connected to the same store sees the same record.

That is what Vilix AI is built for: a cloud-hosted memory layer that scheduled agents reach over MCP, with zero infrastructure to run. The same memory follows the agent across tools, so a correction made in a chat assistant is visible to the scheduled flow, and a decision made by the flow is visible when the same question comes up in another tool. It keeps full conversation history, not just extracted facts, so a later run can revisit what was actually said and decided, not only a summary of it. The free plan is free forever, the 7-day Pro trial asks for no credit card, and data is portable: export everything or delete it anytime.

A practical check before the next scheduled run

Before building anything else, answer one question about the flow: if it stopped halfway through tonight's batch, would tomorrow's run know exactly where it stopped? If the answer depends on a variable, the answer is no. If it depends on a timestamp, the answer is probably not. If it depends on a record the flow wrote, by item, before it ended, then the flow has a memory, and the next run can start from where the last one actually left off.

That is the whole difference between a flow that repeats itself and a flow that compounds what it learns. One starts every morning from zero. The other starts from yesterday.