Clearing the Done column in Jira Cloud: company-managed vs team-managed
Gabriela Perdum
Author
12 min readAugust 14, 2026
Key takeaways
The manual Clear Done work items action was a team-managed feature and the 2026 board harmonisation removed it. Atlassian says the removal was deliberate.
Its replacement, Hide done work items after, is timed and applies per user, so changing it does not clear anyone else's board.
Company-managed Kanban boards never had that button. They have a board-level sub-filter keyed on release state, which is an on-demand batch clear for the whole team.
Measured on a live site: releasing a version dropped the board from 6 rendered work items to 3 in under 15 seconds, and un-releasing put them back.
The same trick does nothing on a team-managed board, because that board has no sub-filter to act on.
GET /rest/agile/1.0/board/{id}/issue ignores the sub-filter, so it reports work items your board is not showing.
Three different people asked the Atlassian Community the same question in the space of a few weeks. "Can't remove Done issues from New Board." "How to clear all Done tickets from a kanban board." "Clearing the Done Column has disappeared---again." Same wall, three times, and the third title tells you how long it has been going on.
The button they are all looking for is gone, and the reason it is hard to find out is that Atlassian's own getting-started documentation still describes it in the present tense. I have watched an answerer on one of those threads paste that documentation, verbatim and with its URL, at someone who had just written that the three-dot menu was missing from his column headers. Right fact, wrong board, and it sent him back to the exact menu he had already reported was empty.
This walks through what actually clears a Done column in Jira Cloud in August 2026, on both project types, end to end. The company-managed half is the interesting one, because it has a mechanism that none of those three threads mentions, it works on demand rather than on a timer, it clears the board for the whole team rather than for you alone, and I measured it on a live site while writing this.
First, work out which board you are on
Everything below forks on this, and the fork is not cosmetic. The two board types solve done-clearing with completely different machinery, so an answer written for one is worthless on the other.
The fastest reliable check is the Agile REST API, because it names the difference explicitly:
I ran that against two boards I built for this article on a test site — one company-managed Kanban project, one team-managed — and the two payloads differ in two places that matter:
Company-managed
Team-managed
type
kanban
simple
subQuery
fixVersion in unreleasedVersions() OR fixVersion is EMPTY
key is absent entirely
3 rows × 3 columnsHeader row enabled
That absent subQuery key is the whole story. A company-managed Kanban board carries a second JQL query that sits on top of the board filter and decides what the board is allowed to show. A team-managed board has no such thing, which is a good part of why the button mattered so much there, and why losing it left a hole nothing else fills.
If you would rather not touch the API, the project list in Jira admin labels team-managed projects as such, and over REST the project's style field reads next-gen for team-managed and classic for company-managed.
Team-managed: the button is gone, and this is what replaced it
Take the bad news first, because pretending otherwise is what wastes people's afternoons.
The manual Clear Done work items action was removed in the 2026 board harmonisation rollout for team-managed spaces. This was not a bug and not a phased quirk that will pass. On the rollout article, which is the current source for all of this and outranks the evergreen documentation while the change is in flight, Peter Oh of Atlassian writes that "the removal of manually clearing done items was a conscious decision we made", on the grounds that the feature in its then-current state was confusing for many customers. The same article's body adds, dated 30 July 2026: "We are still evaluating the possibility of bringing back manually clearing done items however not in its current state."
And as of 12 August 2026 the new board is no longer rolling out — it has landed. The article's top block, that day: "We're pleased to announce that the modernised Jira board is now GA and rolled out to the vast majority of team-managed Software boards!" So if the control is missing from your board, "the rollout has not reached you yet" is no longer a good explanation, and it is worth striking that sentence from your own internal notes if it is in them.
What you get instead is a timed setting called Hide done work items after. The odd part is where it is documented: not on either software-board page, but on the business projects board page, because the software board was harmonised with that one. That is not a mis-link, it is where the sentence lives: "You can choose to have work items in a Done status category clear from your board after a certain period of time (7, 14, 30, or 60 days), or select Never to keep them on your board indefinitely." The path is "From your board, select View settings, then select Hide done work items after to pick your preference."
1
Open the board
not the backlog, not project settings. The setting lives on the board view itself.
2
Select View settings
top-right of the board.
3
Select Hide done work items after
and pick an interval.
4
Save it as the board default if you are an admin
the rollout article describes this as admins being able to "save a default board configuration (e.g. filters, grouping) which propagates to all users", and it lists "Clearing controls for done items" among the features that framework governs. Skip this step and you have changed your own view and nobody else's.
Two things about that list are worth more than the list itself.
The documentation above lists 7, 14, 30 and 60 days. There is also a 1 day option, which does not appear on that page at all — it is announced only in the rollout article, dated 30 July 2026: "We've added an additional option to hide done items after 1 day in addition to the other items." If your menu starts at 7, the shortest interval simply may not have reached your site. I would not assert why; nothing documents that option as phased.
The second thing is the one that catches admins out. This is a per-user view setting. Atlassian is explicit: "view settings are applied per user — any changes you make will apply to your board and backlog, and not anyone else's." The button that was removed cleared the board for everybody at once. The replacement changes what you see. To reach the team an admin has to save it as the board configuration, and even then you have swapped an on-demand action for a timer.
That per-user detail is also why "I set it and my colleague still sees a wall of Done" is not a bug report. It is the design.
Warning
The Get started with team-managed projects support page still says "Only space admins and Jira admins can clear Done work items" and describes the three-dot menu route. That page describes the pre-rollout board. During a rollout the change article outranks the evergreen documentation, and this is the clearest example of that inversion I have run into. If someone sends you that page, check the date on their board, not the date on the doc.
Company-managed: the mechanism nobody mentions
Here is the part that is missing from every one of those community threads.
Company-managed Kanban boards never had the manual clear button. That is not my inference — it is the opening line of JRACLOUD-92697, an open request from February 2024: "Currently, the ability to select the three dots on the Done column and remove done issues from the Board is only available for Team Managed projects." Gathering Interest, unresolved, 0 votes when I read it on 14 August 2026.
So company-managed admins reading the team-managed threads are reading about a button they never had. What they do have is better for exactly the use case people are complaining about, and it is the sub-filter.
Every company-managed Kanban board ships with one. Atlassian's sub-filter documentation describes it precisely: "you can add a sub-filter that refines the issues returned by your board's filter. For example, you might want to display issues on your board once they're marked as done, until those issues are released or the sprint is complete."
Read that second sentence again, because it is the answer. Done work stays on the board until it is released. Releasing a version is the on-demand batch clear, and it has been sitting there the whole time.
Atlassian states the behaviour outright in a separate knowledge-base article, Kanban board shows or hides completed work unexpectedly: "The default Kanban subfilter will remove any work belonging to a Fix version that has been Released." That is a first-party description of the mechanism, and it is on a troubleshooting page rather than anywhere near the board documentation people actually read, which is a fair part of why nobody brings it up.
To be straight about the full picture: a company-managed Kanban board also has a timed hide, and it is a different control from the team-managed one. The same article puts it at "... (more options) > Configure board > General" with the timeframe "changed to 1 week, 2 weeks, 4 weeks, or removed completely to show all work." So company-managed has both routes — a timer for background tidiness and the release for on-demand batch clearing. Team-managed now has only the timer.
The default sub-filter on a freshly created company-managed Kanban board — I created one to check rather than trusting my memory of it — is:
text
1fixVersion in unreleasedVersions() OR fixVersion is EMPTY
A work item shows on the board if it has no fix version, or if its fix version has not been released yet. Release the version and every item in it leaves the board at once, for everyone, the moment the index catches up.
Walking it end to end
1
Check the sub-filter is still there
More actions (•••) next to the board name → Board settings → General → under Filter, the section labelled Kanban board sub-filter. If someone has emptied it, this mechanism is off and the timer is the only thing holding the column down.
2
Make sure Releases is switched on
from your space navigation, select the Releases tab. If it is not in the navigation the releases feature is off, and enabling it needs Space admin permissions.
3
Create a version
name it for the cadence you actually work in, "Week 33" or "Sprint 12", not for a software release you are not shipping.
4
Put the done work in it
set the Fix Version field on the items you want swept. A bulk change from the issue navigator handles this in one pass, or drag them onto the version panel in the backlog.
5
Release it
select the version, then "In the top-right, select the version's current status (for example, Unreleased) and then select Release." You will be asked what to do with any unresolved work items, and for a release date.
6
Check the board
the Done column is empty and the rest of the board is untouched.
The version is doing nothing but acting as a batch handle. You are not claiming to have shipped software. If that framing bothers your teams, name the versions after weeks and nobody will misread them.
What I measured
I ran this on a disposable company-managed Kanban project on our test site on 14 August 2026. Six work items, three of them moved to Done, one version named "Batch 1".
I read the board through the same endpoint the board UI itself calls, so this is what renders, not what a JQL query thinks should render:
bash
1curl-s-u"$EMAIL:$TOKEN"\2"https://your-site.atlassian.net/rest/greenhopper/1.0/xboard/work/allData?rapidViewId={boardId}"\3| python3 -c"import sys,json; d=json.load(sys.stdin); \
4 print([i['key'] for i in d['issuesData']['issues']])"
State
Work items the board renders
Six items, three Done, no versions
6
Three Done items assigned to an unreleased version
6
Version released
3
Version un-released again
6
5 rows × 2 columnsHeader row enabled
The three that stayed were the three that were not Done. The three that left were the three that were.
Polling the board every five seconds after the release call, it flipped from 6 to 3 between the ten and fifteen second marks. That is one trial on a tiny project, so treat it as "seconds, not minutes" rather than as a service level — but it is fast enough that people will assume it was instant.
The reverse direction matters more than the speed. Un-releasing the version put all six back. This is reversible, which makes it a very different proposition from a destructive bulk edit, and it is the single best argument for using it on a board people care about. If you sweep the wrong batch, un-release it and the board comes back.
One wrinkle worth knowing before it confuses you. Immediately after flipping the released flag, unreleasedVersions() returned nothing and releasedVersions() still returned the old set — the version document had updated but the search index had not. Fifteen seconds later both were correct. If you script this and assert on the result in the same breath, you will get a false failure. Wait, then assert.
A second wrinkle applies if you lean on the timer rather than the release. That completion timer resets on any edit to the work item, and the knowledge-base article names Fix version explicitly among the fields that do it. So setting a fix version on a batch of old Done items restarts their clocks. It does not matter for the release route, which drops them regardless of how long they have been sitting there — but it does mean the two mechanisms interfere if you try to use both at once, and the timer is the one that loses.
Note
The release sweeps whatever is sitting in the Done column, whether or not it should be there. If your real problem is that work reaches Done without meeting your definition of done, the sweep is the wrong place to fix it — the gate belongs on the transition. That is the lane our own CogniRunner sits in, full disclosure, one of ours: native validators check that a field is filled, not that what it says means anything.
The trick does not transfer, and I checked
The obvious next thought for anyone running both project types is to do the same thing on the team-managed board. I tried it, precisely so you do not have to.
Four work items on a team-managed Kanban board, two moved to Done. Created a version, assigned both Done items to it, released it, waited, read the board.
All four still rendered, both Done items still on the board.
That is not a permissions problem or a timing problem. It is the missing subQuery from the very first table in this article. Releasing a version only clears a board that has a sub-filter reading release state, and the team-managed board does not have one. Nothing to act on, nothing happens.
So the honest summary for a mixed site is that your two project types have genuinely different capabilities here, and no amount of configuration closes the gap. If batch-clearing the Done column on demand is a real requirement for a team, that is an argument for company-managed, and it is a more concrete one than most of the arguments in that debate. It also fits the general pattern: the shared-configuration project type keeps exposing low-level levers the simplified one does not, in the same family as the workflow properties that block time logging on specific work types.
The trap that will break your audit
This one had me chasing a phantom for a few minutes, and it will cost you a great deal more if you are scripting against boards.
GET /rest/agile/1.0/board/{id}/issuedoes not apply the sub-filter. In every state above — before the version, after assigning it, after releasing it — that endpoint returned all six work items, while the board rendered three.
If you are building a report, a migration check, or any kind of board audit on that endpoint, it is answering a different question from the one you think you asked. It gives you the board's filter, not the board. To get what the board actually shows, read the board's configuration, take the subQuery, and AND it onto the filter's JQL yourself:
bash
1# the board filter alone2project ="DCLR" ->634# the board filter AND the board's own sub-filter — what the board shows5project ="DCLR" AND (fixVersion in unreleasedVersions()6 OR fixVersion is EMPTY) ->3
The backlog is a third surface, and it has nothing
Worth stating plainly because it is asked constantly and answered wrongly, including by me once: hiding done items on the board does not touch the backlog.
The backlog is a separate view with its own View settings, and that menu is a different list — version panel, epic panel, quick filters, density, fields, swimlanes. There is no done-hiding option in it at all. I re-read Atlassian's board and backlog view settings page on 14 August 2026 to confirm the option list, and the entry is not there.
So an admin who sets Hide done work items after to 1 day and then reports that the Board section inside the backlog is still full of Done work is describing expected behaviour, not a fault. The setting was built for the board, and it reaches exactly as far as its name says.
Today the only lever that empties the backlog is moving the items out yourself. Atlassian's own bulk editing from the backlog page gives the path: "Select work items while holding Ctrl (Windows) or Command (Mac) to select multiple at once", then "On any of the selected work items, right-click and select an action, or select Bulk change."
What I could not verify
Three things, kept separate from the measurements above on purpose.
Whether company-managed boards carry the new per-user Hide done work items after setting on top of their own timer. These are two different controls: the company-managed timer lives in Configure board → General and offers 1, 2 or 4 weeks, while the team-managed one lives in View settings and offers 1 to 60 days per user. Whether the second has also arrived on company-managed boards, I cannot tell you. The view-settings documentation opens by saying view settings in software spaces are the same for both project types unless noted — but that page's board table does not list the setting at all, for either type, and the page that does document it does not split by project type. It is not exposed in any REST payload I could read, so I could not settle it by measurement and I am not going to settle it by reasoning. If you need the answer for your own site, open View settings on a company-managed board and look.
What date the team-managed timer keys off. The knowledge-base article I quoted above answers this for company-managed boards — the clock is a completion timer and any edit resets it. But that article's own interval list is 1 week, 2 weeks, 4 weeks, which pins it to the company-managed control, not to the 1-to-60-day view setting on the new team-managed board. Reaching for it to explain a team-managed board is the right fact on the wrong product, and I have seen it proposed. Nothing I can find documents the new board's date basis, so I am saying nothing about it.
Whether the removal comes back. Atlassian's wording is "still evaluating the possibility", which is not a commitment, and the tracking ticket has never left Gathering Interest.
The tickets, as they stood on 14 August 2026
I pulled every one of these live rather than trusting notes, because on an active rollout a ticket fact is good for about a week. JRACLOUD-98961 went from Waiting for Release to Closed overnight on 31 July, and JRACLOUD-99078 went from 3 votes to 8 over the seven days to 14 August. Re-pull before you quote either.
The timed replacement people are complaining about
Closed, Fixed, 216 votes
JSWCLOUD-17582
The original next-gen request behind the button
Closed, Done, 446 votes
6 rows × 3 columnsHeader row enabled
Two notes on using that table. The last two are closed, so sending anyone to them achieves nothing — the 446 votes on JSWCLOUD-17582 buy no leverage at all now, and it is the ticket people find first.
The better reassurance for someone who has started to doubt their own memory is not a ticket. It is that Atlassian's own Get started with team-managed projects page, today, still tells you to "hover over the Done column and select More actions (…), then Clear Done work items". Nobody imagined that button. It is documented, in the present tense, on a page that is live right now, for a board that no longer has it. That is a withdrawn feature rather than a gap that was never filled, and it is worth saying out loud.
And JRACLOUD-99078 is the only open ticket on point for team-managed. Its browse page carries the line "This suggestion needs more unique domain votes and comments before being reviewed by our team" — unique domains. One more vote from an organisation already represented does very little. A comment from an organisation that is not there yet does a lot. Atlassian has also asked publicly, on the rollout article, what people actually used the button for, and whether it is a team ritual or just board tidiness. If you have a real answer to that, it is worth more than the vote.
Where this leaves you
If you are on a company-managed Kanban board, you already have an on-demand batch clear. It is the sub-filter plus a released version, it clears for the whole team rather than for you alone, it takes seconds, and it is reversible. Check the sub-filter is still present before you rely on it — it is a plain text field in board settings and someone may have emptied it years ago.
If you are on a team-managed board, you have a per-user timer and no on-demand action, the shortest interval is 1 day where it has landed, and the backlog is untouched by any of it. The bulk-move route is the only thing that empties a backlog today.
The limitation I would flag hardest is the one that is easiest to miss: on a team-managed board, changing Hide done work items after and then telling your team the board is clean is wrong. You cleaned your own view. Save the board configuration, or say nothing.
If your boards came across in a migration, open the sub-filter field on every company-managed Kanban board you inherited before you trust any of this. An empty sub-filter and a full Done column look exactly like a board that is simply busy, and a configuration that arrives empty and silent is the same failure shape as the default values that quietly disappear — nothing errors, nothing is flagged, and the board just slowly fills up until someone asks why.
