What You Can Script, and What You Have to Have Recorded

[#1]

There is a question no amount of scripting can answer, and it is worth knowing which one it is before someone asks you.

Picture a Jira admin on a Tuesday. Someone from the risk side of the house comes over with what sounds like a reasonable request: how long did approvals actually take last quarter, before we changed the workflow in May?

The admin is not worried. They have a scripting app. They can query issues, walk changelogs, pull the data into a dataframe, group it, chart it. This is exactly the kind of thing the tool is for.

An hour later they are still not worried, but they have stopped writing code. The workflow that existed in April no longer exists anywhere. Two of the statuses were renamed during the May rebuild, so the transitions that used to mean "waiting for approval" now read as something else. One approval field was replaced by a different field and the old one was deleted, which took its history with it. The question is not computationally hard. It is unanswerable, and it became unanswerable months ago, quietly, while everyone was busy shipping.

This is not a criticism of scripting tools. It is a distinction that gets blurred often enough to be worth drawing clearly, because the two halves of it fail in completely different ways.

State is queryable. History is only sometimes there.

Jira is excellent at telling you what is true right now. Every issue, every field value, every scheme and permission and workflow definition is available, precisely, at any moment you care to look. Anything you can express as a question about the present, you can answer whenever you like. If you did not build the report last year, you can build it this afternoon and get the same answer.

History behaves differently, and unevenly. Some of it is recorded thoroughly. The issue changelog captures field changes with an author and a timestamp, and that alone answers a lot of questions about how work moved. Some of it is recorded with a retention limit, which varies by product plan: audit logs are the obvious case, and the practical consequence is that "we can always look it up" is true for a while and then silently stops being true. And some of it is recorded only as the fact that something changed. The audit log will tell you a scheme was updated and by whom; it does not keep the scheme as it stood, so the new version sits where the old one used to be with no way back to it.

A script reads whatever is there. It cannot read what was never written down.

The two lists

It is worth being concrete, because the boundary is not intuitive.

Things you can compute at any time, as long as the data still exists:

• Current values of anything: fields, statuses, assignees, components, versions.
• Counts, distributions, and aggregates over the present population of issues.
• Anything the issue changelog captured: status transitions, field edits, who made them and when.
• Durations derived from those transitions, for issues that still exist and fields that still exist.

Things you cannot reconstruct after the fact, no matter how good your tooling is:

• What a workflow looked like beyond the history window. Company-managed workflows do expose a version history through the workflow REST API, but Atlassian is explicit that retention is limited, and the window is short enough that last year's shape is already gone. Team-managed projects expose no workflow definition endpoint at all — the request for one, JSWCLOUD-25563, was closed in 2024 without being implemented. Recent history: yes. Last year: no. 
• What a permission or notification scheme granted on a particular day, and therefore who could actually see or do what at the time a decision was made. The audit log records that a scheme was updated, and by whom, within your retention window. It does not store the scheme itself, so "what did this grant in March" is a different question from "did something change in March", and only the second one is answerable.
• The history attached to a custom field deleted more than 60 days ago. Trashed fields are restorable with their data for 60 days. After that the field and its past are gone together.
• Configuration as it stood: screens, field contexts, automation rules, project settings. You have today's version. Yesterday's is not stored beside it. The log may tell you it changed; it will not give you the version.
• Changes older than your plan's audit log retention window.
• Anything about work items that were deleted rather than archived. Jira Cloud has no trash or recycle bin for individual work items, and Atlassian's own site backups cannot be used to restore one. Recovery means re-importing from an export you happened to make before the deletion, and the re-imported item comes back under a new key, so its links and history do not come back with it. 

Look at the second list again and notice what it has in common. None of these are exotic edge cases. They are the ordinary consequences of a workspace being maintained by people who are doing their jobs properly. Fields get cleaned up. Workflows get simplified. Schemes get consolidated. Every one of those improvements removes evidence, and nobody experiences it as removing evidence at the time.

Notice also that most of these are not absolutes. They are horizons. The question is not whether the platform records anything, it is how far back the record reaches and whether it kept the thing itself or only the note that it changed.

Why this is biting now specifically

Admins have lived with this for years without much pain, because the questions being asked were mostly questions about the present. Who is this assigned to. How many are open. What is the current state of the release.

Three things have changed at roughly the same time, and all three ask about the past.

Audit and regulatory review. Reviewers preparing an assessment increasingly want to see that a control kept working across a population of changes and over time, not that it existed on the day they looked. That is a question about behavior, and behavior only exists as a sequence.

Knowledge graphs and AI retrieval. The current enthusiasm for graph structure over flat retrieval rests on relationships like "superseded by", "owned by", "implements". Those relationships have a temporal dimension whether or not anyone models it. A graph built on today's configuration will confidently describe a past that never happened, and it will do so in fluent, well-cited prose.

Agentic systems. An agent that acts on an assumption about how something has been working is a much more expensive mistake than a chatbot that merely says it. The check on that assumption is a record, and the record has to predate the question.

None of these are reasons to buy anything. They are reasons to know where your own history ends.

The asymmetry that actually matters

Here is the part worth carrying away.

Analysis is a decision you can postpone indefinitely. Every report you have not built yet, you can build later, on the same data, and get the same answer. There is no penalty for waiting. This is genuinely liberating and it is why scripting and query tools feel so powerful: they turn "I wish I could see X" into an afternoon of work, on demand, forever.

Capture is not like that. It is the one decision in this chain you cannot make retroactively. Either the event was written down when it happened or it was not, and no amount of tooling, budget, or cleverness applied afterwards will produce it. You can always analyze later. You can never record earlier.

Most teams treat these two as the same kind of decision, and defer both. That works right up until the first question that reaches backwards.

Four questions to ask your own instance this week

None of these require a purchase. They require about an hour.

1. What is your audit log retention on your current plan, and what date does that put your visibility horizon on? Look it up rather than assuming. It is usually earlier than people expect.
2. When did your most-used workflow last change shape, and can you describe what it looked like before? If the answer is "someone would have to remember", that is your answer.
3. Has a custom field been deleted in the last year, and was it ever used in reporting? Check whether anything you still report on depended on it. If it went to the trash in the last 60 days you can still get it back.
4. Pick a question you would want to be able to answer twelve months from now. Something like "how long did this class of change take to approve, month over month". Then ask whether the evidence for it is being written down today, or whether you are planning to reconstruct it later. If it is the second one, you are planning something that will not work.

That last one is the whole article compressed. It is a cheap exercise and the result tends to be clarifying, in an uncomfortable way.

The quiet part

There is no dramatic conclusion here, and no failure to point at. Nobody neglects their history. It simply is not anybody's job to notice that a good, well-intentioned cleanup made a future question unanswerable, because at the moment it happens there is no question yet.

That is the whole difficulty. The cost of not recording is paid on a completely different day from the one where the decision gets made, and by then the decision is not reversible. Which is a strange kind of problem to have, and a very easy one to solve, but only in one direction and only in advance.

Disclosure: I am co-founder of MetaFrazo, which reads Jira's event stream to make exactly this kind of history readable. The distinction above holds regardless of what tooling you use, and the four questions are worth running whether or not you ever look at our app.

[Mia Tamm _Simpleasyty_]

Hi @Maria Reisinger _MetaFrazo_ the distinction between capture and analysis is spot on.

I think the same applies to metadata itself. If owner, classification, review date or approval state matters for audit, storing only the current value isn’t really enough. You also need to know who changed it, when, and ideally under which version of the structure or schema.

Otherwise a future report can be perfectly calculated over an incomplete past.

[Cameron Crippen - Workflow Linter]

I feel like “Nothing changed” and “We don’t have the records” are entirely different answers. I would want that distinction made clear in a report, rather than finding out later that information was missing.