Change report (delta export)
Most exports answer "what does this look like right now?". A change report answers the question people actually ask in a status meeting: "what has moved since last time?"
Available on Standard for JQL, board, sprint, release and backlog exports. It is at its best as a scheduled export — a weekly "what moved" report that lands in your inbox on Monday morning.
What it is not
It is not a dump of Jira's change log. The Change history component already does that, per issue.
A change report works at the level of the exported set:
- which issues appeared in the result,
- which issues are no longer in the result,
- which issues moved — status, assignee, priority, due date, plus any fields you add,
- new comments and worklogs.
"No longer in result" does not mean deleted
This is the single most important thing to understand about the report.
When an issue appears under No longer in result, it is no longer part of the export's result set. It does not mean the issue was deleted. It may have been moved to another project, re-assigned, re-labelled, or simply edited so your filter no longer matches it.
Every list of departed issues carries this note in the exported document, in every language and every format, and compaction never removes it. A report claiming work had been deleted when it had only been re-labelled would be an expensive misunderstanding.
For the same reason departed issues are listed by key only. Exportelier holds no copy of them, and fetching their current state would say nothing about why they left.
Setting it up
- Open the template in the designer.
- Turn on Change report and pick a reference point.
- Place the three components:
- Change summary — counters, the reference line and any notes.
- Delta issue list — one list, set to Added or No longer in result. Add it twice for both.
- Change table — one row per changed field.
- Save, and use the template as you would any other.
Reference points
| Reference | Meaning | Use it for |
|---|---|---|
| Previous export | The last time this template exported this scope | Ad-hoc reports |
| Previous scheduled run | The last successful run of this schedule | Weekly and monthly reports |
| Fixed date | A date you type in | "Everything since the release branch was cut" |
Tracked fields
Status, assignee, priority and due date are always tracked. Add your own — story points, sprint, a custom field — in the template settings. New comments and worklogs count as changes too, and can be switched off when they are noise for your audience.
The first run
The first report for a template and scope has nothing to compare against. Rather than failing, it produces a full report of the current set and says so:
This is the first change report for this template and scope, so it lists the full current set. Later reports will show only what changed.
From the second run onwards you get a real delta.
A worked example
A team runs a weekly scheduled export every Monday at 08:00 against project = EX AND sprint in openSprints(), using all three components and the Previous scheduled run reference.
Monday 3 August — first run. No earlier run exists, so the report lists all 14 sprint issues and carries the first-run note. That is the baseline.
During the week. EX-104 is created and pulled into the sprint. EX-77 moves to another project and drops out of the filter. EX-42 moves To Do → In Progress → Review → In Progress → Review → Done over five days. EX-51 is re-assigned from Ada to Grace and picks up two comments. Ten issues sit untouched.
Monday 10 August — second run. The report opens with:
Changes since 3 August 2026
Added: 1 · No longer in result: 1 · Changed: 2 · Unchanged: 10
Then the change table:
Key Field From To Changes EX-42 status To Do Done 5 EX-51 assignee Ada Grace 1
Note the EX-42 row. That issue changed status five times, and it is one line showing where it started, where it ended and how many steps it took. Five separate rows for one issue would bury the two issues that actually need attention.
Reading time: about fifteen seconds, versus scrolling fourteen issue descriptions to work out what is different.
When history cannot be reconstructed
Jira does not record a change log entry for every field, and very long histories are truncated when Exportelier fetches them. Where the available history cannot cover the whole reporting period, the issue is reported as not reconstructable in the summary rather than quietly counted as unchanged.
Sub-tasks and deeper hierarchy levels carry no change history of their own, so they fall into this group as well. They are still counted in the totals — the delta always works on the flat set of exported issues, so the numbers add up.
What Exportelier stores
To tell you what was added and what left, Exportelier has to remember which issues were in the last export. It stores the issue keys, and nothing else.
No summaries, no field values, no descriptions, no comments. The before-and-after values in the change table are read from Jira's own change history at the moment the report is generated, and are never kept. The stored key list expires after 180 days.
This is deliberate: keeping field values would make the report easier to build, and would make Exportelier a second copy of your Jira content, with everything that implies for data protection.
Limits
- Not available for single-issue exports — use the Change history component.
- Not available for per-issue ZIP archives: a report about the whole set has no single document to live in.
- Up to 2,000 issue keys are remembered per template and scope. Above that the report states that the added and departed counts may be incomplete.
- The change table is capped at 500 rows across the report; if reached, the document says so.