Does Azure Logic Apps Remember Between Runs? Run History Is Kept, Run Memory Is Not.

Short answer: Azure Logic Apps keeps a record of each run, and it does not give the next run a memory. Variables, outputs, and decisions from Monday's run stay inside that run. Tuesday's run starts with its trigger payload and nothing else, unless the workflow was built to load earlier information from somewhere else at the start.

That distinction matters because run history looks like memory. You can open a finished run and read its inputs and outputs in detail. The workflow itself cannot do the same on its next run.

A run, a workflow, and the space between them

A workflow is the definition: a trigger followed by actions, conditions, loops, and connectors. A run is one execution of that definition. A recurrence trigger on a schedule, a new file, a new message, or an HTTP call each creates a separate run.

The definition persists because it is saved configuration. The trigger payload persists because it belongs to that run. What a run learned while working belongs to neither one by default. It is recorded for inspection in stateful workflows, and then the next run begins.

Keeping the three apart explains most confusion. Saving a workflow does not save its last result. Keeping run history does not hand that history to the next execution. Each run has to fetch anything it needs again, from a connector, a database, a file, or an external memory.

What persists inside one run

Inside a single run, Logic Apps holds a good deal together.

Variables are the clearest example. Microsoft's documentation is direct on the scope: variables exist and are global only within the workflow instance that creates them, and they persist across loop iterations inside that instance. A counter can climb through a For each loop, a string can collect results from several actions, and later actions in the same run can read the current value.

Action outputs work the same way. An action later in the run can reference the body, status, and outputs of an earlier action in that run. Conditions, scopes, and error handling all depend on that shared in-run context, and it is what makes a multi-step workflow act like one connected piece of work instead of unrelated calls.

Run length strengthens the point for stateful workflows. A stateful workflow can wait, pause on an approval, and resume, with its inputs, outputs, and state stored in external storage so the run can be reviewed and can continue after an interruption. Stateless workflows in the Standard plan take the opposite design: inputs, outputs, and state stay only in memory for faster, shorter runs, with no stored history by default.

None of that storage turns into a starting context for the next run. It keeps one run coherent. It does not connect runs together.

What the next run does not get

A new run does not inherit variables from the previous run. It does not automatically receive the previous run's action outputs, its loop counts, its branch decisions, or the notes it produced about why an item was skipped.

A scheduled check makes the gap concrete. Suppose a daily workflow reviews open support cases, contacts a few customers, and decides that two cases need no follow-up because a fix already shipped. If that decision lives only in variables and action outputs inside today's run, tomorrow's run sees the open cases again and nothing else. It can contact the same customers again and reopen a question that was already settled. The platform ran correctly both days. The second day simply had no memory of the first.

The same gap appears when several tools share the work. A Logic App might prepare a summary, a second workflow might send it, and a person might discuss it in a chat tool. Each run and each tool holds its own slice. Run history can show what one workflow did, after the fact, to someone who goes looking. It does not place the full context in front of the next step before that step acts.

Run history is a record, not a memory

Run history deserves credit for what it is. For stateful workflows, inputs, outputs, and state are saved so a team can debug a failure, audit what ran, resubmit a run, and understand why a value appeared. That is operational visibility, and it is valuable.

Memory for a scheduled agent has a different job. It has to be loaded before acting, not only inspected after acting. It has to cover decisions, open items, and the conversations around the work, not only the fields one workflow happened to store. And it has to be reachable by every tool in the setup, not locked inside one platform's run list.

External storage narrows the gap when it is designed on purpose. Writing selected values to a database, a table, or a file, and reading them back at the start of the next run, gives that workflow a hand-built form of continuity. The limit is the selection: only the fields someone predicted, in the shape someone designed, for that one workflow. The reasoning in a chat thread, the decision made in another tool, and the context nobody copied into a column stay outside it.

Giving scheduled workflows one shared memory

That wider memory is what Vilix AI provides. Vilix AI is a cloud-hosted memory layer for AI tools and agents, with no infrastructure to run or maintain. Connected tools and agents reach the same memory over MCP, the Model Context Protocol, so a scheduled Logic Apps workflow, another agent, and a person reviewing the work can all start from one shared history.

Vilix AI stores full conversation history, not just extracted facts. For recurring work, that means the decision itself and the reasoning behind it are both there for the next run to load. Because the memory lives outside any single platform, it also stays available if the workflow moves, the model changes, or a new tool joins the setup.

Trying it carries little risk. There is a free plan that stays free forever, and a 7-day Pro trial that needs no credit card. Data can be exported or deleted at any time, so control stays with the owner of the memory.

How to design around the edge

1. Use variables and action outputs for what they are good at: carrying values inside one run.
2. Assume every new run starts blank apart from its trigger, and prove it by running the workflow twice in a row.
3. List what tomorrow's run must know before it acts: settled decisions, open items, prior contacts, and customer context.
4. Give that knowledge a home the next run actually loads at the start, and save the new outcome back at the end, through a shared memory layer reachable over MCP, such as Vilix AI.

Azure Logic Apps remembers each run well enough to show you exactly what it did. Scheduled agents become reliable across days when the next run is also given what every run before it learned.