Remove Inactive Users in Jira Cloud with a CogniRunner Agent

This tutorial sets up a CogniRunner agent to remove inactive users in Jira Cloud by a rule you type in plain words: at most 10 of your own users per product, least active first, and a person approves each removal. You end up with a virtual administrator that counts seats through Atlassian's Organizations REST API, files a removal request when a product goes over the limit, and changes nobody's access until an organisation admin says yes.

We filmed the video below on 9 October on CogniRunner 1.32.2. On 29 October we repeated it on our test site with 1.35.15, and the screenshots here come from that second run. One approved request took Confluence on the site from 9 licensed users to 8 by Atlassian's own count, and Atlassian answered 204. It wasn't a clean run. Neither of our freshly described agents posted a report, and the removal only came after we pasted in a plan an administrator had written for the video, which the video's on-screen rail also admits.

https://www.youtube.com/watch?v=NKbEv_MoPRo

Note

Prerequisites

• A Jira Cloud site with CogniRunner installed (we used 1.35.15), and you as a CogniRunner admin.
• An organisation admin in Atlassian Administration. CogniRunner only lets an organisation admin approve an organisation operation.
• An organisation API key and its organisation ID, from Atlassian Administration. Our first key was no longer valid, so test yours before you paste it.
• An AI provider saved in CogniRunner Settings. Describe a job runs on the model in Model for validators and rules, and its first step, finding the operations, has about 20 seconds. For us openai/gpt-6-luna timed out twice at that step, and anthropic/claude-sonnet-5.5 produced the whole proposal in 29 s.
• A Jira project only admins can see, for the agent's daily review issue. We made a Kanban project with the key LICW.
• About 100,000 AI tokens for a first day of testing. Our two agents used 18,839 and 77,499.

You type the rule and press Create, and CogniRunner turns it into an agent with a list of allowed Atlassian operations and a daily job. The agent reads whatever it needs, but each removal becomes a request, and only an organisation admin's Approve and run sends it.

I'll use three words a lot below. A tick is one pass the agent makes over its review issue, on a schedule or when you press Run a tick now. A tick works in rounds, one model call each. Each tick leaves a block in the agent's Scratchpad tab.

[[steps]]

1. Store the organisation API key
2. Describe the job in plain words
3. Review the setup the agent proposes
4. Create the agent and read the Create list
5. Run today's review now and read the scratchpad
6. Count seats per product through the Organizations REST API
7. Run a drill on one product with a lower limit
8. Approve the request to remove the user from the group, and check the 204
9. Count again, put the person back, and delete the drill

Why Jira Cloud can't automatically disable inactive users on its own (AX-1169, 784 votes)

Atlassian bills you on "the number of users with app access at the end of your billing cycle". Whether those people opened Jira this year doesn't come into it. And the fix Atlassian documents on its user-count page is manual: "Use the Export feature to identify the inactive users, and then manually revoke their access one by one on this page."

People have asked for a schedule since 2019. AX-1169, "Deactivate inactive user based on activity", has 784 votes and is still Under Consideration (read on 29 October 2026). ACCESS-720, about deactivation policies for managed accounts, has 214 votes and says Gathering Interest. So Jira Cloud has no built-in setting for it yet. Both requests are still open. Marketplace apps, ours included, read the data and call the API on your behalf.

If you only want to find the inactive people, find inactive users first with the free export method. What an idle seat costs at 50, 200 or 500 users is in our Atlassian pricing budget. Why we'd put an agent on this at all is argued in the Atlassian license management post, which embeds this video beside two others.

One thing to settle before Step 1. The agent removes a user from the group that gives them a product, and that ends the access the group gave. It does not suspend, deactivate or delete the Atlassian account. Atlassian's API docs warn that "the user may still be in other groups that grant the same app access". Atlassian also says you "won't be billed for a user once they're removed" from the organisation. For someone who only lost one product I'd expect that product's count to drop (ours did, 9 to 8), but we couldn't find one Atlassian sentence that says so per product. The same call removes Jira access when the group is the one that grants Jira; our measured removal was in Confluence.

Step 1. Store the organisation API key

Open CogniRunner from Jira's Apps menu and go to Agents, then Setup. Find the Connections & keys card. Under Organisation API key, fill in the Organisation ID and the API key, plus an Expires on date if you want one. Tick the box that lets CogniRunner store the credential and press Check and store.

CogniRunner checks the key with Atlassian before it stores anything. Our first key was no longer valid, and the card answered:

Atlassian refused this key (HTTP 401). Check that it is current and was created for this organisation.

A current key went in fine, and the card switched to "in use", with Replace and Remove next to it. That's your check for this step. The key field is write-only, so nobody can read the key back out of the page later. I'd create a key just for this agent anyway. Then you can revoke it without breaking anything else.

Step 2. Describe the job in plain words

Go back to Virtual administrators under Agents and press Describe a job. Name the agent and pick its home project, then set the time zone. About the home project, the form says: "The home project is where it opens a review issue every day and reports on it. Use a project only admins can see."

Then type the job. This is the rule from the video, word for word. It's 584 characters, and the form takes 20 to 4,000:

Keep our own users at no more than 10 per product, on every site of this organisation. Demo evaluators don't count and are never removed: they are the people in the Demo evaluator field of DACC issues not in Demo expired, and LeanZero offboards them after 5 days. Each day, count the licensed users of every product, and where a product is over 10, propose removing the least active people first, by their last active dates, from the group that gives them the product. Never touch organisation admins, site admins, or app and service accounts. Tell me what you found and what you did.

That evaluator sentence is ours. LeanZero lets demo visitors into one site and offboards them after five days, so they shouldn't count. Replace it with your own exceptions or delete it. I'd name exceptions by something the agent can read, a field on an issue or a group, because "contractors" means nothing to an API.

Press Ask the agent to propose its setup. You should see the proposal in under a minute; ours took 29 seconds with Claude Sonnet 5.5. With GPT-6 Luna it failed twice at about 21 seconds: "The AI provider did not answer in time, so no setup was proposed. Ask again." Switching the Agent model changed nothing. The first step runs on Model for validators and rules, so that's the slot to change.

Step 3. Review the setup the agent proposes

What comes back is a list of Atlassian operations and a plan with a schedule. I'd read the operations first. They decide what the agent can do at all. I wouldn't create an agent whose list I hadn't read.

Ours asked for 8 operations: get directories, list workspaces (sites and products), search users, last active dates, get groups, get group role assignments, a JQL search for the evaluators, and Remove user from group. Seven say Runs on its own. I like that. Remove user from group says Asks you each time, and that label isn't just a badge: when our drill agent reached that call, its tick ended with "That needs a person's approval first, so it was not done in this turn." If your list has any other operation that writes, stop and change the description before you create anything.

In the video the agent asked for getDirectoryUsersCount and getDirectoryUsers. Ours asked for searchDirectoryUsers instead. Both read the same people, but it means the list is picked fresh from your words each time you describe a job.

Our plan came back as ten numbered steps. It reads the review issue and lists the directories. Then it counts each product's users per site and ranks the people over the limit by last_active, oldest first. It finds each person's groups that grant the product, skips groups an identity provider manages, and files the removals together at the end.

Two details in the plan affect your bill. Atlassian counts someone as active after "viewing a product's page for a minimum of 2 seconds", and the date "may be delayed by up to 24 hours". So a person who glanced at a Confluence page last week looks active, and someone who logged in this morning may still show yesterday's date. A person with no last active date for the product falls back to the date they joined the organisation, never to today. I'd keep a margin of a week or two in any rule built on these dates. It's cheap insurance.

And the schedule line said:

It opens a review issue in LICW every day at 07:00 (Europe/Bucharest), labelled cr-review-rolling-licences, and checks for work every 30 minutes, at any hour. It also reads DACC. It may spend up to 500,000 tokens a day, and a second check reads each report before it is posted.

How the agent decides who goes

CogniRunner ships a rolling-licences knowledge pack that the agent plans with. Here's what it says about who counts and who can be removed, quoted where the wording matters.

A billable seat is "an ACTIVE user who holds the role atlassian/user or atlassian/admin on that product's resource". Guests, customers, stakeholders and user-access admins don't count. A suspended user holds no seat "even when a group still grants the role". And "Group membership is not product access". So the count call in Step 6 filters on roles.

Anyone whose platform roles include atlassian/org-admin or atlassian/site-admin is counted in the total and never proposed. So is any account whose accountType isn't atlassian. Apps and service accounts show up that way.

Least active first means "the oldest last-active date, then the oldest join date". A group synced from an identity provider is skipped, because "a removal would be undone". I think that last rule is the one homemade scripts most often miss: they remove the person, the next sync puts them back, and the seat never goes away.

But the admin protection only covers admins CogniRunner can recognise. On the organisation door it recognises them by platform roles. Without an organisation key, an organisation admin who sits in none of the admin groups isn't recognised on a site door.

Step 4. Create the agent and read the Create list

Press Create. It took 12 seconds. You get one line per step:

That red line comes from our setup. Our rule mentions DACC, a project that only exists on our production demo site, so CogniRunner dropped the JQL search it could never run and the agent kept 7 operations. The fourth line scheduled "Rolling licences: open the daily review" at 0 7 * * *. Ours ended "Moved it to Live", because we ran 1.35.15. From 1.35.16 (29 October) every new agent starts in Learn, and your last line will say so: "It starts in Learn: it reads and takes notes and changes nothing until you promote it on its page." An agent in Learn can't file a removal request. Move it up first.

Open the agent from its card, click Live on the phase strip under its name, and confirm Move to Live. Live in CogniRunner means the agent may post and act within its powers. Here those powers contain one write, and it asks each time.

Step 5. Run today's review now and read the scratchpad

Go to Scheduled Jobs and press Run now on "Rolling licences: open the daily review". You should see today's review issue appear in the home project (ours was LICW-1). Then open the agent from its card and press Run a tick now. On an empty Activity pane the button sits in the middle. Once the pane has content, it's only in the More actions menu next to Pause.

A confirm dialog says the tick "sweeps its intake now instead of at its next scheduled run" and uses its own budget. After a minute or two the Scratchpad tab gets a new block. Ours said:

The turn ended when it said it was done, after 2 rounds, in the Live phase. It staged nothing and changed nothing. Not done: stage a reply. The draft broke one of the writing rules, so it was refused and not staged.

So our fresh agent posted no report, and the tick used 18,839 tokens. Part of that is our site: its plan stops if the evaluator search returns nothing, and that search had been dropped. The refused draft is a product problem, though, and the screen doesn't say which rule it broke. We wrote it up for the CogniRunner team the same day. My advice until it's fixed: don't wait for the report. Watch the Atlassian calls tab. The video shows a watchdog an administrator had already tightened by hand, and you'll probably need that one round of tightening too.

Step 6. Count seats per product through the Organizations REST API

Atlassian's own numbers are a few calls away, and you want them anyway to check whatever the agent tells you. Export your key and organisation ID first (ORG_API_KEY, ORG_ID), then find the directory:

curl -s -H "Authorization: Bearer $ORG_API_KEY" -H "Accept: application/json" \
  "https://api.atlassian.com/admin/v2/orgs/$ORG_ID/directories"

{"data":[{"directoryId":"5fe8d258-49f8-40df-9b65-7f4ab5581af1","name":"wolfaenpak","icon":""}],"links":{...}}

Then list the sites and products. Each item's id is the product's resource ID. The count call needs it:

curl -s -X POST -H "Authorization: Bearer $ORG_API_KEY" -H "Content-Type: application/json" -d '{}' \
  "https://api.atlassian.com/admin/v2/orgs/$ORG_ID/workspaces"

{"data":[{"id":"ari:cloud:confluence::site/<siteId>","attributes":{"name":"...","typeKey":"confluence","directory":"5fe8d258-...",...}},...],"links":{"next":"..."},"meta":{"pageSize":20,"total":90}}

Set DIRECTORY_ID to the directoryId above and SITE_ID to the part after site/ in your Confluence item's id. Your first item may be another app. It pages 20 at a time: for the next 20, send -d '{"cursor":"<links.next>"}'. Our organisation listed 90 workspaces over 5 pages, Jira, Confluence and JSM among other app types. Now count one product's licensed users:

curl -s -H "Authorization: Bearer $ORG_API_KEY" -H "Accept: application/json" \
  "https://api.atlassian.com/admin/v2/orgs/$ORG_ID/directories/$DIRECTORY_ID/users/count?resourceIds=ari%3Acloud%3Aconfluence%3A%3Asite%2F$SITE_ID&roleIds=atlassian%2Fuser&roleIds=atlassian%2Fadmin&status=active"

{"count":9}

That's Confluence on our main test site. Both roleIds and status=active follow the knowledge pack's seat rule above. I trust these numbers more than any agent's summary. Ours included. Done for every Jira, Confluence, JSM and Customer Service Management product, our organisation came to:

17 sites, 34 products, HTTP 200 on every call (29 October 2026)
Jira                            17 products   3 to 8 licensed users
Confluence                      12 products   3 to 9 licensed users
Jira Service Management          3 products   3 to 5 licensed users
Customer Service Management      2 products   3 licensed users each

We counted the jira-software workspaces as Jira. The call also lists a jira workspace for each of the 17 sites, at 3 to 4 users each, which we left out of the 34; we didn't find a source that says which of the two is the billed seat. I'd count both on your site until you know. In the video the same organisation had 32 products holding 3 to 6 users each. Nothing was over 10 either time, so our real rule removes nobody. That's why the video and this tutorial both run a drill.

Step 7. Run a drill on one product with a lower limit

I'd always drill first. Pick a product where you already know who should be picked. Describe a second job, Licence drill, with a limit that forces one removal on one product. Ours was Confluence on the wolfaenpak site. Limit 8:

Keep our own users at no more than 8 on Confluence on the wolfaenpak site of this organisation; this is a drill, check only that one product on that one site. Count its licensed users, and if it is over 8, propose removing the least active people first, by their last active dates, from the group that gives them the product. Never touch organisation admins, site admins, or app and service accounts. Tell me what you found and what you did.

Its proposal took 24 seconds and asked for 9 operations. I'd check those the same way as before, and I'd look for the removal's orange label first. Create came back with four green lines and no red one. On 1.35.16 or later, move the drill to Live on its page too. Do it before the first tick.

The first two ticks failed.

1. The first tick ran 8 rounds and stopped with "Not done: call an Atlassian operation. Atlassian answered 400 and refused it." We didn't see which parameter Atlassian refused. We opened the agent's settings, chose Job and then Edit, and replaced its "How I will do it" with the plan an administrator had refined for the video (below). Under Atlassian calls we pressed Change the list and allowed one more operation, Get users in an organization.
2. The second tick said nothing had changed on the issue since it last looked, and queued nothing. A tick only works an issue that changed, so we commented on the review issue (LICW-2) and ran the tick again from More actions.

This is the plan we pasted, shortened, with our IDs swapped for placeholders. It writes the IDs in so the agent doesn't have to find them, and our limit was 8 where the video's was 4:

Known values: orgId = <orgId>; directoryId = <directoryId>; the Confluence resource on the site = ari:cloud:confluence::site/<siteId>. No other call is needed to find them.
1. FIRST round, both at once: org.getDirectoryUsersCount and org.getDirectoryUsers, each with pathParams {"orgId", "directoryId"} and query {"resourceIds": "<the resource>", "roleIds": ["atlassian/user", "atlassian/admin"], "status": "active"}; getDirectoryUsers also takes "limit": 100.
2. SECOND round: leave out everyone whose platformRoles holds atlassian/org-admin or atlassian/site-admin, and every accountType that is not atlassian. For EACH person left, both at once: org.getDirectoryUsersLastActiveDates and org.getGroups (that person's groups for the resource).
3. THIRD round: rank those people by last_active on the Confluence resource, oldest first (no date = never active = first). Take only as many as bring the count down to 8. For each one, file org.deleteDirectoriesGroupsMemberships for the group whose managementAccess.modifiable is true, all in this one round. Its reason names the person, their last-active date, the group, and the admins you left out.
4. FOURTH round: stage ONE comment on the review issue: the count before, who is protected and why, who you proposed and their last-active dates, how many requests wait for approval. Never finish without staging it.

Our third tick ran 5 rounds and ended with "Not done: call an Atlassian operation. That needs a person's approval first, so it was not done in this turn." A writing rule refused the report draft again, even with the edited plan. The request was filed anyway, and you should see "Waiting for your approval 1" on the agent's Atlassian calls tab. The day's spend for the drill was 77,499 tokens over three ticks; the video's single drill turn used 71,807.

Before you approve, run the count from Step 6 and keep the number. Ours was 9 at 11:55 EET.

Step 8. Approve the request to remove the user from the group, and check the 204

Open the agent's Atlassian calls tab. Under Waiting for your approval there's a card for the request:

It shows the exact REST call, what it acts on, the agent's reason, an expiry of 24 hours and a request fingerprint. Below them are Show the exact request and Show the state before. I'd open both. It takes ten seconds. The last line says: "It acts on the organisation, so only an organisation admin can approve it."

An admin CogniRunner recognises never shows up here as a candidate. It refuses before a request is filed, and the refusal text in the code reads: "CogniRunner never does that, whoever approves; an organisation admin does it in admin.atlassian.com. Nothing was sent and nothing was put to a person for approval."

Press Approve. A dialog repeats what will happen:

Approve "Remove user from group" (org.deleteDirectoriesGroupsMemberships) on the organisation? It runs once, now, exactly as shown here, and nothing else.

Press Approve and run. The card should move to Answered and read like ours:

Step 9. Count again, put the person back, and delete the drill

Run the same count from Step 6. I'd do it twice. Ours read 9 at 11:55, before the approval, and 8 at 11:57, after it:

{"count":9}   11:55 EET, before Approve and run
{"count":8}   11:57 EET, after Atlassian answered 204

On a live site you'd stop here. On ours the person is on our team and needs Confluence, so we put them back with the matching POST, which answered 204, and counted 9 again:

curl -s -o /dev/null -w "%{http_code}\n" -X POST \
  -H "Authorization: Bearer $ORG_API_KEY" -H "Content-Type: application/json" \
  "https://api.atlassian.com/admin/v2/orgs/$ORG_ID/directories/$DIRECTORY_ID/groups/$GROUP_ID/memberships" \
  -d '{"accountId":"<the accountId from the request>"}'

204

You'll find the group ID and the account ID in the request on the approval card (Show the exact request). Atlassian's docs say adding someone to a group gives them "the same app access and permissions as the group". A 409 means the person is already in the group, or you've hit a user limit for an app the group grants. Keep this call somewhere. It's how you undo a removal someone disagrees with, and I'd rather have it ready before the first complaint than after.

Then delete the drill. Do it now. Use More actions, Delete on the agent, and delete its scheduled job in Scheduled Jobs. With the person back, the product is over the drill's limit again, and the drill would file the same request at its next tick.

What changed between the video (1.32.2) and our run (1.35.15)

The first eight rows are in CogniRunner's release notes, and 1.35.15 is the Marketplace version 7.43.0 (28 October). The last row is what we saw on our two runs.

In the video, 1.32.2	Now, 1.35.15
A described agent kept working hours on and a 250,000-token default	It works at any hour and the proposal shows a 500,000-token daily cap (1.33.1)
A red "The save narrowed something" note about settings nobody chose	Gone for that case; it still appears when a project is dropped, as ours was (1.33.1)
The job text could only be edited over REST	Agent settings, Edit everything (1.33.1)
The screens said a Jira administrator approves organisation operations	They name an organisation admin for an organisation operation (1.32.3)
A group removal was recorded as not confirmed	It reads the person's groups back and confirms (1.33.1)
Used today lagged with no warning	It says when ticks are still running; their tokens are added when they end (1.33.1)
A staged draft could not be rejected	A person can reject a staged draft in any phase, Live included (1.33.1)
The second check often held a correct license report	Fixed in 1.33.3; it can now see the reads behind the report
A fresh agent's first run staged nothing	Still true in both our runs on 1.35.15

Run a tick now also moved: once the Activity pane has content, it's in the agent's More actions menu.

Four more releases came out after our run, up to 1.35.19 (Marketplace version 7.47.0, 30 October), and 1.35.16 changes these steps: a new agent starts in Learn and you move it to Live yourself, as in Step 4. 1.35.18 lets agents read an issue's links and sub-tasks, and 1.35.19 changes how the second check treats the changes the agent made in that turn. I haven't repeated the drill on them, so the ticks above, the two failures and the writing-rule refusal, are what 1.35.15 did, and I haven't checked whether the newer releases change them.

If it didn't work

1. "The AI provider did not answer in time, so no setup was proposed. Ask again." The first step of Describe a job runs on Model for validators and rules and has about 20 seconds. Pick a faster model in that slot. The Agent model doesn't matter for this step.
2. "Atlassian refused this key (HTTP 401). Check that it is current and was created for this organisation." The organisation API key has expired, was revoked, or belongs to another organisation. Create a new one in Atlassian Administration.
3. A red Create line "The save narrowed something: Project ... is not available to this app or to you, so it was dropped." Your description names a project the app can't read. Fix the description, or accept that the agent works without that search.
4. "The draft broke one of the writing rules, so it was refused and not staged." The report was refused. It happened on the last tick of both our agents on 1.35.15, editing the plan didn't stop it, and the screen doesn't name the rule. The removal request is filed anyway, so read the Atlassian calls tab rather than waiting for the report.
5. "Atlassian answered 400 and refused it." We didn't see which parameter Atlassian refused. What got us past it was giving the plan the directory and product IDs and allowing Get users in an organization under Atlassian calls, Change the list.
6. A tick that queues nothing: "Nothing changed on the issue since it last looked." Comment on the review issue, then run the tick from More actions.
7. The count didn't drop after a 204. The person is in another group that grants the same product. Look at their Apps tab in Atlassian Administration.

What you have now

[[takeaways]]

• An organisation API key stored in CogniRunner and checked with Atlassian.
• An agent built from one paragraph, whose only write is Remove user from group, and that asks each time.
• A daily review issue in an admins-only project, and a tick every 30 minutes.
• Atlassian's own seat count per product from the Organizations REST API, to check the agent against.
• One proven removal: an Approve and run, a 204, a count from 9 to 8, and a POST that puts the person back.

It doesn't deactivate accounts, and it can't save a seat when the person is also in a group synced from an identity provider that grants the product.

Clean up

If this was a trial, also delete the Rolling licences agent and its scheduled job, delete the home project if you made one, and remove the organisation API key from the Connections & keys card if you don't want CogniRunner to hold it. I'd remove it unless an agent still needs it. We did all of that after this run and put both model slots back as they were. Everything ran on our test site and organisation; our production demo site wasn't touched.

What I think of it after two runs

I'd run the approval part on our own live organisation. One write operation, marked in orange before you create anything, a card with the exact request and the reason, a refusal for recognised admins before anyone is asked, and a read-back after the 204.

But the part that builds itself from a paragraph is less finished than the video makes it look. On two releases a fresh agent didn't post its report, and our drill only filed its request once the plan had the IDs written in. So plan on editing the agent's plan once, and run a drill before the limit you mean. Would I let it run my rule daily with no drill first? Probably not, and we built it.

What would you put in the rule for your own organisation? I'm curious whether people would rather cap seats per product, as we did, or remove anyone inactive for 90 days regardless of the count.

For the rest of what CogniRunner's agents do, see the CogniRunner product page.

---

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.