Does Jira Automation Remember Between Runs?

No. A Jira Automation rule carries no memory from one execution to the next. Variables and smart values built during a run end when that run ends. The next run starts from its trigger and the current state of your issues. Anything it knows about last time is what an earlier run wrote onto an issue or a project.

That answer surprises people because a rule feels continuous. It fires every morning and works the same queue. The continuity lives in Jira's data, not in the rule.

What does a rule keep while it runs?

Inside one execution, a rule has real working memory. Smart values pull data from the trigger issue and from anything the rule looks up: fields, comments, dates, lists. The Create variable action lets you define your own smart value and reuse it in later actions and conditions in the same rule.

That variable is always a string, and its scope is the flow that created it. It is a scratchpad for one execution: compose a summary, hold a calculated date, carry a value out of a branch. When the execution finishes, the scratchpad is discarded. Nothing in the Create variable action writes it anywhere durable, and Atlassian describes it as storage for use elsewhere in that same flow.

What survives after the rule finishes?

Three things survive, each one Jira data rather than rule memory.

First, the issues themselves. Any field a rule sets, comment it adds, or transition it performs stays on the issue, and a later run can read those fields like any other data. Writing a result into a custom field is the oldest cross-run pattern in Jira Automation: the issue becomes the storage.

Second, entity properties. Jira stores key-value JSON data on entities such as issues, projects, and users. Automation includes a Set entity property action for entities related to the trigger, and a later run can read a value back with a smart value such as {{issue.properties.usernameEmail}}, or through the REST API and JQL. Atlassian documents a maximum of 32,768 bytes per value, warns that anyone who can edit the entity can modify its property, and states that private or personal data should never be stored in entity properties. Concurrent writes are not merged; the latest saved value is retained.

Third, the audit log. Every execution is recorded so a person can inspect what ran and where it failed. The rule cannot read it back as context for its next decision.

What does the scheduled trigger know about the last run?

Exactly one narrow thing. A scheduled trigger running a JQL search offers an option to only include issues that have changed since the last time the rule executed. Atlassian's support article explains that it compares against when issues were last updated, and that an issue the previous run itself updated counts as changed, because the rule's own edit moved its timestamp.

That is a filter, not a memory. It tells the new run which issues changed, not what the previous run concluded about them, which ones it skipped and why, or what it promised next. Operators have asked Atlassian for the missing piece directly: feature request AUTO-891 asks for persistent smart values remembered from prior executions. The request exists because the product does not do it today.

How do operators carry state between runs today?

Working patterns move state out of the rule into something a later run can read:

1. Decide what the next run genuinely needs: the last processed issue, the current step for each open item, the date of the last notice sent.
2. Write it to a field on the issue when the state belongs to that issue, so any later run, report, or person sees the same value.
3. Use a Set entity property action when the state is small, structured, and tied to one issue, project, or user, and read it back at the start of the next run.
4. Rebuild the rest with Lookup issues and JQL at the start of each run.
5. Keep secrets and personal data out of entity properties, as Atlassian directs.

These patterns work, and they share a shape: memory belongs to one issue at a time, inside one Jira site, in values the author designed in advance.

What kind of memory does a scheduled AI rule actually need?

Add an AI step and the gap changes character. The rule no longer just moves an issue between states. It reads a thread, weighs history, and decides: escalate, wait, reply, or leave it alone. The decision is the valuable part, and it is exactly what field values and small properties were not designed to hold. The next run needs the reasoning, not only the result: that the agent already asked this customer for logs twice, that a human took over the thread on Tuesday, that last week's summary was corrected.

How does Vilix AI give a scheduled rule a memory outside Jira?

Vilix AI is a cloud-hosted memory layer outside the automation tool, so there is no infrastructure to run alongside your Jira site. A scheduled agent connects over MCP with an API key as a Bearer header to https://api.vilix.ai/mcp. At the start of a run it calls get_context and loads the relevant saved context: prior decisions, corrections, and the full conversation history behind them. At the end of the run it calls save_turn and writes back what it did and decided.

Because the memory belongs to your Vilix AI account rather than to one rule or one issue, the same context is available to every connected tool: the scheduled rule in Jira, a session in Claude or Codex where you planned the work, and the next automation you build in n8n or Make. Correct something once and the newest version is what every tool retrieves, since retrieval is recency-aware and the last write wins. You can list, edit, or delete memories, export everything, or wipe the account instantly. The plan is free forever, with a 7-day Pro trial that needs no credit card.

Frequently asked questions

Does a Create variable value persist to the next execution?

No. A variable created with the Create variable action is a string smart value for use in later actions of the same rule execution. When the execution ends, the variable is gone. Carrying a value into a later run requires writing it to an issue field or an entity property and reading it back.

Can a Jira Automation rule read its own audit log?

No. The audit log records executions for people to inspect and debug. A rule has no action that reads a previous execution's log as input, so log history never becomes context for the next run.

Does Jira Automation remember between runs if the rule runs on a schedule?

The schedule changes how the rule starts, not what it remembers. A scheduled trigger can limit its JQL to issues changed since the last execution, a timestamp filter. The run still begins with no variables, no conclusions, and no record of its own prior decisions beyond what was written onto Jira data.