Hi Community, We are looking for a compliant way to automate issue archival in Jira Cloud for issues that match the following criteria: status = "Done"AND statusCategoryChangedDate <= -30d Currently, we have implemented this using Automation for Jira with a Send Web Request action that calls the Jira Cloud Archive Issue API. However, we have the following challenge: * Our organization's security and governance policies do not allow service accounts to be granted Jira Administrator privileges. * We would like to avoid using an individual user's API token for long-term automation. * We are looking for a supported, scalable, and auditable solution that aligns with enterprise security requirements. Questions * Has anyone successfully implemented automatic issue archival in Jira Cloud for issues matching the above JQL without using a Jira Admin service account? * Are Project Administrator permissions sufficient to archive issues through the Jira Cloud Archive Issue API, or are Jira Administrator permissions mandatory? * can we automate issue archival without requiring a Jira Admin service account?* Forge apps * Marketplace apps * What is the recommended best practice for enterprises with strict security policies that prohibit privileged service accounts? Any guidance, recommendations, or real-world implementation examples would be greatly appreciated. Thanks in advance for your help. Best Regards, Nihanth

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Auto-Archive Jira Issues Older Than 30 Days Without a Jira Admin Service Account

nboreddy

Hi Community,

We are looking for a compliant way to automate issue archival in Jira Cloud for issues that match the following criteria:

status = "Done"AND statusCategoryChangedDate <= -30d

Currently, we have implemented this using Automation for Jira with a Send Web Request action that calls the Jira Cloud Archive Issue API.

However, we have the following challenge:

Our organization's security and governance policies do not allow service accounts to be granted Jira Administrator privileges.
We would like to avoid using an individual user's API token for long-term automation.
We are looking for a supported, scalable, and auditable solution that aligns with enterprise security requirements.

Questions

Has anyone successfully implemented automatic issue archival in Jira Cloud for issues matching the above JQL without using a Jira Admin service account?
Are Project Administrator permissions sufficient to archive issues through the Jira Cloud Archive Issue API, or are Jira Administrator permissions mandatory?
can we automate issue archival without requiring a Jira Admin service account?
- Forge apps
- Marketplace apps
What is the recommended best practice for enterprises with strict security policies that prohibit privileged service accounts?

Any guidance, recommendations, or real-world implementation examples would be greatly appreciated.

Thanks in advance for your help.

Best Regards,

Nihanth

Accepted answers

Artyom Karpets _ArtUp Labs_

Hi Nihanth,

On your second question: Project Administrator is not enough for the Archive API. The REST reference for "Archive issue(s) by issue ID/key" (and the JQL variant) lists the Jira admin or site admin global permission as required, plus a Premium or Enterprise license: Jira Cloud REST API, Issues. So a service account without admin rights cannot run that Send Web Request call.

Archiving from the UI is a different path: the support page says you need the relevant space permissions to archive and restore work items, not site admin: Archive a work item. So a person holding that space permission can archive from the UI without being a Jira admin, but it stays a manual or scheduled-by-a-human step, not an automation rule.

One small JQL tip: if "Done" is backed by several statuses in your workflows, statusCategory = Done AND statusCategoryChangedDate <= -30d catches all of them, so the review list matches what you intend to archive.

Drafted with an AI assistant and reviewed by me.

All comments

Matthew Sinclair

Relevant documentation: https://support.atlassian.com/jira-software-cloud/docs/archive-an-issue/

Note: Archiving is a misnomer - all it does is "hide" - it doesn't silo - it doesn't remove - it just makes it invisible to most. Also its not entirely perfect or that great of a tool in hiding. Thankfully its not as bad as Space Archiving as JQL can't see these - at least it can see if its just work items/tickets.

API/Rovo Agent can do the work (In theory) - but no I've not done it or seen it. Our Org ignores the feature aside from Space Archiving - and our policies have changed since discovering its lack of usefulness due to clean up pains.
None of the above. The document says it all - its a "Space Permission" granted by a scheme and/or role. It helps to be a Space Admin in terms of flexibility - but it is not required.
In Theory - yes - but you will likely need to have an API Tokene'd "Actor" - any user account with permissions will work. Service Account is best - but your org policies don't allow that apparently. Jira-Automation likely will not work here in lieu of API as Jira-Automation's actor wasn't meant for that unless they changed it. Don't recall seeing an Automation Action. You may want to look into Rovo Agents instead. Or external Script (Still requires an account) outside Jira-Automation on a timer. TEST IN SANDBOX/Non-critical production space before you use this!
Ironically - Service Account - otherwise - you need an Account with an API token with sufficient permissions. Warning - API Tokens max expiry is 365 Days (1 Year) - there's no breaking that cap. You will need to refresh or it will stop working.

My bias not withstanding - Archiving is just not that great of a feature to use - I would have the tickets age out/fall off the board and move on while remaining there for historicity - if it's a situation where you have too many tickets - export out and silo - then delete when you confirm copy. Cleaner - easier. Not something you can automate easily either due to the destructive nature of the act. So same limitations apply.

Brute force option without the nuke? Move them to an "Archive Space" (in name - call it "the file cabinet") and leave them there to rot - at least relationships are intact - and you can restrict access to said space.

In your situation - Rovo Agent would prob be my next stop. Something you can schedule in Jira-Automation to kick in. Even the Rovo Agent needs an identity - but like a Service Account - it can behave as a user in its own right. (Some features may be in beta)

You may want to talk with your Org Admin/GIS Group - Service Accounts don't eat licenses - and can be scoped down aggressively to the point they don't even need admin rights.

https://support.atlassian.com/user-management/docs/understand-service-accounts/

No email address needed - no IDP/Management.
Just an Actor with user permissions enough to archive as you require it.

Parting shot/Warning : Usage/Billing changes on December 3rd - whatever you do in automation WILL be metered on Steps or Rovo Credits (or both). Choose wisely - budget accordingly. Every step/iteration of a branch for every work item/ticket you touch is a cost.

Artyom Karpets _ArtUp Labs_

Hi Nihanth,

Drafted with an AI assistant and reviewed by me.

Tomislav Tobijas

Hi @nboreddy ,

To add on this — Arek recently experimented with retrieving archived work items using Rovo. However, that was about retrieving existing archived items, not archiving them automatically. Although, it might be worth exploring if something like that is supported for auto-archiving as well 🤔

Out of curiosity, why does your organization's policy prohibit service accounts but allow personal API tokens for these operations? 👀

Btw, Forge or Marketplace apps might help automate the process; they don't automatically bypass those permission requirements.

There's also an existing feature request that might be relevant here: AUTO-1562 – Add a built-in option to Archive Issue using Automation for Jira.

I'd suggest checking with Atlassian Support whether there's a supported approach that meets your organization's security requirements. 🎟️

Cheers,
Tobi

Mertcan Karabaş (WERARE)

Hi, here is what the documentation says today:

Atlassian's REST reference for the archive endpoints (PUT /rest/api/3/issue/archive by key/ID, POST for JQL) lists the Jira admin or site admin global permission as required, plus a Premium or Enterprise plan. Project Administrator is not listed as enough. If the caller lacks permission, the docs say you get an empty result instead of an error, so check the response body when you test.
Atlassian's KB for bulk archiving with Automation (Lookup work items, then Send web request, PUT, body {"issueIdsOrKeys": [...]}) authenticates with a user API token. It does not describe a way around this. Lookup returns 100 items per run and the API accepts 1,000 per request, so a scheduled rule works in batches. https://support.atlassian.com/jira/kb/bulk-archive-issues-in-jira-cloud/
Permission schemes now include an "Archive work items" project permission, which governs archiving from the work item's More actions > Archive. https://support.atlassian.com/jira-cloud-administration/docs/work-item-permissions/ It is worth testing whether a non-admin account that holds only this permission can call the API on your site, but I could not confirm that it can.

For a policy-compliant setup, I'd ask Atlassian Support directly whether the archive API accepts the project-level permission for your plan, and get the answer in writing for your auditors. Until then, the documented route still needs an admin-level identity. A common compromise is a single dedicated, monitored account whose admin rights are limited and reviewed under your governance process, rather than a personal token.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

jira-cloud