Who Moved It, and When? 5 Ways to Put Jira's transitionedBy to Work

Jira's native JQL is great at telling you where a work item is right now: current status, current assignee, current priority. Instant.

But ask it a question about history — who moved MARS-14 to Done, and when — and it goes quiet. The answer is sitting right there in the work item's changelog, but native JQL cannot search it. So teams fall back to opening items one at a time, exporting to spreadsheets, or scripting against the REST API.

That is the gap Argon's transitionedBy function closes. It reads the indexed changelog and answers history questions in a single line of JQL. Here are five ways teams put it to work.

The whole function, in one line

The syntax is the same every time — five arguments:

A subquery (which items to look at), the status they were moved to, a start date, an optional end date, and an optional user. In practice, a basic call looks like this:

It works with both in and not in — and that little not in turns out to be the most useful part.

1. Sprint retros: what actually got done

“Done” on the board today is not the same as “moved to Done during the sprint.” Items get reopened, re-closed, dragged in late, or created straight into a closed column. To see what genuinely crossed the line in a window, ask for the transition, not the current status:

That is the query behind the screenshot at the top of this post: the work that actually reached Done in May, no more and no less.

2. Accountability: who moved it

Add the fifth argument and you are asking a sharper question: which items did a specific person move to a status, in a window. Just pass their name — no cryptic account IDs to look up:

This is the question native JQL simply cannot answer. The assignee field tells you who owns an item now; it says nothing about who advanced it. For audits and for honest retros — who is quietly carrying the workflow? — that distinction is everything.

3. The not-in power move: find what did not happen

Flip in to not in and Argon returns the items that were never moved to a status. Combine it with a current-status filter and you get the report every lead actually wants: work that is still open and never shipped this cycle.

Stalled tickets, skipped steps, work that slipped the sprint — the things that are invisible precisely because nothing happened to them. not in makes them a one-line query.

4. It composes with the JQL you already write

transitionedBy is just another clause, so stack it with everything else. Which bugs did we actually fix and ship in May?

Swap in a priority clause, a component, a label, a saved filter — whatever you already use. The history clause rides along.

5. It is not just Done

The status argument is any status in your workflow. Point it at your review column, your QA gate, your blocked state — anywhere you care when something moved and who moved it:

Approval trails, time-to-review, compliance checks — same function, different status.

How it works (and where your data lives)

Argon indexes your work item changelog — every status change, who made it, and when — so these queries return in seconds instead of crawling the REST API item by item. And because Argon is built entirely on Atlassian Forge, that index lives inside your own Jira Cloud tenant. Nothing is copied to a third-party server.

transitionedBy is one of seventeen functions Argon adds to JQL. For the bigger picture, see using Argon for smarter project planning, or read the deeper write-up on the Atlassian Community.