Saved Filter data sources
A report's data comes from Jira Saved Filters. You add each filter once, give it a name, and bind components to that name.
Saved Filters are the only data source in this version. There is no free-text JQL, no REST, SQL or CSV source, and no third-party connector.
Adding a source
In the report editor, Add data source lists the Saved Filters Jira shows you. Pick one and give it a local display name — "Support backlog", "Engineering escalations" — which is what you will see in the designer's source selector.
You can also type a numeric Saved Filter ID directly. If Jira cannot be reached, the picker says so instead of blocking the editor.
A report can hold up to 8 data sources. Names must be unique.
Exportelier stores a filter id, not a query
This is the single most important thing to understand about reports.
When you add a Saved Filter, Exportelier stores its numeric id and your display name. That is all. It does not store:
- the filter's JQL — it is never read, copied, logged or concatenated;
- the filter's results — no snapshot of issues is kept anywhere.
At export time Exportelier builds one strictly numeric predicate,
filter = 12345, and asks Jira for the answer now.
Three consequences follow, and they are all deliberate:
- The report follows the filter. Edit the Saved Filter in Jira and the next export reflects it. There is nothing to re-sync in Exportelier.
- The filter's Jira sharing rules apply automatically. Exportelier never becomes a side channel around them.
- There is no stale copy to leak. A report holds a reference, not data.
Because the reference is live, editing a widely shared Saved Filter changes every report bound to it — including reports built by other admins.
Every export runs as you
Exportelier reads Jira as the person who started the export, never as the app and never as the person who built the report.
So two people can export the same report, on the same day, and legitimately receive different documents. Each sees exactly the issues their own Jira permissions allow — no more, and no less. This is correct behaviour, not a bug: the alternative would be an app that shows people data Jira denies them.
A site admin building the report sees the filters they can see. That never widens what anybody else gets.
Two sources, one filter, one search
If two data sources point at the same Saved Filter, Jira is queried once and the result is handed to both. The fields the components actually need are collected across the whole report and requested together, rather than fetching "everything" or fetching per component.
You can therefore add the same filter twice under different names — for different components — without paying for it twice.
Preflight: what the export will find
Before an export starts, Exportelier checks each source and reports one of:
| Status | What it means | Blocks the export? |
|---|---|---|
| Ready | The filter was read and matched issues. | No |
| Empty | The filter currently matches no issues. | No — an empty report is a truthful answer. |
| Unavailable | The filter is not available to you. | Yes |
| Rate limited | Jira is throttling requests; try again shortly. | Temporarily |
| Error | The filter could not be checked. | Temporarily |
Preflight also shows an approximate issue count per source and warns when a source will be cut off at the per-source cap.
Why "unavailable" does not say "deleted"
Jira answers 404 both for a filter that no longer exists and for one that
exists but is not shared with you. The two cannot be told apart through the API,
so Exportelier does not guess. Claiming a deletion it cannot prove would send
people looking for the wrong problem; the message names both possibilities and
suggests asking a site admin to share the filter.
An unavailable source stops the export
A report whose source is missing is not exported. The job fails and names the source. This is a deliberate choice: a report silently missing one of its data sources is materially false and indistinguishable from a complete one.
Limits that apply to sources
- 8 data sources per report, and at most 8 distinct filter searches.
- 500 issues per source, and 2 000 unique issues across the whole report.
- 2 Jira searches run at once — reports are background jobs, not interactive reads, and share the site's Jira rate budget.
When a limit truncates data, the finished document says so, per source. See the limits reference.