DEV Community: Mihai Perdum

convoai.rest.bad.request - Failed to invoke action in Rovo

Mihai Perdum — Wed, 28 Oct 2026 11:59:02 +0000

"Message action error: [Code 400] convoai.rest.bad.request - Failed to invoke action. for actionKey: jira-issue-transition-bulk" is what someone got on the Atlassian Community in October 2025 when their Rovo agent tried to move a work item. The accepted answer told them to add the Transition work item skill to the agent. It worked for them. But Atlassian's own ticket for this error, ROVO-419, reproduces it with that skill already on the agent, and the cause there is a workflow validator.

A validator is a rule on a transition that checks the work item before Jira lets it through, like "Resolution is required" or "Comment can't be empty". Rovo doesn't ask you for the missing value, so the move just fails. We rebuilt this on our test site on 28 October 2026 and ran it 8 times through Rovo Chat and 9 times through the REST API. Every move Rovo tried with the field empty failed, 5 out of 5. Today's Rovo showed the validator's own message in place of the Code 400 string, so your text may not match ours.

If you only want the fix: set the field in its own step, then ask Rovo for the move in a new prompt. That got our item to Done on the first try. If your team has started asking Rovo to tidy up their boards, I think you'll want to know before it fails on someone mid-sprint.

What we found: 5 of 5 Rovo moves failed on one validator

Rovo Chat failed every time it tried to move an item through a transition whose validator wanted an empty Due date, and it didn't ask for the date once.
Our runs never showed the Code 400 string. Rovo now shows the validator's own text after "Update Jira Issues for any fields (bulk) failed because".
"Set the due date, then move it" in one prompt fails as a whole: Rovo proposes both changes on one card, and Accept all saved neither of them.
Accepting the date change alone, then asking for the move, worked first time. Atlassian suggests the same workaround in ROVO-419.
Putting the field on a transition screen fixes REST callers and does nothing for Rovo Chat. All 3 tries with the screen in place failed.
The transitions API never shows validators. With Due date on the screen, it reported the field as "required": false.

The myth: the Transition work item skill fixes every Code 400

The Behavior of Rovo Agent thread (750 views) is where a lot of people land, and its accepted answer is good advice for a custom agent: "Edit your agent, scroll down until you see Add skill. Search for Transition work item and update your agent, and then try again." The person who asked replied "thank you, this works!" A custom agent only gets the skills you give it, so if yours can't move anything at all, start there.

Rovo agent skills: check the skill first, then look at the workflow

The default Rovo Chat already has the skill. Atlassian's Rovo Chat capabilities page lists "Transition work item in Jira" as one of Chat's default skills. And the reproduction in ROVO-419 gives a custom agent the Transition Work Item skill, puts a validator on the transition that checks the Comment isn't empty, and still gets the Code 400.

The same error string also turns up on create. On the Error upon creating/ updating jira issue thread (1,825 views), the person asking gets it "not with custom agents but in the general Rovo Chat" while creating stories. Those replies stop on 20 November 2025 without a fix. Create got most of a fix later through ROVO-229, which I come to below.

So if the skill is there and Rovo still can't move one particular work item, open that item's workflow.

The Jira workflow validator: a required field Rovo is never told about

The classic validator is the Field Required validator. In the new workflow editor you find it by selecting the transition and opening Rules, where it sits in the "Validate details" group as "Validate a field". From here on, "the validator" means that rule.

For the test we made a throwaway company-managed project on wolfaenpak, our Atlassian test site. Its Done transition got one rule: Due date can't be empty, with the error message "Set a Due date before moving this work item to Done." Due date was editable on the work item and wasn't on any transition screen.

Then we opened Rovo Chat, left the mode on Auto (every new chat started on it for us) and typed "Move RVAL-2 to Done". Rovo took 9 steps and put a card on screen saying the change "hasn't happened yet: please confirm it on the card". We clicked Accept all.

It failed with "Update Jira Issues for any fields (bulk) failed because rVAL-2: Set a Due date before moving this work item to Done." (The lowercase "rVAL" is Rovo's spelling.) The work item stayed in Backlog and the chat was marked Failed in the sidebar. There was no question about the date, just a "Resend the message" button.

Atlassian already has this logged as ROVO-419, with a Comment validator in place of our date. The ticket says Rovo fails "as Rovo doesn't seem to have the capability to 'ask' for a comment before proceeding". It was created on 3 November 2025 and is a Suggestion in Gathering Interest with 5 votes, last updated on 17 February 2026.

Why your error might say "Update Jira Issues for any fields (bulk) failed because"

In 5 failing runs we never saw "convoai.rest.bad.request". Rovo wrapped each failure in its own sentence and passed the validator's message through, which helps a lot if your admin wrote a clear error message.

I don't know why it changed. Another Atlassian ticket, ROVO-827, says the same "move this" request goes to one of two actions depending on the user: jira-issue-transition-bulk, or a general "update all field types" action. Our wording fits the second one. The action key isn't shown in the UI, though, so that part is a guess. If you still see the Code 400 string, the cause can be the same validator.

Create has mostly been fixed. ROVO-229, the twin error on jira-issue-create-bulk, has 245 votes. Atlassian rolled out support for "most field types" to Agents in December 2025, and in March 2026 a PM said it had reached Rovo Chat too, with the ticket kept open for a few more improvements. ROVO-419, the transition version, is still at 5 votes with no comments.

Jira REST API transitions: why required fields come back false

You'd think Rovo could ask Jira what a transition needs. The endpoint everyone uses for that won't tell it, or you. We called GET /rest/api/3/issue/RVAL-1/transitions?expand=transitions.fields and searched the response.

transition 41 "Done"   hasScreen: false   fields: {}
substring "validator" anywhere in the body: False

Then we added a transition screen holding Due date and asked again:

transition 41 "Done"   hasScreen: true
fields.duedate: {"required": false, "name": "Due date", "operations": ["set"]}
substring "validator" anywhere in the body: False

So the field the validator insists on comes back as "required": false, even with the validator in place. The required flag doesn't look at validators at all. The official OpenAPI description of transitions.fields says it returns "information about the fields in the transition screen", and validators aren't mentioned on either transitions operation. JRACLOUD-41682 asked for this in 2015 and was closed as Won't Fix, and a 2018 reply on the developer community put it plainly: "the rest api has no visibility over validators."

Posting the transition gives you the rest:

POST /rest/api/3/issue/RVAL-1/transitions  {"transition":{"id":"41"}}
-> HTTP 400 {"errorMessages":["Set a Due date before moving this work item to Done."],"errors":{}}

POST ... {"transition":{"id":"41"},"fields":{"duedate":"2026-11-30"}}   (no transition screen)
-> HTTP 400 {"errors":{"duedate":"Field 'duedate' cannot be set. It is not on the appropriate screen, or unknown."}}

PUT /rest/api/3/issue/RVAL-1 {"fields":{"duedate":"2026-11-30"}}  -> HTTP 204
POST ... {"transition":{"id":"41"}}                                -> HTTP 204, status Done

The rule itself is readable through the workflow API (POST /rest/api/3/workflows). We used it to read ours back. For a company-managed workflow like ours that needs Administer Jira. Project admins, or anyone with the View (read-only) workflow permission, can only read team-managed ones. An agent running as a normal user can't see the rule, so the first time it hears about the validator is the error.

Do this instead: set the field first, then transition

These four steps got our work item to Done on 28 October.

Read the error message Rovo shows you. If your admin wrote a decent validator message, it names the field. If it's the bare Code 400 string, open the workflow, select the transition and look under Rules for "Validate details".
Make sure the field is on the work item's edit screen. Ours was. ROVO-419's workaround does the same for Resolution: put it on the edit screen, have the agent set it first, then transition.
Ask Rovo to set the field. If it puts the field change and the move on one card, click Accept on the field row only. Don't use Accept all.
Then ask for the move in a new prompt ("Move RVAL-3 to Done"). Accept it.

We typed "Set the due date of RVAL-3 to 2026-11-30, then move RVAL-3 to Done" and Rovo put both rows on one card. Accept all failed with the same validator message. When we checked the work item afterwards, the due date wasn't saved either. My reading is that Rovo sent both changes in one go and Jira ran the validator before the date was applied (Rovo doesn't show the call, so I can't prove it). It failed the same way on a second item.

For a Comment validator, the one in Atlassian's reproduction, we don't have a tested answer. My guess is that a comment added beforehand won't count if the validator checks the comment entered during the transition, so try it on a test project before you tell your team it works.

What doesn't help Rovo: a transition screen

I expected the transition screen to fix Rovo too, since it fixed the REST call. It didn't. With Due date on the screen, a REST caller can send the date with the move ("fields":{"duedate":"2026-11-30"} came back 204). Rovo Chat didn't use the screen at all. We tried "Move RVAL-5 to Done" twice and the set-then-move prompt once, and all three failed with the same message. So a transition screen is a good fix for scripts and automations that call the API, and leaves Rovo Chat where it was.

If you build against the Atlassian Rovo MCP server, its docs describe transitionJiraIssue as moving a work item to a new status and say nothing about fields or validators, and editJiraIssue as editing "only fields editable on that work item". We didn't test the MCP route, so treat edit-then-transition as the safe default there too.

Which cause is yours: validator, missing skill or screen

Our runs and the Community threads point to four different situations.

If Rovo can't move any work item in any project and you're using a custom agent, add the Transition work item skill.

If Rovo moves most items but fails on one transition, and the message names a field (or the Code 400 mentions jira-issue-transition-bulk), it's a validator. Set the field first.

If you're calling the REST API and get "cannot be set. It is not on the appropriate screen", the field isn't on the transition screen. Add it there, or edit the issue before you transition.

And if Rovo moved the item but a required field is still empty, you've got the opposite problem. That's ROVO-985, where the update work items skill skips required fields on an issue type change. It's In Progress.

Keep one more thing in mind if you're planning Rovo agents inside automation rules. Atlassian's docs say Rovo skills ask the person who prompted for confirmation, "except agents in automation rules". There's no card to click there, so the set-first step has to be built into the rule itself. I went through what an agent can do without anyone confirming in Rovo agent permissions vs CogniRunner approvals.

Validators are still the right place for the rule

I wouldn't take the validator off to make Rovo happy. It kept an item with no due date out of Done, and it doesn't care whether a person or an AI clicked the button. What's missing is Rovo asking for the value, and only Atlassian can add that (ROVO-419).

That's also why we build on validators. CogniRunner, our Jira app, adds AI validators that check what's in a field (is this a real root cause, or just "fixed it"?). If it isn't good enough, they block the transition and say why. When Claude Code tried to move a change request past two of them, it got an HTTP 400 back with both reasons. Mihai wrote that up in Claude Code hits a Jira workflow validator. I'd expect Rovo to show a CogniRunner validator's message the same way it showed ours, since both come back through Jira's validator error, but we haven't tested it yet.

Have you hit this error? I'd love to know which cause it turned out to be for you, and whether your Rovo still shows the Code 400 or the newer message. Tell me in the comments, or vote on ROVO-419 if you want Rovo to ask for the field before it gives up. If enough of us vote, maybe it gets looked at :)

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.

Jira Individual Capacity Planning: Capacity View vs Plans

Mihai Perdum — Wed, 28 Oct 2026 08:59:01 +0000

Jira does have capacity planning built in now: on Premium and Enterprise, the Capacity view does individual capacity planning, one row per person against epics, while Plans still plans capacity per team. Atlassian announced it for every Premium and Enterprise site on 27 July 2026. Before that came an early-access run from December and a gradual rollout through July.

Wurm Peter asked the question I'd ask first, on 15 July, under Atlassian's announcement in the Community: "So the capacity tab is assuming that everyone works the same hours/week? Nobody is allowed to work part-time? Or am I missing something?" That post has 25,149 views and 74 comments as I write this, and he wasn't missing anything. On our test site a person who works 20 hours a week shows up as 50%, and there's no box anywhere to tell Jira she works part-time.

So this guide does two jobs. It walks you through setting up a capacity plan, step by step. We did it on our own Jira Premium site on 28 October 2026, with four people, three epics, a story, a Leave row and a CSV import. And it tells you up front who it's good for, and who still needs Plans or a resource-planning app. A lot of you are reading this with a renewal or a Premium upgrade on the table.

[!NOTE]
Prerequisites: Jira Cloud on the Premium or Enterprise plan ("This feature is available on Premium and Enterprise plans", from Atlassian's support doc). You need permission to change the space's navigation to add the tab, and some epics (or higher) with an Original estimate if you want a Resourcing percentage. Atlassian's FAQ lists team-managed, company-managed and business spaces. The CSV import uses Rovo and is marked BETA. We tested as a site admin in a company-managed space, with the dark theme, so that's what the screenshots show. We didn't test what a non-admin sees.

The short answer, if you're deciding about an app: the Capacity view covers week-by-week booking of full-time people against epics, inside Premium. Keep your app if you need part-time or custom hours per person, or story-level planning. The same goes for planned against logged time, holidays from a calendar, or hiding colleagues' percentages (we couldn't test that last one). The details, and the cost, are further down.

Does Jira have capacity planning? Capacity view vs Plans team capacity

Yes, two kinds, and they answer different questions. In the Capacity view you ask "how much of each person's week is spoken for, and by which big pieces of work?" Plans (Atlassian's advanced planning, the old Advanced Roadmaps) asks "how much can this team finish per sprint or per week, and does the scheduled work fit?"

Here's how they compared when we put the same four people in both:

	Capacity view	Plans team capacity
Unit	One person, against a fixed 40-hour week	One team, a number you type per iteration
What you plan against	Epics or higher, Atlassian projects, and free-text rows like Leave	Estimated work items from the plan's boards, projects or filters
Estimates	Optional. Original estimate only feeds the Resourcing column	Required: story points or time estimates, and boards as sources for capacity
Part-timers	Can't be set. 20 hours shows as 50%	You can type any team total (we typed 140 for 40 + 40 + 20 + 40)
Velocity, actuals	None	Velocity from past sprints
Scope	Site-wide: Add work searches every space, and allocations aren't tied to one space in the API	The issue sources you add
Plans and Capacity sharing data	No. Atlassian: "Capacity data in plans : This is under consideration" (29 July)

One thing we didn't check is whether every space's Capacity tab shows the same plan. We saw no plan picker and no way to create a second plan, and Atlassian's announcement says "The plan spans site level, so allocations are visible across spaces."

If you manage people across several projects and your question is "who's double-booked in November?", the Capacity view is the one. If you run a team on sprints and your question is "will this release fit?", Plans still does that and the Capacity view doesn't try to. Atlassian's product manager put it plainly in the Community thread in March. The MVP helps "plan individual capacity against big rocks of work over a quarter or more directly in Jira" and "does not aim to solve strategic or detailed workload scenarios today."

One naming trap if you're searching: the old Data Center page "Using the capacity view" belongs to Advanced Roadmaps on Data Center. It's a different feature from the Cloud Capacity view in this guide.

How to set up the Jira Capacity view (Premium and Enterprise)

On our site a brand-new company-managed space (we called it ZZCAP) had the Capacity tab already, right after Calendar. An existing space didn't, and it took the + at the end of the tabs to find it. Atlassian's admin note says it's "accessible to anyone with the appropriate space permissions", with no configuration required.

[[steps]]

Open your space and look for the Capacity tab: it sits in the horizontal tabs, near Backlog and Calendar. If it's there, skip to step 3.
Add the tab if it's missing: click the + at the end of the tabs. Under Views you should see Capacity, with the line "Plan contributions and track team capacity in your project." Click Add to navigation, and the tab appears.
Open Capacity: the empty plan says "Balance individual capacity to keep work moving" and offers two buttons, Add people and Upload CSV. The URL ends in /capacity/people, so you're on the People view.
Click Add people and pick your team: the field reads "Search people and teams". Tick each person and click Confirm. Each person becomes a row with an Add work line under it.
Add work under each person: click Add work. Its search box says "Search epic and larger work types". It searches the whole site, so you'll see epics from other spaces too. Tick the epics and click Confirm.
Add time off as its own row: type Leave (or Staff training, or anything else) in the same Add work box and pick "Create: Leave (non-project work, paid time off)". It's created straight away, no Confirm.
Type the allocations into the weekly cells: click a cell, type a number, press Enter. Switch the unit menu (it starts on Percentage) to Hours or Days if you prefer. Each input's label tells you how much is left, for example "Enter allocation for Mihai Perdum to ZZCAP Mobile checkout redesign, 100 remaining".
Check the person totals: switch back to Percentage. Each person's top row sums their week, and anything over 100% turns red.

You don't have to type cell by cell, by the way. Open the legend (the i button). It lists the keyboard shortcuts, and also "Drag blue dot to fill cells" for filling a row across weeks (we typed ours cell by cell).

The two Mihai Perdum rows are two different accounts on our test site, by the way. That second account carries the Leave week. A 40-hour Leave week shows as 100%, so it reads as fully booked.

Besides Weekly, the timescale menu offered Biweekly and Monthly on our site, even though Atlassian's roadmap comment from 28 September still lists "Monthly & Fortnightly Views [COMING SOON]".

Capacity by team member: people, epics and the fixed 40-hour week

Before you put real people into it, here are the limits we hit, one at a time.

Every person is a 40-hour FTE, and you can't change it

Atlassian's doc says it straight: "Capacity plans currently use a fixed 40-hour work week. Custom time-tracking or working-day settings are not yet reflected in these plans." The legend in the product opens with "FTE = 40h per week". And the Resourcing tooltip in the Work view goes a bit further. It says changes to Jira's time tracking settings "will not reflect in the capacity view which is fixed at 8 hours per day, 5 days per week."

We looked for a way around it. A person's More actions menu has exactly one item, Remove person. There's no working hours field in View settings, in the legend or in the header menus either. So we gave Gabriela (me, in the test) 20 hours a week on one epic, and the grid shows 50%. A full-timer with half a week free would show the same. If your team has part-timers, four-day weeks or people split with another department, the percentages are off for them and you'll need to keep that in your head.

It's on Atlassian's list, sort of. Their own RFC from November 2025 planned allocations "anchored to each individual's configurable overall capacity (default 40 hours/week, editable)", under "Later". In July the product manager wrote: "We're considering flexibility here for the future though I'm not able to share a timeline just yet." As of 28 October it hasn't shipped.

Epics or higher, says the doc (a story got in anyway)

The doc says you can add work items "as long as they are epic-level or higher in your work type hierarchy". In the product the Add work box agrees. Searching our story's summary, "checkout button", returned "No results found".

Then we typed the story's key, ZZCAP-4, and it came up with a checkbox. We added it and gave it 4 hours, and the Capacity API returned that 4-hour allocation afterwards. So on our site the search enforced the rule, and an exact key got past it. I'd treat this as something we saw once, on 28 October, that Atlassian may close. Their roadmap comment lists "Level 0 work items: Expanding capacity planning beyond Epics down to standard story or task level work items" as what they're working on now, so maybe it's the start of that.

Over 100% is a warning, never a block

Atlassian's FAQ: "The capacity bar turns red to flag the overallocation, but there's no hard cap." We pushed one person to 54 hours in the week of 26 October and the cell said 135% in red. Jira accepted it without a dialog. Hovering the red bar didn't show any extra detail for us.

The Work view starts empty

Next to People there's a Work toggle. It switches to a view with one row per epic and the people under it. You'd expect it to fill itself from what's in the People view. It didn't: it said "Start adding work" until we added the epics there too, and then their existing allocations appeared. Atlassian's roadmap has "Cross-View Auto-Population [COMING SOON]", so this one is known.

The Work view also has a Resourcing column, fed by the Original estimate. We set a 200-hour estimate on one epic and allocated 4 weeks of 50 hours to it, and Resourcing showed 100%. An epic with no estimate showed 4 with a person icon instead of a percentage. Only one full-timer was on it, for four weeks, so it looks like FTE-weeks (we didn't confirm the unit). We saw no field change on the work items themselves, so the allocations don't seem to write anything back to Jira fields.

No actuals, and no velocity

Nothing in the view reads logged work. Sascha Weber asked for exactly that in the Community thread ("where did he spend his Time already, that's currently an impossible view without marketplace apps"), and as of our test there's still no time-spent column. So what you get is a plan of intent. If you need planned against actual per person, that's still a report you build elsewhere.

Import a capacity plan from CSV with Rovo

If you already keep this in a spreadsheet, the Upload CSV button (with the Rovo icon) is the fast way in. On an empty plan it's on the start screen, otherwise it's under More actions. The doc says to stay on the People view, and that "Rovo will analyze the data and present suggestions. You can accept or dismiss each suggestion individually, or select Accept all".

Our first file failed. It had a row for every person in every week, with the header "Person,Work,Week starting,Allocation %", and the only answer was a toast saying "We couldn't complete your request".

The second file worked. It had one row per person and work item and one column per week:

Name,Work item,Week of 23 Nov 2026,Week of 30 Nov 2026
Gabriela Perdum,ZZCAP-2,25%,25%
LeanZero SRL,ZZCAP-2,50%,50%
Gabriela Perdum,Staff training,25%,25%

Within about 10 seconds the grid previewed the suggestions and the toast said "Suggestions added. Some items missing." Error details had one line:

So the CSV can't create non-project rows like Staff training, and the error says the work must belong to "this space", while the Add work box searches the whole site. We clicked Accept all and the two good rows appeared in the weeks of 23 and 30 November (you can see them as the 25% and 50% cells in the grid above). Keep CSV rows to epics, and add Leave or training rows by hand. We didn't test whether the CSV matches a row that already exists.

Rovo ran three times in our test. We saw no credit counter in the product and didn't pull the usage export, so we don't know what the imports cost. If you're watching Rovo credits, our Think Deeper credits test shows how much the bill can swing by feature, and it's worth checking your own usage page after a big import.

There's also a Rovo skill: open Rovo Chat, type /manage-capacity-plan, and ask in plain words ("Add me to this plan and assign me to Marketing Project for 100% over July" is Atlassian's example). We didn't run it.

Read your capacity plan through the REST API

Atlassian has shipped a public Capacity Planning REST API (its roadmap comment of 28 September marks it "[SHIPPED]"). It's handy for checking what's stored, and it's how we found the cleanup trap below. It worked with basic auth (your email and an API token) on our site. First get your cloud ID:

curl -s https://wolfaenpak.atlassian.net/_edge/tenant_info

{"cloudId":"049de078-bffa-42d1-bbfb-ad8db9860adb"}

Then list the non-project rows, like Leave. Swap in your own site and credentials:

CLOUD=049de078-bffa-42d1-bbfb-ad8db9860adb
curl -s -u "$JIRA_ADMIN_EMAIL:$JIRA_API_TOKEN" -H 'Accept: application/json' \
  "https://api.atlassian.com/ex/capacity-planning/$CLOUD/v1/non-project-work-items"

{"nonProjectWorkItems":[{"id":"055ae1fa-bf87-4e8b-9223-35fa5797ad8a","ari":"ari:cloud:capacity-planning::custom-contribution-target/activation/d0cd8ee8-0829-4199-930e-a54b6fedf70e/055ae1fa-bf87-4e8b-9223-35fa5797ad8a","name":"Leave"}],"pageInfo":{"hasNextPage":false,"hasPreviousPage":false,"startCursor":"TGVhdmUAMDU1YWUxZmEtYmY4Ny00ZThiLTkyMjMtMzVmYTU3OTdhZDhh","endCursor":"TGVhdmUAMDU1YWUxZmEtYmY4Ny00ZThiLTkyMjMtMzVmYTU3OTdhZDhh"}}

That Leave row is the one from our test, still there after we cleaned up. The API has no DELETE for these rows. The API's authorization page says it "enforces the same permission checks as the Capacity Planning UI", so a user can't read through it what they couldn't see in the product.

It also has endpoints for the person-to-work links (contributor-work associations) and the weekly numbers (contributions). We used them to confirm the 4-hour story allocation, and to clean up.

Remove person hides the row, and the hours stay

This one caught us. When we finished, we removed all four people with More actions > Remove person. There's no confirmation, and the plan went back to its empty screen. But the API still returned their links to work and their weekly hours, for example 30 hours a week for one person on the checkout epic. Remove person hides the row. The allocation data stays.

We cleared it with the API (POST to contributions:clear for the 8 person and work pairs, then contributor-work-associations:delete), and re-reading gave 0 links and 0.0 hours. If you're cleaning up a test plan, or someone leaves and you don't want their old allocations lingering, keep this in mind.

Who can see whose allocation: no setting we could find, and untested

Atlassian's line is that the tab is "accessible to anyone with the appropriate space permissions". We didn't find a capacity-specific permission or a "who can see this" setting anywhere in the view. Wurm Peter raised the same worry in the thread. "In most companies, team members aren't allowed to know whether colleagues are assigned 80%, 100%, or 110%." We couldn't test it from a non-admin's seat, because our only non-admin test account has no Jira access and giving it a seat costs a Premium licence. So check it on your own site, with a regular user, before you put real names and percentages in.

Jira team capacity planning in Plans: what the Capacity view does not replace

Plans measures a team, per iteration. From Atlassian's capacity and velocity doc: "Capacity in your plan refers to the number of story points or hours your team can complete in one iteration." For Kanban teams it's hours per week, and capacity information only shows when the plan's work comes from boards.

We built a plan on the same board and added a plan-only Kanban team with the same four people. Then we set its capacity to 140 weekly hours (40 + 40 + 20 + 40). Plans took the number. Its REST record has one capacity field and a list of members, with nothing per member.

So the funny situation today is that Plans lets you type a part-timer's hours into the team total and the Capacity view doesn't let you type them for the person. And they don't talk to each other. If you use both, you keep two sets of numbers.

Does the Capacity view replace a Jira resource planning plugin?

For some teams, yes. If you were paying for an app mainly to see who's booked on which initiative, week by week, and your people all work full weeks, the Capacity view covers that inside Premium. Atlassian even calls it "big rocks" planning.

It doesn't replace one yet if you need any of these. Part-time or custom working hours per person, planning at story or task level (officially), planned against logged time, holidays from a calendar instead of typed Leave rows, or a permission that hides colleagues' percentages. The Community thread keeps asking for them, and two old tracker tickets are still open: JRACLOUD-90363 (capacity per team member, 227 votes, 119 watchers, Gathering Interest) and JRACLOUD-88144 (scheduling plans on user capacity, 188 votes). Neither was closed by the launch. You also don't get dependencies or a critical path in the Capacity view. That's Plans' timeline, or an app (our own LeanZero Management Gantt tutorial is one example of where that lives).

And the cost. Atlassian's pricing page lists Premium at $15.56 and Standard at $8.48 per user per month, at its 300-user reference price. That's $7.08 more per user, about $2,124 a month for 300 people. I wouldn't pay $7.08 a user for the Capacity view alone. If you'd use Plans too, the sum looks different, and our usage-based pricing budget for 50 to 500 seats has the full numbers by seat band. If you're already on Premium, it's included. Try it for a week before you renew an app.

If it didn't work

There's no Capacity tab. Check the + at the end of the space's tabs, under Views. If Capacity isn't listed there, check your plan: it's Premium and Enterprise only. In the summer release thread, an Atlassian PM told a user who couldn't see it that "a space admin will need to add it from the ‘ +' in your top navigation."

Add people says "No results found" for someone. On our site an active user wasn't offered. We think (unverified) it's because he has no Jira product access. Check the person's Jira access first.

Add work can't find your story or task. That's the epic-or-higher rule. Use the epic. (An exact key got a story in for us, but don't build your process on it.)

The CSV says "We couldn't complete your request". Our row-per-week file failed with this. The file that worked differed in more than layout. It had Name and Work item headers and the bare key (ZZCAP-2, without the summary). Its columns were headed "Week of 23 Nov 2026", with a % sign on each value. We changed all of that at once, so copy the example above exactly.

The CSV says "wasn't found. Ensure it is an epic or above work item and belongs to this space." Our case was a non-project row, which you add by hand. The message also says the item must belong to this space.

Removed people still show up in the API. Remove person only hides them. Clear the contributions and associations through the API.

What you have now

[[takeaways]]

A capacity plan in your space, with people on their epics (plus Leave rows) week by week, and red bars where someone is past 100%.
The limits that matter before you rely on it: everyone is a 40-hour FTE, epics or higher (officially), no actuals, the Work view filling only from what you add there, and Remove person keeping the hours.
A CSV format that Rovo imported (one column per week), and the one that failed.
A clear line between this and Plans: per person against big work here, per team against estimated work there, and no data shared between them today.

Are you using the Capacity view with part-timers, and how are you working around the 40 hours? Or did you try it and go back to your app? Tell me in the comments, or mail gabriela at leanzero.net. I'm collecting the workarounds :)

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.

GPT-6.1 Terra Benchmarks: 13th of 48 on Agentic Coding

Mihai Perdum — Wed, 28 Oct 2026 05:58:53 +0000

I like GPT-6.1 Terra more than its score suggests, and I trust it less for long jobs. It scored 0.6953 on our Gauntlet agentic coding benchmark, 13th of 48 ranked runs, for 75 cents. On our Forge 2.0 benchmark its two builds scored 0.4384 and 0.4174, for 73 cents and $1.09. On both boards it passed almost as many checks as models costing up to twenty times more. Then it lost points on behaviour that only shows up after a few virtual hours.

OpenAI released Terra on 26 October 2026 as the mid-tier model of the GPT-6.1 series, and it costs $1 per million input tokens and $5 per million output, which OpenAI says is 50% below GPT-5.6 Terra's standard prices. Their developer forum post says it "finishes tasks over 3× faster on average than both Astra and GPT-6.1 Sol". A few lines later it says "For in-depth research or complex coding, choose GPT-6.1 Sol or GPT-6 Astra." (GPT-6 Astra is the model the same post says Terra matches at one-tenth the price per token.) So OpenAI itself tells you that Terra stops somewhere, and I wanted to find out where that is on our two tasks. At $1 per million input tokens it will get tried behind a lot of coding agents this month, maybe yours, so I wanted our numbers out before that happens.

We ran it the morning after the listing. It ran on the laptop, through goose (the open-source coding agent, in our own fork) and OpenRouter, at medium reasoning effort, Terra's documented default. One Gauntlet run and two Forge 2.0 builds is a small sample. And the Forge pair sits in a comparison group of its own on our board, so treat those comparisons as indicative.

Terra builds fast, edits in small steps, writes very little and stops before it has tested the long path. I'd use it first for short, bounded jobs. Each run here took under 18 minutes and about a dollar. For a Jira app that has to keep its numbers right for six virtual hours under a rate limit (our harness fast-forwards a simulated clock), I'd pick GPT-6.1 Sol or Opus 5.5, or make Terra run the long test before it says done.

GPT-6.1 Terra benchmarks: 0.6953 on Gauntlet, 0.4384 and 0.4174 on Forge 2.0

The Gauntlet gives an agent 150 model calls to build a payments console. It has two services and a 3D field of payment towers, and we score it on 99 checks. Forge 2.0 gives it 300 calls to upgrade a working Jira Forge app to v2. We score that on 105 checks against three seeded Jira test sites. The Gauntlet also has a ceiling rule: if the 3D field fails certain checks, the score can't go above 0.699 however good the rest is. Terra passed 0.9274 of the weighted checks. Then it hit that ceiling. I read these from the boards on 28 October:

Run	Score	Before cap or reliability	Calls	Time building	Bill (OpenRouter)
Gauntlet 7.2	0.6953, 13th of 48	0.9274, capped at 0.699	148	15.4 min	$0.75
Forge 2.0 build 1	0.4384, 26th of 70	0.9128 x reliability 0.4803	74	13.7 min	$0.73
Forge 2.0 build 2	0.4174, 28th of 70	0.8814 x reliability 0.4735	109	17.3 min	$1.09

Call counts include one small Gemini 2.5 Flash call per run that goose makes on the side. The bills are complete, read from OpenRouter's generation records, and the live board on /agentic-benchmarks is the current word if anything moves.

What we found, in five points

Our run page names tower heights as Terra's Gauntlet cap. They didn't set it. Five failures in the 3D interaction band give the same 0.699 on their own, and two of them trace to one line Terra wrote.
Terra shrank its 3D canvas to fit the towers, from 900 by 560 pixels to 660 by 320. Its own measurement printed towers touching the bottom row. The scorer then found the coloured tower tops too small to read.
On Forge 2.0 it passed almost as many checks as GPT-6.1 Sol and lost half its score to reliability. A good part of it went on a background reconcile that refused itself on its own budget and started again from zero, for 24 virtual hours in build 1. The rest is spread over several groups, among them sprint totals that were wrong before any live update arrived and one check almost every model failed.
Its dashboard update arrived live and on time, on a total that was already wrong. The change rows were right and the sums weren't.
It stopped at 73 and 108 of 300 calls, saying in both builds that a six-hour run had not been verified. Jev Router, our own router that sends its calls to GPT-6.1 Sol, spent two of its 43 calls on exactly that rehearsal.

Gauntlet 7.2: 0.9274 earned, 0.699 allowed

The Gauntlet scores in two layers. The raw score is the weighted share of checks passed. Then admission bands put a ceiling on it, so if your 3D field gets certain things wrong the score can't go above 0.699, however good the rest of the app is. And a capped score sits a little under its ceiling (our scorer pulls it down by 0.05 times what you missed).

Terra earned 0.9274, against 0.9342 for DeepSeek V4.1 Flash 1017 and 0.8781 for Gemini 3.8 Flash. All three ended within 0.003 of each other under the same 0.699 ceiling. GPT-6.1 Sol (0.9768 raw) and Claude Sonnet 5.5 (0.9894) cleared that band and stopped at 0.799. So among the three cheap models the cap sets the order, and Terra's raw work is level with DeepSeek's. (Gemini's run sent no reasoning setting at all. And I can't confirm the effort Sol, Sol Pro and Sonnet ran with on the Gauntlet: those runs are from early October and their request logs are gone.)

The tower heights were right, and our probe gave up on one

The run page lists t_height_pixels as the reason for the cap. Terra's height formula is correct. In web/viz.js line 40 it writes clamp(.9+.55*Math.log10(p.amount_minor/10**exp[p.currency]),.2,4.2), with the minor-unit exponent per currency (0 for yen, 3 for the Kuwaiti dinar). For a KWD payment of 992000 that gives 2.548. Our probe predicted 2.5481. Five of the six towers were measured. All five came within a pixel of the prediction.

The sixth, a euro payment, was never measured. Our probe tries up to 600 camera poses to find a clean view of a tower's top, and when it can't, it records noDecisivePose, and the scorer counts that as a failure: 5 of 6. My guess is that the small canvas left too few clean poses. A US dollar tower uses the same exponent as the euro one, and it measured at minus one pixel, so a height bug in Terra's code looks unlikely to me. Every other model in this comparison measured 6 of 6. DeepSeek's and Gemini's canvases were 890 by 480 and 1230 by 598.

I re-graded the run with that check passing, using the scorer's own band function. The ceiling stays 0.699. The 0.799 band has five failures of its own, all listed on the run page, and five failures in that band also cap the score at 0.699. So fixing that check alone would leave the ceiling at 0.699.

The flick that never coasted

The contract asks for inertia. You drag the field and let go. It keeps turning for a moment, then slows down. The release speed comes "from the last two moves". Terra wrote the coast correctly, with an exponential decay. Then it added a rule the contract doesn't have, in the pointer-up handler at web/viz.js line 77:

if(time-lastMove.time>100){vyaw=vpitch=0}

If more than 100 ms passed since the last pointer move, the speed goes to zero. Our probe drags the field 57.6 degrees in a headless browser and lets go, and in Terra's page each probed move took 305.6 ms to draw, so by the time the release was handled the last move was well over 100 ms old. The probe recorded a release speed of 0 and a coast of 0 degrees, and both coast checks failed on it.

I think the cutoff plus slow headless frames did it, though I haven't reproduced it live. My control is Gemini 3.8 Flash. Its page was even slower (1,640 ms per move), and it still released at 4.22 degrees a second and coasted 1.66 degrees. So slowness alone doesn't zero the speed. DeepSeek V4.1 Flash fades the speed instead of cutting it (viz.js line 1186, sinceMove > 0.12 ? Math.exp(-sinceMove / FLIGHT_TAU) : 1) and coasted 12.8 degrees. Sonnet coasted 15.4, and Sol and Sol Pro 8.4 each.

And DeepSeek tested it. Its transcript has three drags with page.mouse.down() (calls 60, 131 and 134). Terra's 150 tool calls contain no mouse drag at all. It wrote viz.js once, at 08:41 laptop time in call 15, and never opened that handler again.

It shrank the picture to make the towers fit

Calls 79 to 107 are a two-minute loop in which Terra wrote a script to measure where the tower pixels sit on screen, cut the canvas, and measured again after each cut. Height went from 560 px to 480, 460, 400 and 320, and the maximum width from 900 to 760, 680 and 660. Its last measurement, at 08:48:07, printed h: 320 ... y: [ 63, 72, 300, 319 ]. Tower pixels sat on row 319 of 320. The visual contract says no tower may sit within 4 CSS pixels of the canvas edge. It moved on.

The scorer found 48 edge pixels and "0/0 readable caps show their status colour" (caps here are the coloured tops of the towers). At that size they were too small to read, so q_overview_legibility scored 0.5. Sol Pro had zero towers on the edge and 96 of 96 caps readable. I think this moment says the most about the model. Terra built itself a measurement, and the measurement showed the rule it was breaking, in its own terminal, four minutes before the run ended. It optimised the number it was watching (how much of the canvas the towers filled) and stopped there.

How it worked: 99 edits, two sentences

Terra made 150 tool calls in 15.4 minutes. 99 of them were edits, mostly three or four seconds apart, on files it kept minified on one line. It wrote two messages in the whole run. The first came at 08:36:50: "I'll build the services and the console against the vendor contract, then exercise the sync and browser paths locally." The second was its summary. It produced 40,190 completion tokens over the run, about 272 per call, and only 5,835 of them were reasoning.

Gauntlet 7.2 run	Calls	Completion tokens	Wall time	Score
GPT-6.1 Terra	148	40,190	923 s	0.6953
DeepSeek V4.1 Flash 1017	147	212,850	1,400 s	0.6957
GPT-6.1 Sol	106	56,390	1,595 s	0.7978
GPT-6.1 Sol Pro	44	75,961	1,275 s	0.9574
Claude Sonnet 5.5	54	329,286	3,076 s	0.7984

DeepSeek made the same number of calls and wrote five times as much, and Sonnet wrote eight times as much in a third of the calls. Terra finished in 923 seconds against Sol's 1,595, and it never exercised the two coast checks it then failed.

And the older Terra

We ran ~openai/gpt-terra-latest on the same Gauntlet task on 6 October. That alias most likely pointed at GPT-5.6 Terra, OpenRouter's newest Terra then, though the logs only show the alias. It scored 0.5781 in 49 calls and 336 seconds. It sent no reasoning effort at all. So the setup differs as well as the model.

Its 3D scene sat in the wrong place on screen: 17 of 120 predicted pixels matched, and none of the six towers could be measured. Its approval notification never reached the page either, which our scorer treats as a dead primary flow (x0.9429). Its outbox relay delivered 50 events every 0.4 seconds, behind thousands of sync events. My guess is that the approval sat in that queue when the probe looked, but the logs can't prove it. GPT-6.1 Terra pulls 500 events per round trip and polls every 3 seconds, and it saw both notifications. On this task the new model is clearly better, mostly in the 3D field.

GPT-6.1 Terra on Forge 2.0: 0.91 of the checks, 0.48 reliability

Forge 2.0 multiplies the share of checks passed (the pre-severity score) by a multiplier for critical defects and by reliability. Reliability is a product over 19 groups of checks. Each group's worst check takes up to 10% off, so a group whose worst check scores 0 multiplies the total by 0.9. Six groups at 0.9 get you to about 0.53. Terra had no critical defects. It had six groups at or near 0.9 in build 1 and five in build 2.

Our board groups runs whose setup matched. Terra's two builds form a group of their own. Sol and Opus share one group. Sonnet and Gemini 3.8 Flash share another. DeepSeek and Jev Router each have their own. But every Forge 2.0 run I compare here used the same task and sent the same medium reasoning effort. Jev Router comes up a lot below. It's our own router, and in this run all 43 of its model calls went to GPT-6.1 Sol (plus goose's one Gemini side call). Its build scored 0.8523, the best here.

One group is a loss Terra shares with almost everyone: a_action_result scored 0 for four of the five models here, Terra included, and Opus got 3 of 5, so I'm not counting it against Terra.

The reconcile that never finished

The task app keeps a scope ledger of what was added to and removed from each Jira sprint, and when Jira drops change events (our test harness drops some on purpose) the app has to heal itself. A background reconcile reads Jira's change history and fills the gaps. It has to stay inside 70% of an hourly rate budget, which is 1,680 points in the task's own rate model (not Atlassian's published quotas). Terra's build 1 meters its own spending before each background request, at src/jira.js lines 26 and 46:

if (used + cost > limit) throw new RateLimited(..., 'local-background-budget');

That part is fine. The refusal is where it goes wrong. Build 1 saves its cursor only when the function is about to run out of time (src/sync.js lines 246 and 275). When it refuses itself on budget, the job is retried up to 900 seconds later. And it starts again from discovery and the candidate search. It never got far. In the heal phase on the hardest seed, our observations show 97 deliveries of that one reconcile, all retries, over 24 virtual hours. They made 192 search pages and only 24 changelog reads. It healed 0 of 4 dropped changes.

Build 2 has no cursor at all. It throws WorkContinues when time runs low, queues a fresh reconcile and searches again. That went on for 1,096 invocations over 273 virtual hours, until Forge stopped it with "The limit on cyclic invocation has been reached." (Forge caps how many times a chain of functions can re-queue itself.) It healed 1 of 4 and kept background spending within its 70% share in only 6 of 829 hours.

My guess for build 1 is a livelock. One full pass costs more than an hour's allowance, and each hour it starts the pass from zero. That reading comes from the call sequence and the code. The 0 of 4 healed is measured.

Jev Router charges itself with the same cost formula, 1 + issueIdsOrKeys.length, at src/jira.js line 25. (It routed to GPT-6.1 Sol here too, as in the run I wrote about earlier this month.) But at src/sync.js line 152 it has a comment Terra never wrote: "Durable reconciliation: each page is checkpointed before the next is requested." It reads pages of 50 issues and stores each page's changelog under its own key before processing it. Its heal phase took 2 invocations and healed 4 of 4. Opus and Sol healed 4 of 4 as well, DeepSeek 1 of 4.

Terra knew the risk. Build 1's last message says "continuation under unusually large workloads have not been fully validated". Build 2's says "Low quota settings can defer reconciliation".

If the heal group and the rate-quota group next to it (10 of 954 person-facing requests refused for quota) had both been clean, build 1 would score 0.541 by my arithmetic from the run document. Fixing the re-estimated totals in the next section alone would give 0.478. Their groups also hold a not-started view and a comment-format failure, and clearing all of them gives 0.591.

A live update, right on time, on the wrong number

Our scorer makes two scripted changes to one sprint and watches the dashboard widget. Terra's live path works. Its backend waits five seconds for the app's own storage index to catch up, then publishes on a global Forge Realtime channel (src/realtime.js lines 17 to 19), and the widget subscribes to it. The added total moved by +5, live, with no polling and no reload. But it moved from 149.5 to 154.5 in build 1 and from 162.5 to 167.5 in build 2. The three builds I compared it with all went from 163 to 168. So u_widget_live scored 0. Our scorer's message for it, "the dashboard does not update live", gets the reason wrong, and that one's on us.

It shows up in other checks too. t_out_of_order reads "11/11 rows exact, 0/3 sprints with oracle numbers" in both builds. Re-estimated sprints matched the expected numbers in 1 of 6 and 2 of 6 (Jev 6 of 6, Opus and Sol 5 of 6). Terra kept v1's computeTotals. So did Jev. I think the fault is in what feeds the totals. Terra reads only the Sprint field's change history (fieldIds: [sprintFieldId], src/sync.js line 205). A story-point re-estimate inside a sprint is invisible to it. And an unhealed dropped change can flip an issue between committed and added. Jev also reads the estimate fields' history and freezes the members of closed sprints. The checkpoint dumps don't carry the rows, so I couldn't diff it issue by issue. Which path lost the 13.5 points is a guess.

What each one ran before saying "done"

A six-virtual-hour rehearsal exercises both defects above. You reset the site, run the reconcile, feed it an hour of events, repeat six times and read the logs. Terra's build 1 tested pieces: event batches of 3, 6, 30, 250 and 700, and the scheduled reconcile four times. It never ran that sequence. The string local-background-budget appears zero times in its transcript, so it never watched its own refusal fire. It stopped at 73 of 300 calls with "a complete six-hour run against the scoring seed was not verified." Build 2 stopped at 108 with "A full six-hour run was not verified." Its last shell command deleted its dev logs.

Jev Router used 43 model calls in total and spent two of them (calls 36 and 37) on exactly that rehearsal, reset; scheduled scope-reconcile; events --limit 165; ... through hour six. Then it grepped the output for killed invocations and errors. Its report: "The dev stream completed with hourly reconciliation and no killed invocations or function errors." Opus didn't run the full six hours either. But it checked its numbers against a recount from Jira for all six active sprints.

I think this is how Terra behaves at medium effort. It writes an accurate limitations paragraph where Jev spends the budget to close the gap. The token counts fit: about 70 reasoning tokens per call for Terra, against roughly 290 for Sol and 370 for Jev's Sol leg, at the same effort label. A model that thinks little per step may be planning little per step, though I've seen it on one task and two builds. We didn't run Terra at high effort, and we haven't tested whether telling it to run the six-hour rehearsal makes it do so.

GPT-6.1 Terra vs GPT-6.1 Sol

Sol won on both boards. On the Gauntlet, Sol scored 0.7978 to Terra's 0.6953. Sol cost at least $1.28 (its bill is a lower bound), Terra $0.75. Both builds are good underneath. Sol cleared the interaction band that capped Terra. On Forge 2.0, Sol's two builds scored 0.6495 and 0.5371 for $1.15 and $1.23. Terra scored 0.4384 and 0.4174 for $0.73 and $1.09, in a different comparison group. Sol used fewer calls (about 48 per build) and more thought per call. GPT-6.1 Sol Pro scored 0.9574 on the Gauntlet in 44 calls, the top run on that board, for $4.91.

Artificial Analysis runs its own coding agent index and puts Terra at 48 and Sol at 54, and on its separate Intelligence Index it finds Terra's low and medium effort levels Pareto-optimal for cost. Our two tasks agree on the order and disagree on the size of the gap. I think ours run long enough for a skipped rehearsal to cost something. On the Hacker News launch thread one commenter wrote "I'm not sure why you would pick Terra over Sol in that case." On our Forge task you'd save little by picking it. A Sol build cost $1.15 to $1.23 and a Terra build $0.73 to $1.09, and Sol's builds scored 0.10 to 0.23 higher.

GPT-6.1 Terra pricing: what a run cost

Run	Bill	Tokens in (cached)	Completion (reasoning)
Gauntlet 7.2	$0.7467	8,183,481 (98.5%)	40,190 (5,835)
Forge 2.0 build 1	$0.7318	6,571,060 (96.7%)	30,722 (5,099)
Forge 2.0 build 2	$1.0853	11,535,044 (97.8%)	43,935 (7,945)

OpenAI's model page lists Terra at $1 in, $5 out and $0.05 for cached input on the standard tier. OpenRouter doubles input and raises output to $7.50 once a single prompt reaches 272,000 tokens. Our largest prompt was 157,263, so that never applied. We were routed to OpenAI's standard endpoint. OpenRouter also lists a Flex endpoint at half price, which would have made these runs about 34 to 52 cents. Most of each bill is cached input that goose sends again with each call, 8 million cached tokens for 40 thousand written.

For scale, on Forge 2.0, Claude Opus 5.5's 0.7294 build cost $20.71. Sonnet 5.5's 0.5899 build cost $5.00 and Gemini 3.8 Flash's 0.4958 build $6.70. Jev Router's 0.8523 build cost $1.15, and DeepSeek V4.1 Flash 1017's 0.6618 build at least $0.32. Terra is cheap. Per point on this board, though, DeepSeek was cheaper, and by a lot.

Why might it behave like this? What the cards say

Model	Size	Context as served	Reasoning effort	Price in / out per M
GPT-6.1 Terra	not published; "same types of data and training as GPT-6 Astra"	1,050,000	none to max, default medium; we sent medium	$1 / $5
GPT-6.1 Sol	not published	1,050,000	low to max, default medium; we sent medium	$2 / $10
DeepSeek V4.1 Flash 1017	552B, about 16B active while decoding, mixture of experts	1,048,576	1 to 100 scale; we sent medium	$0.15 / $0.60
Gemini 3.8 Flash	not published	1,048,576	effort levels, default not stated	$0.825 / $4.125
Claude Sonnet 5.5	not published	1,000,000	adaptive, default high; we sent medium on Forge 2.0	$2 / $10
Claude Opus 5.5	not published	1,000,000	adaptive, default medium; we sent medium	$4 / $20

Sources: OpenAI's Terra and Sol model pages, the Terra system card addendum, the DeepSeek V4.1 Flash model card, the Gemini 3.8 Flash model card, Anthropic's Sonnet 5.5 and Opus 5.5 pages, and OpenRouter's listing for the served context.

OpenAI publishes no parameter count or attention design for Terra, so its card can't explain the reliability gap. Two lines in it do fit what we saw. The system card calls it "a fast, efficient model for high-volume professional work, with strong image analysis and computer use capabilities". That fits a model that looked at its own canvas five times, checked its scene against the app's debug digest twice and measured pixels with a script. And OpenAI's advice to use Sol or Astra for complex coding is what our Forge numbers say too. Sonnet 5.5's default effort is high, so our medium sits one step below its default. For Terra, Sol and Opus, medium is the default.

Where our harness got it wrong

Our Gauntlet probe scores a tower it couldn't measure as a tower measured wrong. And our run page names that check as the cap when another band gives the same 0.699. We should leave unmeasured cases out of the count, record how many scans the probe tried, and print the band that actually binds. Our Forge widget check says "the dashboard does not update live" when the update arrived on a wrong total. It should say the number was wrong. And a_action_result scores 0 for four of the five models I compared here, which usually means the check deserves a look before a model does. Fixing them wouldn't change Terra's 0.6953, 0.4384 or 0.4174, only the reasons the run page prints.

I also couldn't find the goose version these runs used. The run files carry no version string, and the laptop's app was updated after the runs. The three Terra runs sent medium effort, which our app has done since 3.0.116, so they ran on that version or a later one.

Should you use GPT-6.1 Terra for agentic coding?

For short, bounded jobs, yes, and I'd try it first. It wrote a correct height formula for four currencies and a relay that didn't lose the approval notification. Its Forge v2 upgrade passed lint, bundling, manifest and scope checks. Each run took under 18 minutes and about a dollar. For work that has to survive time, like background sync, retries under a rate limit or anything that runs for hours after you look away, I'd use GPT-6.1 Sol or Opus 5.5. Or keep Terra and make the rehearsal part of the task. Tell it to run the long scenario and show you the log before it says done. In both Forge builds it wrote down that the six-hour run wasn't verified. At medium effort it didn't go and run it.

The goose fork we ran this in still isn't a polished product (we use it because we know where it squeaks), and it produced every number above. If you've put Terra behind an agent for something long-running, did it stop early and leave you a careful note about what it hadn't checked, or did it run the long test when you asked? Tell us in the comments under this post. Each run above, with its video and its bill, is on the benchmark page, and the October roundup has the rest of the field.

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.

Rovo Credits Cost: We Got Think Deeper Wrong (10 to 182)

Mihai Perdum — Tue, 27 Oct 2026 19:35:13 +0000

Two weeks ago we told you a Think deeper message in Rovo costs 65 to 86 credits. That was wrong. We measured two runs on one evening and wrote the range up as if it meant something. When we exported our org's usage five days later, it had single chat messages at 203, 238, 268 and 310 credits, and nobody went back to check the article against it.

Then an admin at another company told us they're seeing single calls above 300. So on 27 October we went back to our test org (a pool of 3,920 credits this period) and sent 21 more messages, one at a time, reading the meter after each. They cost 1,285 credits. Think deeper came in anywhere between 10 and 182. The same prompt, word for word, cost 12 on one run and 134 on another.

It's a small sample on a small org, and I'll say where it runs out. If you put our 65 to 86 into a budget, take it out. The original article stays up as it was.

What our usage export says

Atlassian Administration will email you a CSV with one row per billable Rovo event (Gabriela walked through the export in how to check Rovo credits usage for each user). Ours was exported on 20 October 2026 at 21:46 UTC and has eleven columns: Usage Id, Usage Count, Date, Org ID, Site ID, Site Name, App, Actor ID, Feature, Agent, Feature Status. There's no column for the mode.

It has 19 Rovo Chat rows between 8 September and 20 October. Sorted by credits: 10 eleven times, then 65, 77, 78, 86, 203, 238, 268, 310.

Three of the big ones came within twelve minutes of each other on the morning of 11 September (310, 268, 238). On 14 October at 07:56 UTC came the 203, the same day we measured. That evening also had two messages at 77 and 78 that never made our table. I don't know what those prompts were. Nobody wrote them down, and I'm not going to guess.

We picked two cheap runs and didn't look at our own data afterwards. That's on me.

Rovo credits per prompt: the same prompt cost 12, 49, 65 and 134

We started by repeating our own 15 October prompt, the one that cost 86: "Our 40-person company runs Jira Standard and Confluence Standard. Draft a one-page plan for rolling out a change advisory process: roles, approval steps, and what to measure in the first month."

We forced Think deeper from the mode menu on each run. Four runs: 134, 49, 65, 12.

Look at the 12. Rovo's step panel on that run says "This is a writing task, so I don't need heavy tool use", and it finished in 2 steps. On the 65 run it ran a Teamwork Graph search first. For the 134 and the 49 we didn't capture the steps, so I can't tell you what Rovo did on those.

What moves Think deeper credits from 10 to 182

Here are the 21 messages, all on our wolfaenpak test org. The meter never moved between messages, so nothing else was spending, and each message's full charge was already there at the first read, 21 to 22 seconds after the answer.

What we asked	Mode	Read site data?	Credits
Change advisory plan, four runs	Think deeper	not captured, not captured, Teamwork Graph search, no	134, 49, 65, 12
Same plan as a thread, follow-ups 2 to 4	Think deeper	no	44, 29, 26
Summarise a 100-word incident report	Think deeper	no	10
Summarise a 2,000-word incident report, twice	Think deeper	no	23, 26
Write a 1,500-word rollout plan, twice	Think deeper	no	16, 15
Summarise every page in a 13-page Confluence space, twice	Think deeper	yes	57, 80
Group all 469 open items in a Jira project, three times	Think deeper	yes	106, 182, 141
Follow-ups on that Jira thread	Think deeper	yes	86, 79
Find payment and login failures across every Jira project	Think deeper	yes	94
The 469-item Jira question again	Let Rovo decide	yes	11

In Think deeper, every run we could inspect fits one rule: the price followed whether Rovo went off to read Jira or Confluence. Runs where it read nothing cost 10 to 26 as fresh messages. Runs where we saw it read site data cost 57 to 182.

I thought length would drive it. Pasting 2,000 words instead of 100 added about 15 credits. Asking for a 1,500-word plan got answers of about 2,000 words for 15 and 16 credits.

Steps aren't the meter either. The run with 75 steps cost 79, the one with 54 cost 94, and the one with 27 cost 182. On the 182 run Rovo did 5 Jira searches over 469 open items and named 33 of them in its answer. My guess is the charge follows how much text goes through the model while it reasons, retrieved data included. I can't prove it, and Atlassian doesn't publish a formula.

Our plain thread went 49, 44, 29, 26, and the Jira thread went 141, 86, 79, so later messages didn't get dearer. Follow-ups did cost a bit more than a fresh short prompt (26 to 44 against 10 to 16), which would fit a small charge for the context the thread carries. Three data points, so treat it as a hint.

Then the row that annoyed me most. On Let Rovo decide, the 469-item question cost 11 credits. That answer says it reviewed all 469 items, found the same six themes, counted the same 166 overdue items and named 26 work items. Its step panel says Completed 24 steps. On Think deeper the same question cost 106, 141 and 182. The work looked the same from where I sat. It's one run, so I won't call it a rule, but on that question the mode label was the difference between 11 and 182.

Rovo credits pricing: Atlassian's own bands already allowed 300

Atlassian's pages allowed for all of this. We misread them.

The How Rovo credits work page lists Think deeper under "Variable credits per billable event" and names four things that move the number: "Reasoning steps", "Search volume", "Tools invoked" and "Model power". It also says Think deeper "dynamically plans, searches, reasons, and iterates to return a thorough answer, with built-in quality validation that automatically retries if it doesn't meet the quality bar." Atlassian's usage pricing page adds "the output generated", which our long-answer runs didn't bear out.

That support page also links an image called "Rovo Credits: Task Types". Light tasks are "Estimated Rovo Credits 10-200". Medium tasks are "201-500". Heavy tasks are "500+". The Wayback Machine's capture of 14 September doesn't have the image, and its capture of 17 September does. We quoted those bands in the first article and also wrote that Atlassian "publishes no number" for Think deeper. The second statement was wrong, and I should have caught it.

So our 310 sits in Atlassian's own medium band, and a 300-plus call like the one we were told about is at least medium. The card has a heavy band above 500.

Rovo "will activate think deeper mode automatically if it detects a multi-layered or open-ended prompt", says the reasoning modes page. Your users don't have to pick the expensive mode to get it. And Rovo shows no estimate before you send. ROVO-866, "Show estimated credit cost before submitting a prompt", had 6 votes on 27 October, and its description still quotes June's flat 10 and 100.

Why this hurts on 3 December

From 3 December, extra usage is billed at "$0.01 per Rovo credit, or $10 per 1,000 credits", and "extra usage is on (by default)". A Jira Standard seat gets 25 credits a month. So our 182-credit Jira question is more than seven seat-months, and the 310 is twelve, or $3.10.

Your pool is shared, and you can't cap a person yet. The support page says "Coming soon: you'll be able to allocate Rovo credits by user", with no date. On ROVO-1224 a customer wrote on 26 October that one user spent 101,000 of their org's 196,000 credits in a month, and added: "Hearing there is no timeline for said feature feels nothing more like a cash grab." The broader request, ROVO-532, had 57 votes.

You can't switch Think deeper off for Chat either. ROVO-1302 asks for control over the automatic switch (2 votes), and ROVO-1317 asks for an admin setting for the default mode (12 votes). And a usage limit won't stop an expensive message halfway: when a limit is hit, Atlassian says work already running completes and only new credit-consuming requests pause.

Afterwards you can't see which messages were the expensive kind. Our Features tab for the billing period that started 15 October, test included, shows "Rovo Chat 1,438 credits", every mode on one line. That's a different window from the export's 1,435, so the near match is a coincidence. The Teamwork Graph line stayed at 0 even though Rovo ran Teamwork Graph searches inside our chats.

No quote before you send, no mode in the export, no cap per person. I can't budget that, and I doubt you can.

What I'd do as an admin this week

Export your CSV now and sort the Rovo Chat rows by Usage Count. If your top rows are in the hundreds, that's your real per-message price. The export walkthrough shows where the button is, and the emailed link expires after 24 hours.
Tell people which questions cost money. Asking Rovo to read a project or a space ("look at all open items", "summarise every page") was our expensive class. Writing and rewriting stayed cheap even in Think deeper.
Try Let Rovo decide on the big read-everything questions before Think deeper. In our one run on the 469-item question it found the same themes and overdue count for 11 credits. One run proves little, but it's a cheap thing to test on your own org.
Set a usage limit before 3 December, or decide not to on purpose. The usage limit walkthrough covers both settings.
Re-check any budget built on a fixed Think deeper price. Ours modelled it at 75.5 credits in the usage-based pricing budget, which is too low for data questions.

Some of this we couldn't test. Deep Research has disappeared from the mode menu on our org, and the chat composer has no agent or model picker, so nothing here covers either. Our biggest Jira project has 469 open items and our biggest Confluence space has 13 pages. Yours are probably bigger, and my guess is that's how people get past 300.

What's the most expensive single Rovo message in your export? If you've got one above 310, I'd like to know what the question was.

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.

Rovo Dev Pricing After End of Life: Standard, CLI, Credits

Mihai Perdum — Tue, 27 Oct 2026 11:59:41 +0000

Rovo Dev pricing today is $20 per developer a month for Rovo Dev Standard, with 2,000 Rovo Dev credits and $0.01 for each extra credit, and Atlassian has said Rovo Dev will reach end of life as a standalone product. On 27 October I wanted to count how many of those credits a normal coding task eats. So we logged the Rovo Dev CLI into our test org and gave it a one-line job. It answered "Rovo Dev CLI is not enabled for this organization." The site's own Rovo Dev page offered a free 30-day trial of Rovo Dev Standard, and the button behind it said "Rovo Dev sign-up is no longer available." So at the end of October 2026 you can still pay for Rovo Dev, and you can't start it.

The reason is on Atlassian's licensing page: "Rovo Dev as a standalone product will reach end of life." There's no date yet, only "at least 60 days' notice". If you run engineering or pay the Atlassian bill, you're holding seats at $20 per developer a month for a product whose replacement has no price. Ten developers cost $200 a month, 50 cost $1,000 and 200 cost $4,000.

The $20 seat was always a prepaid bucket of 2,000 credits at exactly one cent each, which is the same list price Atlassian charges for an extra Rovo credit. If that one-to-one holds when the CLI moves into Rovo credits, the developers who barely use Rovo Dev get much cheaper and the heavy users cost about what they cost today. If it doesn't hold, nobody can tell you the after-price yet, including us.

Three separate events are coming, and I'll keep their names straight: the Code Reviewer switch on 3 December 2026, the CLI migration to the Rovo CLI (no date), and the final end of life (no date). If you only want the checklist for your seats, it's the last section.

Six things we found: $20 seats, no end date, no exchange rate

Standard costs $20 per developer a month. The pricing page says "$20 per developer / month" with "2,000 Rovo Dev credits per developer" and "$0.01 per credit" after that (we read it on 27 October 2026). Rovo Dev Free gives 350 credits per user, per month, per site with no extra usage.
The end of life has no date. The Rovo Dev FAQ lists the Rovo CLI migration, the IDE retirement and the final end-of-life date under "Upcoming (Dates TBA)". The only firm date is 3 December 2026, for Code Reviewer.
Two Atlassian pages disagree. The pricing page carries an end-of-life banner. The support page "How billing works for Rovo Dev" still sells Standard and mentions no transition at all (we searched it for "end of life", "transition" and "retire" and got zero hits).
There's no exchange rate. Atlassian says Rovo Dev credits and Rovo credits are "different and separate" meters and has published no rate between them, and no price for the Rovo CLI.
At list price the seat and the credit cost the same. $20 for 2,000 credits is $0.01 a credit, and an extra Rovo credit is "$0.01 per credit over your allowance". At one-to-one, 200 developers who each use 350 credits would cost about $650 a month instead of $4,000.
New sign-ups are closed in practice. On our org the trial button ended at "Rovo Dev sign-up is no longer available", Add app doesn't list Rovo Dev, and the CLI's credit check came back FEATURE_DISABLED_ORG_LEVEL.

Rovo Dev pricing today: Free, Standard at $20 and $0.01 per extra credit

These are the numbers on Atlassian's pages on 27 October 2026. I'm quoting them because two of the pages say slightly different things.

	Rovo Dev Free	Rovo Dev Standard
Price	"Free with Jira paid plans"	$20 per developer per month
Credits	350 per user, per month, per Jira site	2,000 per developer per month
Extra usage	"Not available"	$0.01 per credit
When credits run out	stops "until your usage resets in the next billing cycle"	keeps working if paid extra usage is enabled, up to any limit an org admin set
CLI and IDE	the usage doc says 350 credits cover "1 to 10 tasks in Rovo Dev CLI"	yes, on a paid subscription (not during the trial)

The billing page even has a worked example. 100 users on Standard, with 50 of them using 500 extra credits each, comes to $2,000 plus $250, so $2,250 for the month.

Atlassian's pricing page shows no Free tier at all, while the billing doc lists one, and I think that's why some people never realise Free exists. The billing doc also says 2,000 credits "per user", while the usage doc and four other support pages say the 2,000 sit "at the organization level". The billing doc's own example treats them as per user, so that's how I've done the sums.

How far do 2,000 credits go? Atlassian's own estimate is "20 to 75 code reviews, or 5 to 50 tasks in Rovo Dev CLI. More complex tasks require more credits." That works out to roughly 40 to 400 credits for one CLI task. We wanted our own number for this and couldn't get one.

Can you move light users to Free today? Atlassian's rollout page says that "Starting in mid-October, Rovo Dev is gradually rolling out to sites with Jira Standard or Premium plans at no extra cost", with the 350-credit allowance. None of the pages we read describes moving a paying Standard user back to Free, and our org has no Rovo Dev to test it on. So ask Atlassian Support before you count on it.

Rovo Dev end of life: what Atlassian has announced and what it hasn't dated

Everything firm sits on one page, the Rovo Dev FAQ. I read it in full on 27 October.

The product first. "Rovo Dev as a standalone product will reach end of life," with "at least 60 days' notice", and "No immediate action is required."

Code Reviewer moves into paid Jira: "Code Reviewer will transition to Rovo Credits on December 3, 2026." Before that date, once it shows up in your Jira, "you can use it without Rovo Credits metering during the transition window". Atlassian adds that 3 December "is not the Rovo Dev end-of-life date."

For the CLI, "Rovo Dev CLI is evolving into the unified Atlassian Rovo CLI experience, which will operate under Atlassian's Usage-Based Pricing model after the transition." Meanwhile: "Continue using Rovo Dev CLI until migration instructions are shared." Bitbucket Pipelines keeps Rovo Dev CLI until the Rovo CLI exists, and ordinary builds are "completely unaffected". The IDE goes: "Standalone Rovo Dev IDE capabilities will be retired." AtlasCode, the VS Code extension for Jira and Bitbucket, stays.

And your subscription? "Atlassian will not automatically cancel your Rovo Dev subscription." Code-Reviewer-only customers get a notice when it's live in Jira so they can cancel. CLI and IDE users are asked to "keep your Rovo Dev subscription active until the transition paths and instructions for those capabilities are released." Annual customers are told "Your investment and prepaid term are fully protected" and that Atlassian is "working to ensure a fair commercial transition". Anyone with an annual or recently renewed subscription is asked to contact Atlassian Support. I don't know whether that means a refund, a credit or running to the end of the term, and the page doesn't say.

The page gives no date for the CLI migration, the IDE retirement or the final end of life. They're all "Dates TBA", and I didn't find a Rovo CLI price on any Atlassian page we read. The one place "Rovo CLI" sits next to money is the Rovo licensing page, where it's listed among "Premium AI interactions" with "Variable pricing per billable event".

A few of the support docs haven't caught up yet. The pricing page, the product page and the FAQ all carry the end-of-life message, while the billing page, the trial page and the "Add Rovo Dev Standard" page still describe buying and trialling Standard as if nothing changed. One trial page still says, from an earlier change, that after 22 June "Rovo Dev CLI, IDE and AI code review, will continue to be available through a Rovo Dev Standard subscription." Both versions are live today. When pages conflict, I go by the one that is newest and most specific about the change, which is the FAQ.

Rovo Dev CLI becomes the Rovo CLI: is Rovo CLI free, and what will it cost?

Not as a free product of its own, and there's no price yet. Atlassian says the Rovo CLI will "operate under Atlassian's Usage-Based Pricing model", which means it draws from your org's Rovo credits once billing applies to it. Your org's Rovo credits come from your seats. Jira or Confluence Standard gives 25 per user a month, Premium 70 and Enterprise 150, and Teamwork Collection or Service Collection gives 250, 700 and 1,500. They all go into one shared pool, and extra credits are $0.01 each (that's $10 per 1,000).

So is the Rovo CLI free? A small slice of it is probably covered by the credits you already have. How small depends on a number Atlassian hasn't published: how many Rovo credits one CLI task costs. Atlassian already lists the Rovo CLI as a "premium" interaction with variable pricing, so I wouldn't expect it to sit at the cheap end of the scale.

While we tested, the CLI binary that acli downloaded on 27 October reports itself as "Rovo Dev CLI: 202610.27.1", and its own doctor command already describes itself as "Run Rovo CLI diagnostics". The rename has started inside the tool before Atlassian has published a date or a migration guide, so please don't plan on it yet.

"Rovo Dev CLI is not enabled for this organization" and the other messages we hit

Here's our first CLI task on our test org (acli 1.3.39, 27 October 2026), with our cloud ID replaced by a placeholder:

$ BILLING_CLOUD_ID=<wolfaenpak cloud id> acli rovodev legacy "Reply with the single word OK."
Working in /private/tmp/lz-rovo-dev-pricing/sandbox

─── Rovo Dev CLI is not enabled for this organization. ─────────────────────────

To use Rovo Dev CLI on this organization, enable it in Rovo Dev settings. Rovo
Dev settings

────────────────────────────────────────────────────────────────────────────────
────────────────────────────────────────────────────────────────────────────────
Run without an interactive terminal, so the billing site could not be
selected. Pin the billing cloud ID for headless runs by setting the
BILLING_CLOUD_ID environment variable before invoking the CLI, e.g.
BILLING_CLOUD_ID=<cloud-id>.
You can find a site's cloud ID at
https://<your-site>.atlassian.net/_edge/tenant_info.
────────────────────────────────────────────────────────────────────────────────
────────────────────────────────────────────────────────────────────────────────
To resume your session, restart Rovo Dev CLI with the --restore flag.
────────────────────────────────────────────────────────────────────────────────
✗ Error: failed to execute the command
exit=1

Login had succeeded. The refusal comes from the credit check, which the CLI's log shows returning FEATURE_DISABLED_ORG_LEVEL.

We hit five messages that stopped us on 27 October, in the order a new user meets them. Before login, acli rovodev says "to get started, authenticate your Atlassian account: 1. Create a Rovo Dev scoped API token" (our classic API token logged in fine anyway). A headless run then stops at "Billing site not set", and setting BILLING_CLOUD_ID gets the run past it to the credit check (the billing-site notice still prints). Next comes "Rovo Dev CLI is not enabled for this organization." The CLI links you to "Rovo Dev settings", and on our org that link redirected to the Rovo access page, which has no Rovo Dev control on it. On the site itself, /rovodev says "Rovo Dev is not activated on this site", and its trial button leads to "Rovo Dev sign-up is no longer available".

Rovo Dev credits vs Rovo credits: two meters, no published exchange rate

Atlassian is clear that these are two meters. The usage doc says "Rovo Dev credits are different and separate from Rovo credits", with Rovo Dev credits for the CLI and code reviews and Rovo credits for Rovo Chat, agents and Deep Research. The usage-based pricing FAQ lists Rovo credits, Automation steps, Assets objects, Bitbucket meters and AI agent resolutions, and doesn't mention Rovo Dev at all.

What nobody has published is a rate between the two. Our Code Reviewer article ran into the same gap last week. Both meters charge $0.01 for an extra credit. Equal prices for an extra credit still don't tell you that one Rovo credit buys as much as one Rovo Dev credit. A CLI task could cost 100 Rovo Dev credits today and 150 Rovo credits after the migration, and the price tag on both credits would still read one cent.

My after-costs all assume a one-to-one rate: one Rovo credit buys what one Rovo Dev credit buys today. Treat it as the optimistic case. If the real rate turns out different, the after-costs change with it, roughly in proportion.

Rovo Dev cost for a 10, 50 or 200 developer team, now and after the move

Today's cost is just seats. 10 developers on Standard cost $200 a month, 50 cost $1,000 and 200 cost $4,000, whether each developer uses 50 credits or all 2,000.

After the CLI migration there's no seat. Each developer's own Jira seat adds credits to the shared pool, and anything above the pool is billed at $0.01. The table uses the one-to-one rate. It counts only the 25 credits a month that each developer's own Jira Standard seat adds. I've priced three levels of use.

Team	Today, Standard	After, 350 credits each	After, 1,000 each	After, 2,000 each
10 developers	$200	$32.50	$97.50	$197.50
50 developers	$1,000	$162.50	$487.50	$987.50
200 developers	$4,000	$650	$1,950	$3,950

I picked 350 because it's Atlassian's Free allowance, which Atlassian says covers "1 to 10 tasks in Rovo Dev CLI". 2,000 is a full Standard allowance. On Jira Premium (70 a seat) the full-use row drops only a little, to $193, $965 and $3,860. Teamwork Collection is where it moves: Premium (700 a seat) gives $130, $650 and $2,600, and Enterprise (1,500) gives $50, $250 and $1,000.

Keep in mind the pool is shared. Those 25 credits per seat also pay for Rovo Chat and agents, and from 3 December for Code Reviewer, across the whole company. Every seat in the org feeds it, developers or not. To use your own numbers, open Atlassian Administration, then Usage, Meters, and read the Rovo credits row. Use your spare credits in place of the 25-per-seat line, so the after-cost is roughly (developers x credits each, minus spare) x $0.01. Our test org's allowance is 3,920 and its monthly average is 1,189, so we'd have about 2,700 spare. A 200-seat company that already uses Rovo Chat heavily might have none.

The rate might not be one, either. Atlassian already lists the Rovo CLI as a premium interaction, and if that means more Rovo credits per task, every "after" column grows roughly by that ratio. At 1.5 Rovo credits per Rovo Dev credit, the 200-developer full-use row would be about $5,950, more than today.

And nobody knows the timing. Atlassian has said "at least 60 days' notice". If notice came tomorrow, the earliest switch would be in late December. Whether you'd pay for a Standard seat and Rovo credits for the same work in that month isn't covered on any page we read.

"You've reached your Rovo Dev credit limit": what it means and what the admin can do

One Community thread called "rovodev standard trial not working, You've reached your Rovo Dev credit limit" has 1,994 views, and another with the bare error as its title has 1,383. One asker wrote, "I have 0 usage of rovodev credits and still I'm getting You've reached your Rovo Dev credit limit!!!" An Atlassian team member replied on the first thread that they'd "uncovered a bug while rolling out new changes".

When the limit is real, the fix depends on the plan. On Free, Rovo Dev "will stop working until your usage resets in the next billing cycle", and there's no extra usage to buy. On Standard, an org admin can raise or switch on the extra usage limit (the billing doc puts it under Insights, Platform usage, Rovo Dev credits, then the Credit settings tab). Once a user runs through their credits and any extra usage, "Rovo Dev functionality will be disabled for them until the next billing cycle". For code reviews, the credits come from "the pull request author's allocation", so a developer who's out of credits also stops getting reviews.

On our org, though, the Insights menu now only has Analytics and Audit log, and the old Platform usage address doesn't open any more (usage lives under Usage, Meters). We can't tell you whether the Rovo Dev page moved with it, because we have no Rovo Dev to look at.

We couldn't measure one Rovo Dev credit: sign-up goes to sales

We meant to run three fixed tasks of known size through the CLI (explain a file, fix a failing test, a multi-file refactor) and read the credits each one used. We updated acli from 1.3.23 to 1.3.39 and logged in. The credit check refused us. Our org's Add app page offers three collections and six single apps, and Rovo Dev isn't one of them. Atlassian's trial doc still says "Under Rovo Dev, select Try it now". The site's trial button sends you to sales, and we weren't going to ask sales for a product that's being retired just to count credits.

So we don't have our own credits-per-task number, sorry. Atlassian's 5 to 50 tasks per 2,000 credits is the best figure out there. Our org's Rovo credits export from 20 October has 39 rows and not one of them is Rovo Dev, as you'd expect on an org that never had it.

Should you cancel your Rovo Dev subscription? Cancel unused seats, keep the CLI ones

If I were holding Rovo Dev seats this month, I'd go through them like this.

Don't sign anything annual. Atlassian protects existing annual terms, but a new annual commitment to a product with an announced end of life buys you nothing. The pricing page only offers annual through sales anyway.
Sort your seats into three groups. Code Reviewer only, CLI or IDE users, and people who never use it. The billing doc puts per-user numbers under the Rovo Dev credits Users tab, and each developer can see their own breakdown by feature on the Rovo Dev "Your usage" page.
Cancel the seats nobody uses. A seat that used 50 credits last month still cost $20. Atlassian bills "any user who has write access to Rovo Dev features". So an org admin removes those people from the rovo-dev-agents-users- group (and any other group with the Rovo Dev User or App Admin role). Cancelling the whole subscription is "Contact us" on the billing doc, and the credits last until the end of the billing cycle. If you're not sure the next invoice will drop, one line to support settles it: "We've removed these users from the Rovo Dev Standard group. Please confirm they won't be billed from the next cycle, and whether they stay on Rovo Dev Free."
Hold the Code-Reviewer-only seats until Atlassian's notice. When Code Reviewer appears in your Jira it runs without Rovo credit metering until 3 December, and Atlassian says it'll tell you when you can cancel. Our Code Reviewer setup guide covers what each review costs after that.
Keep the CLI and IDE seats active. Atlassian asks you to, and there's no Rovo CLI to move to yet.
Set a Rovo credits limit before 3 December. Code Reviewer will draw from the same pool as Rovo Chat, and the Rovo licensing page lists extra usage as "on (default setting)". Our guide to the Rovo usage limit walks through the screens, and the 2027 budget for 50 to 500 seats shows where Rovo sits next to the other meters.

If I had to bet, most teams will pay less after the CLI migration. An Atlassian team member wrote in October 2025 that 2,000 credits a month "suits most users", so most seats probably aren't using all of it. If most of yours sit under 500 credits a month, the one-to-one table says you'd pay about a quarter of today's bill or less. That bet depends on a rate Atlassian hasn't published, so I'll come back and update this page when the Rovo CLI price or the end-of-life date appears.

How many of your Rovo Dev seats used their 2,000 credits last month? If you've looked at the per-user numbers, I'd love to hear what share of your developers are heavy users, in the comments or at office@leanzero.net.

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.

Confluence XML export end of life: CSV tested

Mihai Perdum — Tue, 27 Oct 2026 08:58:50 +0000

Confluence Cloud's XML site and space export reaches end of life on 1 December 2026, and Atlassian's supported replacement is the CSV export, so we exported the same space both ways to see what each file keeps. On our test space CSV kept all the content XML kept, plus two things XML dropped. The catches are elsewhere: CSV can't go into Data Center, it carries no email addresses, and Backup manager doesn't let you pick a format at all. Its two buttons decide it, and we ran both.

You'll find the date in Atlassian's knowledge base article on the XML export end of life, updated on 6 August 2026, and in the Community announcement from 1 June, which had 1,922 views when I checked this morning. Only two people commented on it, and nobody from Atlassian has answered either of them. One asked "What about XML imports on Cloud?". The other asked Atlassian to keep XML until Data Center itself reaches end of life. If you run Confluence for a company, you've probably asked both of those yourself.

On 27 October we built a small space on our own test site with as many kinds of content as we could think of. Then we exported it as XML and as CSV, imported both files back, and compared them item by item. We also looked at Backup manager and at what a script can still call. Our site is on Premium.

[!NOTE]
Prerequisites: Confluence Cloud, and space admin permission on the space you export (Atlassian's import doc: "You must be the space admin to export"). Importing a space back needs site admin, and you need Confluence admin for the Backup manager screen. We tested on one Premium site with a space of about 20 objects, all created by one author, so treat the timings as indicative. CSV export is on every plan, per the KB: "Free, Standard, Premium, Enterprise".

Confluence XML export end of life: what changes on 1 December 2026, and what doesn't

Nothing gets switched off. The KB is clear: "The features continue to work — they have not been removed from the product". Then it adds "Atlassian will no longer fix bugs, accept support tickets, or provide SLAs for XML export". And "You use XML export at your own risk". Your runbook will still run on 1 December. If the XML export breaks after that, though, you can't raise a ticket about it.

Two more lines from the KB matter for planning. "XML Import is not in scope for this change", which answers the first commenter, at least for now. And "CSV cannot be imported into DC". The KB's own checklist tells you to "Identify any automated scripts, scheduled jobs, or internal runbooks that use XML Site Export or XML Space Export". It also says to "Keep one final XML export as a transitional backup until you've fully validated your CSV workflow." I'd do that last one this week, while XML is still supported.

A Wayback copy from 8 June has the same date. Atlassian added the "Action required" box and the verification section between June and August, so if you read the page back then, it's worth reading again. I re-read it this morning.

Who must act before 1 December, and who can ignore it

You need to do something if your runbook or a scheduled job uses XML Space Export or Create backup for server. For a space export, switch to CSV, run it once, and restore it into a test space the way we did further down. For a site backup, switch to Create backup for cloud and download the file. If Jira is on the same site, our Site Import page says a whole-site restore isn't available and points you to importing spaces one at a time, and Import spaces takes only space exports. We didn't try feeding it a site backup. So keep CSV space exports of the spaces you'd need back, and test restoring one.

You also need to act if a script starts your exports or backups. There's no documented API for a CSV space export. The backup endpoint scripts have used for years still answered for us, but it's undocumented. So decide: keep running the old call unsupported, or move to Atlassian Backup and Restore. You can only buy that on an annual Premium or Enterprise plan. On Free or Standard there's no supported way left to automate a backup (CLOUD-12817: "Standard customers will lose the ability to automate the backup creation process"), so it's a manual Create backup for cloud or an upgrade.

If you could ever need your Cloud content in Data Center, take one XML export now, test it while Atlassian still supports it, and ask Atlassian Support what they'll offer after December.

And if a compliance or legal team parses your archives, give them a CSV sample now. Their tooling probably reads entities.xml, and the CSV zip is a different set of files with no email addresses in it.

You can mostly ignore the date if you only export spaces to move them between Cloud sites. Since 2023 Atlassian has called CSV the preferred format for a single space you re-import into Cloud, and in our test it kept all the content XML kept. For moving a whole site, Atlassian now points to copying product data instead.

Switch the Confluence Cloud backup to CSV in Backup manager (the Create backup for cloud button)

The KB says "For Site Backup/Restore: Go to Confluence Settings → Backup Manager / Select CSV as the export format instead of XML". Our Backup manager had no format selector.

It has two buttons. Create backup for server sits under "Moving to Confluence Server" ("you can import a backup of this site into Confluence Server 6.0 or later"). It has the same yellow end-of-life text, so that's the XML one. Create backup for cloud sits under "Restoring a Confluence Cloud backup", and the KB's further-reading list says "Create backup for cloud" exports in CSV format.

We ran both on our test site, which has about 50 spaces, with Backup attachments unticked to keep the files small. Create backup for cloud showed PROCESSING under the button and finished in 3 minutes 14 seconds. The download was called confluence_backup_csv_2026-10-27.zip and weighed 14.7 MB. Inside were 50 gzipped table files, a whiteboard file and a metadata.json, and no entities.xml. So yes, cloud means CSV.

Create backup for server first opened a dialog called "Understanding why you backup", asking whether this was an offline backup, a merge or a move to server, plus an optional server licence number. We left it on Offline backup. It took about 26 minutes and gave us a 21.3 MB Confluence-export.zip with one entities.xml inside, 472 MB once unpacked. So server means XML. It was also eight times slower for us, which surprised me.

About six minutes into the server backup, the page put up a red box: "Export error / Export in progress - not responding", with a request to contact Atlassian support. It wasn't true. The progress call at the same moment said "Writing export" at 23%, and the backup finished fine. We saw it once, in a headless browser, so it may not show up for you. If you see that box, check the progress (below) before you open a ticket. The page also shows only one download link, for the newest backup, so the second backup replaced the first one's link.

Atlassian's own site backup doc muddies this. Its only step is "Choose Create backup for cloud". The same page says "You can import the backup data into Confluence Data Center 6.0 or later." That can't be true of a CSV file, given the KB's "CSV cannot be imported into DC". If a Data Center restore matters to you, use Create backup for server and test the restore.

The doc also has the numbers you'll want for a real site. A backup "can be up to 30 GB in total size, plus 800 GB of attachments". Only one backup file is kept at a time. The Backup manager screen says files are "automatically deleted after 14 days". So download each one and store it somewhere you control. And if your boss asks whether Atlassian backs it up anyway: Atlassian takes backups "every 24 hours for purposes of application recovery (not for rolling back application data)". Those are for Atlassian's recovery, and you can't restore your own mistakes from them.

Restoring a whole site is the part most runbooks haven't tried. Our Site Import page says "If your Atlassian Cloud site has both Confluence and Jira, site import is not available. To import an entire Confluence site, you'll need to import the spaces one at a time." Plenty of sites have both, and ours does. Backup manager also warns that "Remix content isn't supported in exports for Pages or Live Docs", so if your teams use Live Docs, expect those blocks to come back as errors.

Scripts that call XML export have no documented CSV equivalent

For scripts, the KB's advice is "Switch each to CSV export". That's harder than it sounds, because neither export has a public API.

CONFCLOUD-40457, "Add REST API endpoint for generating space exports", has 459 votes, was opened in January 2016 and is still Gathering Interest. The headless script in our August tutorial drove the web UI's own XML call, a form POST to /wiki/spaces/doexportspace.action with exportType=TYPE_XML, and that's the exact call our browser made this time too. Our CSV button made different calls, internal GraphQL ones with names like useCsvExportTaskMutation. Atlassian doesn't document them, and we didn't try calling them outside the browser. So a script can keep its XML call after December, at its own risk, but there's no documented CSV call to swap in.

Site backups had their own cutoff earlier this year. Atlassian's ticket CLOUD-12817 says "The v1 Backup management APIs will be deprecated on March 30, 2026", and JRACLOUD-68196 says the community backup scripts "are no longer valid" since then. Customers on CLOUD-6498 (2,251 votes) disagree about whether the Confluence one still answers. Its path is /wiki/rest/obm/1.0/runbackup. If that's in your scripts, here's what it did for us:

Our button for the cloud backup called exactly that path, so we called it from a script too, with an API token, the body {"cbAttachments":"false","exportToCloud":"true"} and no browser. It answered HTTP 200. Then it started a cloud backup. You can follow it with the progress call:

curl -s -u "$EMAIL:$TOKEN" "https://<your-site>.atlassian.net/wiki/rest/obm/1.0/getprogress"

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><backupresult fileName="temp/filestore/<id>" size="14684393" currentStatus="COMPLETE" alternativePercentage="100" concurrentBackupInProgress="false" time="1793072727104" isOutdated="false"/>

That's the script-started backup, finished, at 14.7 MB like the one from the button. So on 27 October the Confluence endpoint still worked with an API token. It was never a documented API, though, and Atlassian can turn it off without notice, so treat it as borrowed time.

The supported automated route is now Atlassian Backup and Restore, a paid add-on. For Confluence it covers up to 32 GB and 7 million attachments, keeps backups for 30 days, and Atlassian quotes 12 hours to restore and up to 24 hours of lost data. Atlassian publishes no price, and on Free or Standard you can't buy it at all.

Export a Confluence space to XML (the baseline)

From here on it's the space export, step by step, with what each file held.

[[steps]]

Open the space and go to Space settings: open Space settings for the space, or go straight to the address in the next step.
Pick Export space under General: the address ends in /wiki/spaces//settings/export, and you'll see a File format list with PDF and CSV.
Expand Advanced Options and select XML: XML and HTML sit under it, and XML shows the yellow end-of-life text quoted below.
Click Next: this leaves the new screen for an older page titled Export a zipped XML file.
Keep Export each item, with attachments, and click Export: a progress page counts up until it says Export complete.
Download the zip and list it: you should see one entities.xml with the attachments next to it.

Word for word, the text under the XML radio says: "Support for XML export ends December 1, 2026. You can continue to use this format. After December 1, Atlassian will no longer provide bug fixes or technical support for XML exports. We recommend switching to CSV export."

One thing on the older page confused me. Its default option reads "Export each item, with attachments. Comments are excluded." The form still sent includeComments=true when we clicked Export, and all 3 of our comments were in the zip. So yep, check the zip and ignore the label.

Our XML zip held 7 files:

unzip -l xml-Confluence-export-space-lzxml.zip

Archive:  xml-Confluence-export-space-lzxml.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
      749  10-27-2026 02:28   exportDescriptor.properties
       69  10-27-2026 02:28   attachments/435945498/436109316/2
       69  10-27-2026 02:28   attachments/435945498/436109316/1
       30  10-27-2026 02:28   attachments/435945498/436338698/2
       21  10-27-2026 02:28   attachments/435945498/436338698/1
   751549  10-27-2026 02:28   entities.xml
     1750  10-27-2026 02:28   AO_BAF3AA_AOINLINE_TASK.csv
---------                     -------
   754237                     7 files

Everything lives in entities.xml: 776 objects, including 23 pages, 3 comments, 5 attachments and 447 space permissions. Folders, whiteboards, databases and smart link embeds are all stored as pages, each with a flag such as isFolder. Our whiteboard and database came out as empty shells with no board data.

Export a Confluence space to CSV, step by step

There's no page picker for CSV, so the screen has fewer choices.

[[steps]]

Open Space settings > Export space again: same address as before.
Select CSV: the Content section underneath changes to say what will be included.
Read the Content note: it says "Your exported space will exclude content you don't have permission to view and anything blocked by your data security policy." and "Comments and attachments are included".
Click Export Space and stay on the page: you'll see Exporting files and a Completion percentage. Ours sat at 60% for about two minutes.
Click Download when it says the zip is ready: the message is "Your exported zip file is ready to go!".
List the zip, then unzip it and check one table file: you should see a few dozen files named after database tables, plus an attachments folder.

unzip -l csv-Confluence-export-wolfaenpak.atlassian.net-LZXML.zip | tail -3
unzip -q csv-Confluence-export-wolfaenpak.atlassian.net-LZXML.zip -d csv && cd csv
file content.csv.gz
gunzip -t content.csv.gz

      539  10-27-2026 02:31   whiteboards/data/whiteboardExport_1.csv
---------                     -------
   316802                     55 files
content.csv.gz: CSV text
gunzip: content.csv.gz: not in gzip format

Our CSV zip had 55 files: 48 table files ending in .csv.gz, an exportDescriptor.properties.gz, one whiteboard data file and 5 attachment files. None of those 49 .gz files is actually gzipped this time, so an archive script that tries to decompress them will fail. The site backup further up is different: its .csv.gz files are real gzip. Our August tutorial on turning a space export into a folder tree called the same files gzipped, and these weren't, so check yours before you write a parser.

If you open content.csv you'll see what kind of CSV this is. Its first line is a database header (it starts with contentid and hibernateversion), and pages, folders, attachments and comments sit in that one table as rows. If you were hoping to open it in Excel and read a page, you'll be disappointed. It's really meant for Confluence to import.

Compare the XML and CSV exports, item by item

We seeded one item of each kind, looked for it in both zips, and looked again after importing each zip back into Cloud.

What we created	XML export	CSV export
Page tree, 3 levels	Kept	Kept
Folder with a page and a grandchild in it	Kept, as a page flagged isFolder	Kept, as a FOLDER row
Page with 3 versions and version comments	All 3 kept	All 3 kept
Footer comment with a reply, inline comment	Kept	Kept
Image and text attachment, 2 versions each	Both versions kept	Both versions kept
Labels, content property	Kept	Kept
View and edit restrictions	Kept	Kept
Space permissions	447 rows	447 rows
Space role assignments	Missing	14 kept
Space logo	Listed in entities.xml, file missing	Kept
Whiteboard	Empty shell	Shell plus a whiteboard data file
Database	Empty shell	A content row, no data file
Smart link embed, blog post	Kept	Kept
Unpublished draft, trashed page	Kept	Kept
Users	14 with email addresses	661 account ID mappings, no emails
Time until the Download link appeared	6.8 s (first run about 64 s)	145 s and 184 s
Zip size	26,152 bytes, 7 files	74,254 bytes, 55 files

A note on the odd numbers in there. One person built the space, yet the XML held 14 user records and 447 space permission rows, and the CSV mapped 661 accounts. We didn't work out exactly where they all come from. They're far more than the people who touched the space, so they look like the site's users and groups that the space's permissions reach.

I expected two tickets to bite here. CONFCLOUD-84941 said a CSV export "Produces a flat table of all content with no folder hierarchy information", and it was closed as Fixed on 18 September 2026 with no note about what shipped. In our export the folder was a FOLDER row with its children pointing at it, and it came back as a real folder after import. CONFCLOUD-79269 is a size complaint: both formats include the old attachment versions too, which makes big spaces bigger. That's still true, and it's still Gathering Interest.

I'd tell people about the role assignment gap first. Space roles are Confluence Cloud's newer way of granting space access, and the XML screen warns about them ("The permissions data for users will export, but not role assignments"). Our entities.xml had no role data at all, while the CSV had 14 assignment rows. If your spaces use roles, an XML copy of them is missing who holds which role.

XML carried all 14 users with their emails. CSV only maps account IDs. If someone downstream uses the export to work out who wrote what, CSV gives them an account ID and they'll need the user directory to turn it into a person.

We didn't set up a classification policy, so one difference isn't in our table. Atlassian's Prevent data export doc covers pages blocked by a classification policy. Say a blocked parent page has unblocked children. The children still go into an XML export. For CSV, "both the parent pages and the child pages are omitted when exporting to CSV format." So with a data security policy in place, a CSV export can have fewer pages than an XML one.

Import both files back to check the round trip

We wanted to know the files actually come back, so we deleted the space and imported each zip through Confluence administration > Import spaces.

[[steps]]

Go to Confluence administration > Import spaces: the page is titled Import Confluence spaces and has one file picker, Space export file.
Make sure the space key is free: the importer won't overwrite a space with the same key, so import into a site where the key doesn't exist, or delete or rename the old space first.
Select the zip and click Import: the same picker took both formats, and Confluence worked out which one it was.
Wait for the import, then check the result: open the space and compare its page tree and one page's history with what you exported.

Both came back, which I was glad to see. The XML import task ran for 32.4 seconds after about 2 minutes in the queue, and the CSV one ran for 111.6 seconds. Both restored the page tree, the folder, all 3 versions, the comments, both attachment versions, labels, restrictions, the blog post, the draft and the trashed page, all with new content IDs. After the XML import the space icon was a broken image, because the logo file was never in the zip. I didn't expect that one.

The XML screen also warns that "If you use the XML file format to import to Cloud, content permissions will not be imported." Our restrictions came back after the XML import anyway. We only tested restrictions with one user, ourselves, on the same site, so I wouldn't lean on that result for a real cross-site move.

Our first CSV import failed. I nearly missed it. We tried it while the original space still existed, and the screen sat on "Importing in progress... Unzipping the uploaded file" for 8 minutes (our browser was headless, which may play a part). What actually happened was in Confluence's long-running task list, which you can read with an API token, newest task first:

curl -s -u "$EMAIL:$TOKEN" "https://<your-site>.atlassian.net/wiki/rest/api/longtask" \
  | jq -r '.results[] | select(.name.key | test("ImportCsv|ImportXml")) | "\(.name.key | split(".") | last)  successful=\(.successful)  \(.messages[0].translation)"'

ImportXmlSpaceTaskRunner  successful=true  Space with key LZXML imported successfully.
ImportCsvSpaceTaskRunner  successful=true  Total successful records processed: 2
ImportCsvSpaceTaskRunner  successful=false  A space with key LZXML already exists.

Confluence Cloud to Data Center migration still needs XML

The KB calls it "The one known gap": "Cloud to Data Center migration (e.g. due to a company merger) where the Data Center site restore only accepts XML format. If this applies to you, please contact Atlassian Support to discuss your options." CSV space exports had the same limit at launch in 2023: "you will not be able to import CSV space exports into Confluence Server or Data Center".

You might one day need Cloud content in a Data Center instance, after an acquisition say, or for a regulator. If so, take the XML export now while it's supported. Test the restore, and keep it. Atlassian's own doc for merging two Cloud sites still describes a route that restores a Cloud backup into a Data Center trial and migrates it back out, so that route depends on XML too. For a plain move between Cloud sites, Atlassian now points to copying product data in Atlassian Administration, or a CSV space export and import. Data Center itself goes read-only on 28 March 2029, so this window is limited at both ends. If a Data Center exit is on your table, our migrations team is happy to talk it through.

If it didn't work

An error that Confluence can't find the exportDescriptor.properties file (that's Atlassian's description, we didn't hit it): Atlassian's import doc says a Mac may unzip the CSV export automatically when it downloads. Upload the original zip file again.

The import sits on "Unzipping the uploaded file": check the long-running tasks as shown above. Ours had failed with "A space with key LZXML already exists." The importer won't overwrite an existing space, and that includes personal spaces.

A CSV export has fewer pages than you expected: CSV includes only what the exporting user can view, unless they're a site admin. A data security policy can also leave out a blocked parent and its children. Run the export as a site admin and compare page counts. Our CSV zip has a space_export_counts file (Page 16, BlogPost 1, Comment 3, Attachment 5) that's handy for this.

You need only some pages: CSV has no page picker. Use XML's Select what to export while it's supported, or PDF or HTML if you only need something people can read.

There's no CSV option at all: a 2023 Community thread, "No longer able to export confluence cloud space to CSV", shows people who couldn't find CSV in the list. Atlassian's Prevent data export doc says an organization admin can block space exports with a data security policy, so check that first.

What you have now

You've seen where XML and CSV export live in Confluence Cloud today, what each held for one small space, and both files going back in through Import spaces.

[[takeaways]]

XML export lives under Advanced Options and still works after 1 December 2026, with no fixes or support.
On our space CSV kept all the content XML kept, plus role assignments and the space logo, but no email addresses.
Both zips imported back through Import spaces. Check the long-running task list if an import seems stuck.
In Backup manager, Create backup for cloud gave us CSV and Create backup for server gave us XML. On a site that also has Jira, Site Import is off, so your restore path is space exports, one at a time.
Not covered: backups with attachments, restoring a site backup, multi-user restrictions, populated whiteboards and databases, and any restore into Data Center.

This week I'd follow the KB's own tip: run one final XML export of anything important, run the CSV export of the same space, and restore the CSV into a test space before 1 December. Has anyone already moved a scheduled backup to CSV? I'd love to hear what your scripts ended up calling.

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.

Rovo vs Copilot vs ChatGPT: Cost at 50-500 Seats

Mihai Perdum — Tue, 27 Oct 2026 05:58:41 +0000

A thread on the Atlassian Community starts with an admin whose company had rolled out the Jira Cloud connector for Microsoft 365 Copilot: "Some users can't access/ask about work items that they have access to in Jira via Copilot; they get "this item does not exist" or "I don't have access to this data" responses." I keep coming back to that line when people ask me about Rovo vs Copilot, because it isn't about price at all. What matters is how the assistant gets at your Jira and Confluence data. Each of the three does it differently.

So here's my take, with the money first. If you pay for Jira and Confluence Standard or above, Rovo comes with them and has no seat price. Microsoft 365 Copilot is a per-person add-on at $18 to $30 a month. ChatGPT Business is $20. OpenAI doesn't publish a ChatGPT Enterprise price at all.

Rovo still costs money, though. From 3 December 2026 Atlassian charges $0.01 per credit once your team goes over its pool, and extra usage is on by default. And if you buy ChatGPT and point it at Jira through Atlassian's MCP server, some of those calls draw from the same pool. You can end up paying a seat price and the Rovo meter for the same question.

The prices below come from the vendors' own pages, read on 26 October 2026. The Rovo numbers come from our own test org. We hold no Copilot licence and no ChatGPT Enterprise licence. So nothing here measures how good their answers are. By Copilot I mean Microsoft 365 Copilot throughout. GitHub Copilot, the coding assistant, isn't part of this comparison.

What we found: Rovo stays cheaper until one person uses about 2,150 credits a month

There's a break-even, and it's high. On Jira Standard + Confluence Standard a person has to use about 2,150 Rovo credits a month before Rovo costs as much as a $21 Copilot Business seat. That's about 28 Think deeper runs at our measured average.
Heavy Rovo use gets close to a ChatGPT seat. One Quick answer and one Think deeper run per working day comes to $17.46 a person a month over the Standard pool. ChatGPT Business is $20.
300 seats is the last size Copilot Business covers. Licensing all 300 is $75,600 a year at list. The same 300 people on the $30 add-on would be $108,000.
Copilot costs less inside a bundle. Microsoft 365 Business Premium with Copilot is $32 a user, $10 more than Business Premium alone, while the separate Copilot Business add-on is $21.
ChatGPT's Jira questions can show up on your Rovo meter. At one question per working day and Atlassian's 10 to 25 credits for a typical prompt, that's at most 210 to 525 credits per person a month.
The Rovo meter disagrees with itself. On 26 October at about 09:20 UTC its Usage tab said 447 credits and its Features tab added up to 487, 9% apart on the same screen.
Microsoft's Jira connector treats issue security as optional. Its docs list issue-level security as an optional permission, and the connector doesn't support the "Any user logged in" role.
The cheap Rovo answer can miss a field. On a test project, a 10-credit Quick answer said no open item had a due date, while 12 of 15 had one. The 62-credit Think deeper answer used the dates, and every figure in it checked out. That's one run of each.

Rovo vs Copilot vs ChatGPT Enterprise: cost per seat at 50, 200 and 500 users

All prices are USD list on annual billing unless the row says monthly. Rovo's seat price is $0 on these plans. The Rovo rows are the credits above the pool.

Option	Per seat per month	50 seats, per year	200 seats, per year	500 seats, per year
Rovo, light use over the Jira Std + Confluence Std pool	$1.60	$960	$3,840	$9,600
Rovo, routine use over the Jira Std + Confluence Std pool	$3.11	$1,866	$7,464	$18,660
Rovo, heavy use over the Jira Std + Confluence Std pool	$17.46	$10,476	$41,904	$104,760
Rovo, routine use over the Jira Prem + Confluence Prem pool	$2.21	$1,326	$5,304	$13,260
Rovo, routine use over the Teamwork Collection Std pool	$1.11	$666	$2,664	$6,660
Microsoft 365 Copilot Business, list	$21.00	$12,600	$50,400	not sold above 300
Microsoft 365 Copilot Business, promo, first year	$18.00	$10,800	$43,200	not sold above 300
Microsoft 365 Copilot Business, monthly billing	$25.20	$15,120	$60,480	not sold above 300
Microsoft 365 Copilot add-on (enterprise plans)	$30.00	$18,000	$72,000	$180,000
ChatGPT Business Standard, annual	$20.00	$12,000	$48,000	$120,000
ChatGPT Business Standard, monthly	$25.00	$15,000	$60,000	$150,000
ChatGPT Enterprise	not published	quote	quote	quote

The Copilot and ChatGPT rows are on top of what you already pay Atlassian. Copilot also needs a Microsoft 365 plan underneath it. The Rovo rows use three usage profiles built from our own measured unit costs (a Quick answer is 10 credits, our Think deeper runs averaged 75.5) over a 21-working-day month. Light is one Quick answer per working day, 21 × 10 = 210 credits a person a month. Routine adds two Think deeper runs, 210 + 2 × 75.5 = 361, the profile from our 2027 budget for 50, 200 and 500 seats. Heavy is one Quick answer and one Think deeper run per working day, 21 × 85.5 = 1,795.5, which I've rounded to 1,796. Each row is the profile minus the pool, times $0.01, so routine use on Standard is (361 − 50) × $0.01 = $3.11 a seat a month. They have no cap unless you set a limit.

Run the same sum backwards and you get a break-even. A $21 Copilot Business seat buys 2,100 credits of Rovo overage. Add the 50 in the Standard pool and a person has to use 2,150 credits a month before Rovo costs as much. That's about 28 Think deeper runs at our 75.5 average, or seven runs the size of our biggest 310-credit one. Against ChatGPT Business at $20 the break-even is 2,050 credits, and against the $30 add-on it's 3,050. Our heavy profile stays under all three.

A 300-seat company sits right on the Copilot Business limit. Licensing all 300 is $75,600 a year at the $21 list price, against $72,000 on ChatGPT Business and $11,196 of routine Rovo use. Past 300 users Microsoft points you to its enterprise options. The same 300 people on the $30 add-on would cost $108,000. Price both if you expect to grow.

Copilot and ChatGPT are bought per person, so you don't have to license all 200. Say you buy Copilot for 30 people who live in Outlook and Teams. That's $7,560 a year at the $21 list price, about the same as routine Rovo use for 200 people. Rovo comes with the paid Jira or Confluence seats. The pool is shared.

What Rovo costs when you already pay for Jira and Confluence

Atlassian's Rovo licensing page says it plainly: "If your organization has at least one of these paid Cloud plans, Rovo will be automatically added to eligible sites as part of the rollout, no separate Rovo purchase is required." It covers the Standard plan and up of Jira, Confluence, Jira Service Management, and the Service and Teamwork Collections. Atlassian's one published per-seat price is for Rovo Dev, a separate coding agent at $20 per developer a month. Some comparison sites quote that as Rovo's price. You don't need it for Rovo Search, Chat or agents.

What you get is a monthly credit allowance per paid user, pooled across your whole organization: 25, 70 and 150 credits per user per month on Jira and Confluence Standard, Premium and Enterprise, and 250, 700 and 1,500 on the collections. Atlassian's own example is "A Premium customer with 100 users on both Jira and Confluence receives 7,000 (Jira) + 7,000 (Confluence) = 14,000 Rovo credits/month in their shared pool." Unused credits don't roll over.

Above the pool you pay "$0.01 per credit over your allowance ($10.00 per 1,000 credits)", and Atlassian's usage-based pricing page says billing for most meters starts on 3 December 2026. Extra usage is on "for most organizations" by default. Rovo Search stays free, and so do in-line summaries. If you'd like a ceiling before December, our tutorial on how to set or turn off Rovo extra usage walks through the screens.

On our test org, a few long runs used most of the credits

We exported the Rovo credits usage file from our own test org on 20 October. It covers 39 events from 8 September to 20 October and 1,625 credits in total, 826 in September and 799 in October up to the 20th.

Rovo Chat was 19 of those events and 1,435 of the credits. Eleven events cost exactly 10 credits. The other 8 cost 65, 77, 78, 86, 203, 238, 268 and 310, and together they're 92.3% of the Rovo Chat total. Three of the big ones came within 12 minutes of each other on 11 September. The file has no column for the chat mode or the prompt. So the mode behind the 203-310 runs is unknown. Our Rovo credits per user measurement has the single-action numbers (a Quick answer is 10 credits, our two Think deeper runs were 65 and 86). Our Jira Service Management self-service agent ran 15 times at 10 credits each, Rovo agents ran 4 times at 10 each, and a Teamwork Graph event cost 0.

The live meter on 26 October, read at about 09:20 UTC, said 447 credits used of a 3,850 allowance, 12%. On the same page at the same minute, the Features tab added up to 487 (Rovo Agents 196, Self Service Agent 150, Rovo Chat 141, Teamwork Graph 0) and so did the Users tab. On 23 October, for our per-user tutorial, the lag went the other way and the total was ahead. Atlassian doesn't document either. If you're budgeting from the meter, expect the tabs to disagree. On 26 October they were 40 credits (9%) apart, and on 23 October 24 credits the other way. The meter also showed a 961-credit monthly average at that read. It doesn't say which months it averages, and neither month in our export comes close (826 and 799), so I don't budget from it.

Half an hour later the tabs disagreed again, and this time the Features and Users tabs were the ones behind. The four test questions in the next section spent 92 credits. About two minutes after the last one, at about 09:50 UTC, Allowance used said 539 (14%) and the monthly average had moved to 966. Credits this period, on the same tab, had moved only from 447 to 467. The Features and Users tabs had picked up only 20 of the 92. Only Allowance used kept up, and that's the number I'd watch.

A seat price is the same every month, and a credit pool isn't. Of the 487 credits on our Users tab at the 09:20 read, one of our two users accounted for 383. On a small team one person running long jobs can use most of the pool.

Ten credits missed the due dates, and 62 credits got them right

On 26 October I asked Rovo Chat four questions on our test org, each in a fresh chat, and read the org meter before and after every one. Before I started, the meter sat still for 7 minutes, so nothing else was spending. The three Quick answers cost exactly 10 credits each. The one Think deeper question cost 62.

Two of the Quick answers were right. Asked about open work in our LZPT test project, Rovo said 81 items open and 4 in progress, and Jira's own search returned the same counts. Asked which Confluence pages mention incidents, it found the one page there is, though the link it gave pointed at a placeholder your-site address instead of our site.

The third one's why this section exists. I asked what's still open in a test project called Mobile card payments (MPAY) and which work item is due first. The Quick answer counted the 15 open items correctly, then said none of them had a due date set. In Jira, 12 of the 15 have one. Only the three epics don't, and the earliest due is MPAY-9, on 29 September.

Then I asked Think deeper to compare MPAY with a second test project, MALR, and tell me which one looks further behind. It took 80 seconds and 12 steps, and it used the dates the Quick answer said weren't there: 7 overdue items in each project, 120 overdue days added together on MPAY against 97 on MALR, and MPAY-9 the most overdue at 27 days. I checked every figure in its table against Jira by hand, and each one held.

That's one run of each, so I wouldn't call it a pattern. It does show you the trade inside the pool, though. If your question depends on dates, the 10-credit answer may skip the field, and the answer that reads it can cost about six times as much.

These runs also check the numbers behind our table. Quick answers held at 10 credits, the same as on 14 and 15 October. Today's Think deeper run cost 62, under the 75.5 average from our two October runs (65 and 86), so if anything the table overstates what Rovo costs you. At 62 the routine profile would be 334 credits, or $2.84 a seat a month over the Standard pool instead of $3.11. I've kept 75.5, because it's the figure our 2027 budget used and one more run doesn't make a new average.

Microsoft 365 Copilot pricing: Business at 50 and 200 seats, the $30 add-on at 500

Microsoft sells two versions on its pricing pages on 26 October 2026. Microsoft 365 Copilot Business is "Originally starting from $21.00 now starting from $18.00" per user per month paid yearly, or $25.20 on a monthly subscription. The footnote matters for anyone budgeting 2027: "This discount offer is available between July 1, 2026, and December 31, 2026. ... An annual commitment is required, and promotional pricing applies to the first year only." Sign in December and your second year is $21.

Business has a ceiling. Microsoft Learn says it "supports up to 300 licensed users per tenant. Organizations with more than 300 users should use Microsoft Copilot licensing options designed for enterprise environments." For a 500-seat company that's the Microsoft 365 Copilot add-on at "$30.00 user/month, paid yearly", and "A separate license for a qualifying Microsoft 365 plan is required." The enterprise page shows only that yearly price. Its Pay monthly button goes straight to sign-up, so there's no separate monthly price to compare.

A few other things are on the same pages. Copilot is included in Microsoft 365 E7, which lists at $99 per user per month. Copilot Chat comes at no extra cost with an eligible Microsoft 365 plan, but Microsoft's own FAQ says it "doesn't integrate with Microsoft 365 apps or organizational content such as files, emails, or chats." Agents built in Copilot Studio are billed on Copilot Credits ($200 a month for a pack of 25,000). They're "No charge" when a licensed Copilot user runs an employee-facing agent under their own identity, but Microsoft's billing rates page says agent flows with other triggers and computer-using agents still spend credits.

The bundles cost less than the add-on plus the base plan. Business Premium is $22 and the Copilot Business add-on is $21, yet "Microsoft 365 Business Premium with Copilot" shows $32. Business Standard with Copilot is $23.50 against $14 plus $21. The page's footnote only says "Offers and discounts may vary between Microsoft 365 plans with Copilot and add-ons." Bought as a bundle, Copilot adds $10 a user on Business Premium and $9.50 on Business Standard, which is $24,000 and $22,800 a year at 200 seats (our arithmetic). On one of those plans? Get the bundle quoted next to the $21 in the table.

Copilot vs ChatGPT Enterprise: the per-user price OpenAI does not publish

OpenAI publishes ChatGPT Business at $20 per user per month billed annually or $25 monthly for a Standard seat, and $100 or $125 for a Premium seat. Its billing help page adds a "2 seat minimum per workspace", and whoever owns the licences should know that "you are charged for all standard and premium seats in your workspace, whether or not they've been assigned".

Set against Copilot, the two published prices are close. ChatGPT Business is $20 a seat and needs no other licence. Copilot Business is $21 ($18 on the promo) on top of a Microsoft 365 plan of $7 to $22, up to 300 users, and above that it's $30 on top of an enterprise plan such as E3 at $39. Counting the base plan, a Copilot seat is $28 to $43 a month on Business and $69 on E3. That's if you don't already pay for the plan.

ChatGPT Enterprise has no public price. The pricing page says "Contact our sales team to discuss enterprise pricing" and "Credit-based and token-based pricing are available for Enterprise plans." The help centre says Enterprise workspaces "purchase a shared credit pool at the contract level" with "no per-seat usage caps by default", and once the pool runs out "advanced features will be paused unless Workspace Owners enable overages". It's the same idea as Rovo's pool, sold on a contract.

What about the actual number? One comparison site, Coworker AI, reports $45 to $75 per seat, about $60 typical, and a minimum of around 150 seats. It also says the widely quoted $60 traces back to a single 2023 Reddit anecdote. I couldn't confirm any of it on an OpenAI page, so it isn't in the table. If ChatGPT Enterprise is on your list, the quote is the number, and the Business price is the floor you can compare it with.

Copilot Jira connector vs ChatGPT's Atlassian connector: what each can read

Rovo reads Jira and Confluence with your own permissions

Rovo sits inside Atlassian. The admin overview on our org says "Rovo respects existing permissions. Users and agents can only access data and take actions that their permissions allow." Atlassian's trust page says "Rovo honors all existing permissions within each feature." There's no index to configure for Jira and Confluence themselves. Those are Atlassian's statements. We haven't tested Rovo against issue security levels on our org, so give it the same restricted-ticket test you'd give Copilot.

Rovo can also pull other tools in. Our connector catalogue listed 39 connectors in 7 groups. Six of them are Microsoft: Entra, SharePoint and OneDrive, Outlook Calendar, Outlook Mail, Teams and Azure DevOps. Atlassian's page says indexed data "stays within Atlassian's infrastructure, and is never processed by external AI models", and that storing indexed objects doesn't use Rovo credits. There's no ChatGPT, OpenAI or Copilot connector in that list. We tested the SharePoint one in our Rovo SharePoint connector piece.

Copilot reads an index Microsoft builds from Jira and Confluence

Microsoft 365 Copilot uses Microsoft's own connectors. The Jira one "supports Jira Cloud-hosted instances only. Jira Server and Jira Data Center versions aren't supported." It indexes "Title, Issue description, Issue status, Project name, Created and updated dates, Assignee name, Priority", and custom fields can be added. You choose who sees the results: "Everyone", or "Only people with access to this data source: Indexed data appears only for users who have access in Jira." It needs Browse projects, while issue-level security is listed as optional, and "The connector doesn't support the Any user logged in application role for granting issue access."

The Confluence connector "honors Confluence's space permissions and page restrictions" and indexes attachments. It leaves out page history, archived pages, drafts and content from third-party Confluence apps. Watch the timing, though: "Permission changes are picked up only during a full crawl (once every 24 hours by default), not during the 15-minute incremental syncs."

The Jira connector has the same lag. Microsoft's deployment guide says "Updates to groups that govern access permissions are synced in full crawls only. Incremental crawls don't support the processing of updates to permissions", and the full crawl runs daily. A reply in the Community thread from the top blamed that lag. The admin answered that it wasn't sync lag: the connector didn't seem to read the permissions in the first place. The thread ends there. No fix. I wouldn't assume issue security levels are honoured until you've tested a restricted ticket and a permission change yourself.

Indexing costs nothing extra on Microsoft 365, per the connector prerequisites. Grounding Copilot answers in connector data needs Copilot licences, though. Without them the content shows up in Microsoft Search only. On writing back, a Microsoft Q&A answer says "write permissions are not supported by the connector."

ChatGPT goes live through the Atlassian MCP server (the Rovo MCP server), and spends your credits

ChatGPT reaches Jira and Confluence through Atlassian's MCP server. Atlassian's support docs now call it the Atlassian MCP server, its launch post called it the Atlassian Rovo MCP Server, and OpenAI lists it as the Atlassian Rovo app. OpenAI's Company Knowledge page says "Company Knowledge respects permissions in the connected source. A member can retrieve only information they are already allowed to access through the app connection." OpenAI's admin page says administrator-managed sync is no longer available, so the Atlassian app works as a live connection through Atlassian's MCP server, which Atlassian's launch post says "uses OAuth authentication and respects all existing permission controls".

I didn't expect this bit: some of those ChatGPT calls come out of your Rovo credits. Atlassian says "Installing and connecting to Rovo MCP Server and Teamwork Graph (TWG) CLI are free. However, enriched API calls into TWG ... consume Rovo credits when they externalize Teamwork Graph context to an agentic, CLI, MCP, API, or other 3P product path." Most are "1-10 Rovo credits per call", and "Typical prompts consume 10-25 Rovo credits total." A Community member who tested it with Claude found that "Just opening a ticket, or searching for tickets — this did not cost any credits", while Teamwork Graph calls cost 0 or 7-10.

To put a number on it, assume each ChatGPT user asks one Jira or Confluence question per working day. Assume each prompt costs Atlassian's typical 10 to 25 credits. That's 21 × 10 = 210 to 21 × 25 = 525 credits per person a month. Say routine Rovo use has already spent the Standard pool. Then 200 ChatGPT users would add $5,040 to $12,600 a year to the Atlassian bill (210 to 525 × $0.01 × 200 × 12). That's an assumption, and an upper bound. Plain ticket opens and searches cost nothing in that Community test.

One Community thread says "Until December 16, 2025, this worked without any configuration" and that the connector "does not provide live access to Jira data from this ChatGPT integration, despite being listed as connected." Another says the links it returns point at api.atlassian.com, and clicking them shows "Issue does not exist or you do not have permission to see it." Atlassian also keeps a support article for write actions failing through the ChatGPT Rovo connector.

There's a reverse route too. Since 26 August 2026 Rovo has been "available as an agent in Microsoft 365 Copilot and Teams". That page names no price. But Atlassian's licensing page says a Rovo Chat question from Teams costs the same credits as one in Jira.

On training data the three are close but not identical. Atlassian's LLM partners "operate under strict zero data retention (ZDR) agreements", but Atlassian itself may use de-identified metadata to fine-tune open-source models in its own infrastructure, subject to your data contribution settings. Microsoft says prompts and responses "aren't used to train foundation models", and OpenAI says "We do not train our models on your data by default".

Assumptions, and which AI assistant to buy at each seat band

Prices are USD list prices read on the vendors' pages on 26 October 2026, on annual billing unless a row says monthly. No discounts, no reseller margins, no tax.
You already pay for Jira Standard + Confluence Standard (or Premium where the row says so). Jira + Confluence Standard on Atlassian's annual tables is $8,450, $30,500 and $64,500 a year at 50, 200 and 500 seats, and it's left out of the table because you need it whichever assistant you pick.
Rovo pool: 25 + 25 credits per person per month on Jira Standard + Confluence Standard, 70 + 70 on Premium, 250 on Teamwork Collection Standard. If you pay for only one of Jira or Confluence, the Standard pool is 25, and routine use costs (361 − 25) × $0.01 = $3.36 a seat a month. Overage $0.01 per credit from 3 December 2026.
Rovo use, over a 21-working-day month: light is 210 credits per person (one Quick answer per working day at 10 credits), routine is 361 (plus two Think deeper runs at our measured mean of 75.5), heavy is 1,796 (one Quick answer and one Think deeper run per working day). Overage is the profile minus the pool, times $0.01, times seats, times 12.
Copilot needs a qualifying Microsoft 365 plan you already pay for (Business Basic $7, Business Standard $14, Business Premium $22, or an enterprise plan such as E3 at $39). That base isn't in the table.
Copilot Business is capped at 300 users per tenant, so 500 seats use the $30 add-on.
ChatGPT Business needs no other licence. It bills for the seats you bought, assigned or not. ChatGPT Enterprise is priced by OpenAI's sales team, so there's no figure.
ChatGPT questions through Atlassian's MCP server aren't in the table. Our estimate above (210 to 525 credits per person a month) assumes one question per working day at 10 to 25 credits.
Everyone at the company gets a licence. In real life you'd probably buy Copilot or ChatGPT for a subset.

What I'd buy depends on where your people spend their working day.

50 to 200 seats, mostly working in Jira and Confluence. Start with Rovo, because you already have it. Set an extra-usage limit before 3 December. Then watch the meter for a month. Look at who's running the long jobs, since one heavy user can spend more than everyone else together. Copilot for everyone would cost $12,600 to $50,400 a year at list, for answers about content Rovo can already read.

50 to 200 seats, living in Outlook and Teams. Buy Copilot Business for the people who write documents and mail all day, and maybe not for the rest. If you're buying it anyway, sign before 31 December 2026 for the $18 first-year price and budget $21 for year two. Test the Jira connector with a restricted ticket and a permission change before you promise anyone it sees what Jira shows them.

500 seats. Copilot for everyone is $180,000 a year at $30, against about $18,660 of routine Rovo overage on Standard or $13,260 on Premium in our model. That gap isn't like for like, because a Copilot seat also covers Microsoft 365 apps such as Outlook and Word. I'd keep Rovo as the assistant for Jira and Confluence and license Copilot by role. On Premium at this size, the Teamwork Collection maths in our budget article is worth redoing too.

Your people already use ChatGPT. ChatGPT Business at $20 is the published price. For Enterprise, ask the sales team for the credit-pool terms in writing, and set a Rovo limit for the MCP calls.

We only pay for Rovo, so answer quality is the part we haven't measured. I'd love to hear from the other side. If your company already pays for Microsoft 365 Copilot or ChatGPT Enterprise, did anyone point it at Jira, and did it find the tickets Rovo finds? Tell me in the comments under this post. And if you've got a ChatGPT Enterprise quote you're allowed to share as a range, I'll add it to the table.

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.

Jira new create screen: turn off Simple create as default

Mihai Perdum — Mon, 26 Oct 2026 11:59:03 +0000

To turn off Jira Cloud's new create screen for everyone, a Jira admin opens Settings > System > General configuration, clicks Edit Settings, and sets Simple create as default to OFF in the Options section. If you aren't an admin, there's a per-user version too: expand the window to the full form, open the ••• menu and switch on Always open in this view.

Atlassian calls the new window Simple create in the setting, Quick Create in its support doc and the streamlined Create experience in its staff announcement from 2 July 2026. I'll call it the compact window here, and the expanded version the full form. A lot of the 109 comments under that announcement ask how to get the old form back, and one Community question asks whether you can disable it at the admin level. Yep, you can.

We flipped the switch on our own test site on 25 October 2026 and then tried to make Jira open the full form by itself. Our test account uses the dark theme, so that's what the screenshots show.

[!NOTE]
Prerequisites: Jira Cloud, and the Jira admin permission for the site-wide switch. The per-user toggle needs no admin rights (Atlassian's article says "No admin action needed."). The staff article says the new window doesn't apply yet to Jira Service Management or Jira Product Discovery, and we didn't test either. No source mentions a plan restriction, but we only tested on one Premium site.

Before you flip it

It's site-wide. There's no per-space version, and it's the only admin control we found. So as far as we found, an admin can't turn it off for one person either (each person can, see below). It's easy to undo, though. Turning it back ON is the same page and the same Update button. We did exactly that when we finished.

With the switch OFF, the dialog we got had no Show more toggle. We didn't find a way back to the compact window for a single user (we didn't open that dialog's ••• menu). As far as we saw, everyone gets the old Create dialog.

You should also know where our testing stops. We only used a company-managed space, so I can't tell you how team-managed spaces behave. We pressed c on a board each time, and the staff article says inline create on a board, the timeline and the roadmap opens the new window when required fields need filling in, and so does creating child work items. I don't know which form those use with the switch OFF. We didn't check whether people who already have Jira open need to refresh. And none of the three Atlassian pages we read says whether this switch is here to stay.

Turn off "Simple create as default" in Jira's General configuration

[[steps]]

Open Jira admin settings: click the cog and pick Jira admin settings. The admin settings open.
Go to System > General configuration: the URL ends in /jira/settings/system/general-configuration, and the page lists Simple create as default as on. Atlassian's staff article and support doc call it General Configurations, plural, but the menu and the release note say General configuration. (The old /secure/admin/ViewApplicationProperties.jspa address redirects here.)
Click Edit Settings: the address changes to /secure/admin/EditApplicationProperties!default.jspa, a long form with radio buttons.
Scroll to Options and pick OFF next to Simple create as default: it's the first row of the Options block, with the help text quoted below.
Click Update, then open General configuration again: you should see Simple create as default listed as off.
Check it on a board: press c. You should see the old Create dialog, with a title like Create Story and Space and Work type dropdowns at the top.

Jira's own help text under the radio buttons lists the rules. Verbatim from the page:

Simple create as default   ON   OFF
Show a compact create window by default. Users can expand to the full form
when they need to enter more details. Work items with more complex create
requirements, such as multiple required fields, tabs, or customized create
screens, will open in the full form automatically.

Two more rows in the same block change what the create window shows. Status ("Allow users to select a status for a work item they're creating.") and Hide unused fields are both ON on our site. We didn't change either.

If you were hoping to script this across a lot of sites, I couldn't find a way. I pulled the application properties on our site and searched the key names:

curl -s -u "$EMAIL:$API_TOKEN" https://your-site.atlassian.net/rest/api/3/application-properties > props.json
jq length props.json
jq -r '.[].id' props.json | grep -iE 'create|simple|modal|gic'

This is what it printed on 26 October 2026:

66
jira.global.configuration.contexts.created

You should see the count and no key about simple create. That one match only has "created" in its name. But the list isn't complete. Voting, from the same Options block, isn't in it either, yet ?key=jira.option.voting reads fine. So all this shows is that the list doesn't name the setting. We tried a few likely keys by name and got 404s, and we didn't find a way to script it.

What you get with the switch OFF

I pressed c on a board in our test space (ZZSC, a company-managed space we made for this and deleted afterwards), and this came up.

The strings, if you're checking that you got the old one:

Create Story
Required fields are marked with an asterisk *
Space *          ZZSC Simple Create test (ZZSC)
Work type *      Story
Status           Backlog   This is the initial status upon creation
Classification level
Summary *
Description
Cancel   Create

There was a bug about exactly this setting. JRACLOUD-99633, "Setting Simple create as default to Off results in double load of Create screen", was closed as Fixed on 22 October 2026. We tried it three times with the switch OFF, three days after the fix, and only ever got the old dialog, with no trace of the new window loading first. With the switch back ON, the same check caught the new window in all three tries. So the check itself worked.

Can you disable the new issue creation form for one user? Always open in this view

Not from the admin side, as far as we found. The only admin control is the site-wide switch. But each user can make the full form their own default. It's a toggle in the full form's menu, so you have to expand the window first. These are also the steps to send to people who aren't admins.

[[steps]]

Open the create window: click Create, or press c on a board. You get the compact window, with the summary at the top and a row of chips under it.
Click the two-arrow icon: it's the middle of the three icons at the top right, and its tooltip says Show more. The window grows into the full form and the tooltip changes to Show less.
Open the ••• menu: its tooltip says More options (Atlassian's article calls it More actions). A menu opens with Configure fields, Find your field, Hide unused fields and Always open in this view. There's no ••• button in the compact window. You need step 2 first.
Switch on Always open in this view: the toggle should turn on (we didn't flip it on our account, more on that below).
Check that it stuck: close the window and press c again. You should see the full form straight away.

Look at the header line. The full form keeps Space and Work type there, as ZZSC | Story above. Atlassian's support doc describes the same header, "represented by the space icon, space key, and work type name". Both are buttons in that header (we didn't click them to see what they offer). In the old Create dialog they're labelled dropdowns, so if your team wants those back, that takes the site switch.

I didn't flip the toggle on our test account, so I haven't checked that it sticks. Mark Baird reported in the staff thread that clicking it just closed the menu and the toggle never switched on. Atlassian's reply was that they had "identified the cause and shipped a fix. The toggle should now save your preference and hold it across sessions."

When Jira opens the full create form on its own

Even with Simple create as default ON, some work items skip the compact window. Atlassian's staff article lists "tabs, more than three required fields, custom create screens (CMP spaces), Forge UI app modifications, or a complex field type such as rich text." CMP means company-managed. The support doc says the compact window "always shows Title, Description, and up to three required fields", with the required ones as chips under the description.

We tried them one change at a time, on the Story work type in our ZZSC space. Full means the window opened without the Show more toggle and listed every field.

What we changed	Which form opened
Nothing (baseline)	Compact
A custom screen mapped to the Create operation	Full
Same, with the Create mapping removed again	Compact
A second tab on the default screen	Full, with both tabs in the dialog
Due date required (1 required field)	Compact
Due date and Labels required (2)	Compact
Due date, Labels and Components required (3)	Compact, with 3 Required chips
Plus Fix versions required (4)	Full
One required single-line text custom field	Full
Two required single-line text custom fields	Full
The same text fields, optional	Compact
An optional Paragraph (rich text) custom field	Compact
The same Paragraph field, required	Full
A Forge UI modification	Not tested (needs a Forge app with a UI modifications module)

A custom create screen opens the full form (company-managed spaces only)

Mapping our own screen to the Create operation in the screen scheme opened the full form every time. Removing that mapping brought the compact window back. It has to be the Create operation specifically: Kanad from Atlassian told Rune Rasmussen in the staff thread that if your custom screens are only assigned to Edit or View, and Create still points at the default screen, you'll get the streamlined view. Team-managed spaces don't have screen schemes, so the article says CMP. If you're not sure which kind of space you're in, our post on sub-tasks under an epic in company-managed vs team-managed spaces shows how to tell.

A second tab on the create screen opens the full form

Adding a second tab, ZZSC Tab 2, to the default screen opened the full form, and the dialog showed both tabs (Field Tab and ZZSC Tab 2) across the top. If your create screen already has tabs, your users won't see the compact window for that work type.

Three required fields stay compact, a fourth opens the full form

With system fields this matched the docs. Up to three required fields kept the compact window, and making Fix versions required as a fourth opened the full form. We used Fix versions because Jira wouldn't let us make Assignee required at all.

One required text field was enough, once

A single required single-line text custom field, ZZSC Req 1, opened the full form, well under the three-field limit. Two of them did the same, and with both made optional again we got the compact window back. No doc I read mentions this. I ran it once, on one site and one work type, so I don't know yet if it's a rule about custom text fields or a bug.

A required rich text field opens the full form

A Paragraph custom field that renders as rich text was fine while optional. Making it required opened the full form. Description is rich text too, and it's always in the compact window, so the trigger seems to be a required rich text field.

Known bugs and open requests for the new create screen, with JRACLOUD keys

Statuses as of 26 October 2026, read from jira.atlassian.com. The first four come up around the setting itself, and two of them aren't bugs.

Ticket	What it says	Type	Status	Votes
JRACLOUD-99633	Simple create as default Off double-loads the create screen	Bug	Closed, Fixed 22 Oct 2026	1
JRACLOUD-99920	Version picker misses exact matches past 50 versions	Bug	Needs Triage	0
JRACLOUD-99873	Simple create should respect the screen's field order	Suggestion	Gathering Interest	1
JRACLOUD-99926	Allow the Reporter field in the Quick Create modal	Suggestion	Gathering Interest	1
JRACLOUD-99522	Enter key doesn't insert line breaks in Paragraph fields	Bug	In Progress	0
JRACLOUD-99460	No formatting toolbar on rich text fields	Suggestion	Gathering Interest	8
JRACLOUD-99003	Field descriptions are missing from the new Create Screen	Suggestion	Gathering Interest	5
JRACLOUD-99230	Show custom field descriptions	Suggestion	Gathering Interest	5
JRACLOUD-99264	Restore visible field borders in the new create experience	Suggestion	Gathering Interest	3
JRACLOUD-99171	Create from Video is missing	Bug	Gathering Impact	1

JRACLOUD-99920 is the one open bug of the first four. Its workaround is to "Disable Simple create as default to use the classic create screen, which correctly retrieves all pages of search results." JRACLOUD-99873 says the same switch "restores the correct field order". For the Reporter, JRACLOUD-99926 points you to the expand icon and then the ••• menu > Always open in this view, the per-user toggle from above.

Two older ones are already closed. JRACLOUD-99349 (a linked item field cleared between Jira and Jira Service Management) was fixed on 23 September, and JRACLOUD-98974 (the error "Field 'customfield_xxxx' cannot be set. It is not on the appropriate screen, or unknown.") on 5 August.

Summary is back, and the rollout dates don't agree

Atlassian renamed Summary to Title for a while and then posted "We're rolling Summary back". Our site shows Summary, while the support doc, last modified 25 September 2026, still says Title.

Even the dates don't agree. The release note says the rollout started in April 2026, the staff article says mid-July, and Julia Foden wrote in the thread that "it has actually been rolling out since at least May".

If you're cleaning up create-screen complaints anyway, the select field None tutorial covers a related one: a default value that hides None. And the Jira reports retirement is another Jira Cloud change from the same months.

If it didn't work

You can't find General Configurations. It's General configuration, singular, under System in Jira admin settings. You need the Jira admin permission to see it.

There's no Options section. The view page only lists the values. You'll find the radio buttons on the Edit Settings page.

You can't see the Create button. Press c on a board instead. It opens the same window.

The full form opens even with the switch ON. Go through the table above. Check what's mapped to the Create operation in the space's screen scheme, whether the create screen has tabs, how many fields are required for that work type, and whether any of them is a custom text or rich text field.

Always open in this view won't stay on. Atlassian said in the staff thread that they shipped a fix for this. If it still happens, send support the link to their reply to Mark Baird in the announcement thread.

What you have now

[[takeaways]]

The site-wide switch: General configuration > Edit Settings > Options > Simple create as default > OFF > Update, and the old Create dialog with Space and Work type dropdowns on your boards.
The per-user option, the ••• menu > Always open in this view, for people who want the full form without changing the site.
A tested list of what forces the full form: a custom Create screen, tabs, a 4th required field, a required rich text field, and (once, on our site) a single required text custom field.
The ticket keys with their real statuses, so you know which ones are bugs and which are suggestions to vote on.

Did your team switch the site back, or did people get used to the compact window after a couple of weeks? And if you've seen the one-text-field thing too (or the opposite), tell me in the comments or mail gabriela at leanzero.net :)

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.

Rovo SharePoint Connector: Permissions, Sites and Consent

Mihai Perdum — Mon, 26 Oct 2026 08:59:47 +0000

Yes, Rovo can access SharePoint. The Rovo SharePoint connector copies SharePoint and OneDrive files into the Teamwork Graph, the index Atlassian keeps for search and AI, and Rovo answers from there. A Microsoft 365 admin has until 15 November 2026 to consent to Atlassian's new app, and one of the two permission requests the setup sends Microsoft names no permissions at all, only .default.

I think the design is fine. The problem is the setup page never shows you the permission list you're approving. Microsoft's consent screen shows it once, to whoever clicks Accept, and Entra shows it after the fact.

I walked the setup on our test org this week, right up to Microsoft's sign-in page, and recorded where each button sends you. We don't have a real Microsoft tenant, so nothing got connected. Anything past the sign-in page comes from documentation, and I say so where it counts.

My recommendation for a 50 to 2,000 seat company: grant the admin consent now, because that's the one with the deadline. For the Authorize step, do it first in a pilot or test Microsoft tenant and read the granted list in Entra. Without one, have the approving admin screenshot Microsoft's consent screen and click Cancel, then decide for production. When you do switch indexing on, use an allow list of sites, never a block list.

What we found

Two Microsoft apps, two requests. Grant consent asks for six named, read-only scopes. Authorize goes to a different app and asks for .default. Its list isn't on the setup page or in any Atlassian doc we read; you see it on Microsoft's consent screen and, afterwards, in Entra.
The deadline is for the first app only. Atlassian says you don't need to finish the connector setup to grant it.
Allow and block lists cap at 50 entries each and can't target individual files or folders.
The docs and the tracker disagree twice, on SharePoint pages and on whether agents read file contents.

Connect SharePoint to Rovo: two apps, up to three admins

I found the connector under Atlassian Administration > Connectors > All connectors. Rovo needs a Standard plan or higher, and Atlassian Government organizations don't get it.

The setup talks to two Microsoft apps. I'll call them the consent app and the indexing app from here on.

	Consent app	Indexing app
Button in the wizard	Grant consent	Authorize
Entra app (client ID)	0c8611af-925f-491b-86f4-32fad2901689, named "Atlassian"	20ddde29-f84a-4a98-a8c2-b3b698d4ace2
Microsoft endpoint	/organizations/v2.0/adminconsent	/organizations/oauth2/v2.0/authorize
Scopes in the URL	email, openid, Files.Read.All, Sites.Read.All, User.Read, offline_access	https://graph.microsoft.com/.default, offline_access
Who approves	Entra Global Administrator, Application Administrator or Cloud Application Administrator	"SharePoint global admin" per Atlassian's connect page
What Atlassian documents	Each scope, read-only	"the permissions here are broad"

That's what the browser sent on 25 October 2026. No consent was granted and we saved nothing. The page creates an unsaved draft when it loads, and the connector list still showed 0 items afterwards.

So up to three admins sign something: the Atlassian organization admin who runs the wizard, the Entra admin who grants consent, and whoever authorizes indexing. Then each user connects their own Microsoft account once.

The wizard asks that last admin for "Microsoft Entra admin permissions". Connect SharePoint to Teamwork Graph, which I'll call the connect page, says "SharePoint global admin permissions". Plan for whoever holds both.

Read the terms under the Authorize button. You "allow Atlassian to access or ingest sensitive data". You also agree "that Atlassian may share data from the third-party product with MCP clients or apps that users connect to Teamwork Graph".

That second term reaches MCP clients and other connected apps as well as Rovo. I'd flag it separately. If you've already locked MCP down with Atlassian Guard, our piece on what the Atlassian data security policy covers lists the "Prevent Atlassian MCP server access" control.

Admin consent for the SharePoint and OneDrive connection is due 15 November 2026

Upgrade your SharePoint and OneDrive connection names the app: "a Microsoft 365 administrator must grant consent to Atlassian's new Microsoft publisher-verified application by November 15, 2026", application ID 0c8611af. Without it, "users may no longer be able to resolve SharePoint and OneDrive Smart Links, display link previews, or find SharePoint and OneDrive content through Rovo."

You can do that without switching indexing on. Same page: "You don't need to complete the connector setup or add the connector. Opening the setup page is only necessary to obtain the admin consent URL." Indexing only happens "If your organization separately configures a synced Teamwork Graph connector for Rovo".

So I'd split the two decisions. The consent app's scopes are documented and read-only. Sites.Read.All is "Read items in SharePoint sites that the signed-in user can access", and "If a user cannot access it in Microsoft, granting consent does not give them access through Atlassian." Revoking it later "will disable SharePoint and OneDrive features in Atlassian for all users in your organization".

The indexing app asks for .default, and the list behind it is in Entra

Authorize is the step that switches indexing on. The connect page calls it "granting Atlassian Teamwork Graph access to your SharePoint/OneDrive accounts" and adds: "Although the permissions here are broad, Atlassian Teamwork Graph will only ingest assets that comply with the admin policy controls".

Microsoft's scopes page says .default "signals that consent should be prompted for all required permissions listed in the application registration". So the request carries no list. The list is whatever permissions Atlassian set on its own app in Microsoft's directory.

Microsoft shows that consent screen when nothing has been granted yet, or when the request forces it. That screen is where the list appears, once, for the admin who approves it. If someone in your tenant already clicked through, you probably won't see it again. After consent, Entra shows the same list: Enterprise applications > the app > Permissions, with delegated and application grants kept apart.

That split is what to look for. Delegated permissions act as the signed-in user, so they can't reach anything that person can't open. Application permissions run with no signed-in user at all. Microsoft's reference says Sites.Read.All as an application permission "Allows the app to read documents and list items in all site collections without a signed in user".

What we captured is a sign-in request with offline_access. In Microsoft's model that gets a token acting for the admin who signs in, which fits Atlassian's line that synced connectors index "using a service or admin account". Nothing we saw rules out the same app registration also holding application permissions used another way. Only the consent screen or the Permissions list in Entra would show that.

The old setup asked for more, and you built it yourself

Until spring 2026 you created the Entra app. The archived connect page (12 March 2026) said "Select Application permissions" and listed eight Graph ones, from Directory.Read.All and Sites.Read.All to AuditLogsQuery-SharePoint.Read.All, plus ActivityFeed.Read and a tenant-scoped SharePoint read.

That list was read-only, which isn't greedy by comparison. Glean's SharePoint connector asks for Sites.FullControl.All in its standard setup, and "All permissions must be granted as Application permissions." Glean does document Microsoft's Sites.Selected, which limits an app to chosen site collections, as an alternative it doesn't recommend, and Google documents it too. No Atlassian page we read mentions it. I'd ask Atlassian before assuming either way.

It ran on Azure Access Control Service (ACS), Microsoft's old SharePoint add-in authentication, retired for existing tenants on 2 April 2026. Atlassian announced the move to "an Atlassian-managed Microsoft Entra app" on 31 March. Connectors left on legacy auth "may stop syncing", leaving Rovo "reasoning over stale data".

Synced means Atlassian keeps a copy of your SharePoint

If I were the CISO, I'd read this part first. SharePoint is a synced connector, and Atlassian's privacy page says those store "the content for each file" and "permissions settings about the file". Your content sits in the Teamwork Graph, and the permission check runs against Atlassian's synced copy of your SharePoint permissions.

Microsoft 365 Copilot works differently. Its data is "processed and stored in alignment with contractual commitments with your organization's other content in Microsoft 365". This connector moves a copy out of Microsoft 365 into Atlassian, which you can at least pin with Atlassian's data residency.

Per the connect page it copies Word (.doc, .docx), Excel (.xls, .xlsx), PowerPoint (.ppt, .pptx), PDFs up to 10 MB, and web pages (.html, .aspx). It stores each file's body along with its name, URL, dates, creator and collaborators. "Encrypted documents do not get ingested." SharePoint lists aren't mentioned, and neither is what happens to a 12 MB PDF.

People come along too. The People data tab always indexes display name and email address. A toggle, on by default, adds job title, manager and department. The doc's own list has hire date and no manager, so check the screen you actually get.

OneDrive arrives through Include personal sites. One Atlassian page says it comes "automatically"; the setup screen says "OneDrive is off by default", and the toggle was off. Trust the screen.

What happens when a file's access changes

Atlassian's permission-sync page covers changes to a document, not to a person. Restrict a file at the source and it "Only shows up in search results for those with permissions". Remove the restriction and it's "Visible in Search for everyone using Rovo on your site". Delete it and it's "Removed from Rovo, including Search, Chat, and Agents".

It has no row for someone who leaves or is taken out of a SharePoint group. How long a change takes to land isn't on any Atlassian page we read either.

So I'd treat the connector as exactly as tight as your SharePoint sharing. The setup page puts it this way: "Permissions are always respected. We encourage you to review your permissions in Microsoft SharePoint and OneDrive before connecting. Content that has not been restricted will appear in search results for all users." A site the whole company can open in SharePoint is just as open in Rovo.

Limit the Rovo SharePoint connector with an allow list

In the Choose content modal, Include SharePoint sites starts on and Include personal sites starts off. "At least one must be on. If both are off, nothing is indexed."

Control	What it does	Limits
Allow SharePoint sites	Only listed sites are indexed	Up to 50 URLs; URLs aren't checked
Block SharePoint sites	Everything except listed sites is indexed	Up to 50 URLs; a blocked URL wins over the allow list
Limit by date	Only content created or modified after a date	One date for the whole connector
Limit by labels	Blocks files with listed sensitivity label GUIDs	GUIDs read in Microsoft Graph Explorer by an admin with SensitivityLabels.Read.All
Allow / Block personal sites	Personal sites (OneDrive) by Microsoft 365 Group ID	See below

Fifty entries is plenty for "the IT wiki and the HR policy site", and a site created next month stays out until you add it. A block list works the other way round: every new site is indexed by default, and anything on it that isn't access-restricted in SharePoint shows up for every Rovo user.

I'd watch the personal sites allow list. A blank one means all users, so turning Include personal sites on with an empty list puts every OneDrive in the tenant in scope.

"Blocking or allowing individual files or folders is not supported." A sensitive folder inside an allowed site goes in unless something else stops it.

Sensitivity label blocking keeps a file out

Atlassian added label blocking on 3 June 2026, and for a blocked label "None of its content, metadata, or embeddings reach Rovo's index." Label a file after it was indexed and "it stops appearing in Rovo search immediately and is purged from the index on the next full scan." I couldn't find how often the full scan runs.

Encrypted files are skipped anyway, so it's the labels you use without encryption that need listing. You read their GUIDs in Graph Explorer, Microsoft's web console for calling the Graph API.

Rovo agents and SharePoint as a knowledge source: the tracker says file names only

The connector step says "Rovo can use Microsoft SharePoint and OneDrive data in chat and agent responses". Atlassian's own bug tracker says that doesn't fully work yet.

ROVO-529, "Rovo Chat/Agent cannot read or search content from SharePoint resources", is a bug in Short Term Backlog with 41 votes. Its description: "The SearchTool is able to read SharePoint file metadata (e.g. filename), but not file contents." It was filed in December 2025, before the new connector. On 4 September 2026 Chait Donthini, the Atlassian who wrote the March connector announcement, asked in the ticket whether it was fixed, saying users should be able to reach SharePoint from chat and agents. A customer answered three days later: "No, it's not resolved."

Pages are the other gap. The connect page lists .aspx. Suggestion AI-1233 (22 votes, still Gathering Interest) was filed in September 2025 saying pages created in SharePoint "can't be ingested as of now", and Atlassian hasn't closed it since .aspx appeared in the doc. I haven't tested either on a live tenant, so pilot with one known file and one known page.

The same screen says "External AI models don't process this data." Rovo's data handling page says its hosted LLM partners run under zero data retention. How those fit when Chat answers from a SharePoint file, neither page explains. I'd ask Atlassian in writing.

One more. A Bugcrowd disclosure Varonis named RovoBlast, reported on 4 November 2025 and fixed on 8 July 2026, says the technique "was also demonstrated against data reachable through connected surfaces (Jira, and third-party connectors such as SharePoint and Outlook)." So a bug in Rovo can reach what you index, whoever is allowed to search it.

Indexing costs no credits; disconnecting takes 48 hours, deletion up to 30 days

"Connecting Teamwork Graph connectors and indexing data does not consume your Rovo credit allowance." It counts against indexed objects instead: 100 per user on Standard Jira or Confluence, 250 on Premium, 625 on Enterprise, and 1,000 to 6,250 on Teamwork Collection (Service Collection gets the same as Jira). Nothing on that page covers going over.

I pulled our own usage export (8 Sep to 20 Oct 2026, no connectors). The Teamwork Graph line was 1 event and 0 credits. Rovo Chat was 19 events and 1,435 credits (how to pull that export).

To get out, hide the app from Search or disconnect it. "It will take 48 hours to completely disconnect most apps." Cached data "may persist for up to 5 minutes". After uninstalling, stored content is deleted "within 30 days". Turning Rovo off doesn't switch Search connectors off, as we found when we looked at what stays on when you disable Rovo.

Before you connect: the security review checklist

What I'd do, in this order:

Grant admin consent to the consent app, 0c8611af-925f-491b-86f4-32fad2901689, before 15 November 2026, and log it. You don't need the connector for this.
Check two Entra settings the connect page needs. "Let Microsoft manage your consent settings" must be on, or "end-user authorization may fail". Everyone must be able to view site group membership, or group-based permissions "will not sync correctly". If your security team tightened either on purpose, write down why.
In a pilot or test Microsoft tenant, click Authorize and screenshot Microsoft's consent screen before you accept. Then open Entra > Enterprise applications > app 20ddde29-f84a-4a98-a8c2-b3b698d4ace2 > Permissions and screenshot the Admin consent tab. Delegated and application permissions are listed separately. Send it to Atlassian if anything surprises you, and only then decide on Authorize in production.
Review SharePoint sharing on each site you plan to allow.
Pick the sites with an allow list (50 max). Leave Include personal sites off unless you've named the Microsoft 365 groups.
Pull the sensitivity label GUIDs you never want indexed and add them to Limit by labels.
Turn off Include additional people fields if those shouldn't sit in the Teamwork Graph.
Decide whether the MCP sharing term is acceptable, and check your Guard data security policy if it isn't.
Pilot with one known file and one known page, and check whether Chat can quote the file's contents (ROVO-529).
Write down the exit: hide from Search, disconnect (48 hours), uninstall (30 days).

What we could not verify

The exact Graph permissions on the indexing app, and whether any are application permissions.

Which "service or admin account" the indexer runs as, and whether it supports Sites.Selected.

What happens in Rovo when a user leaves or loses a SharePoint group, and how fast.

How often permission sync and the full scan run. No Atlassian page we read gives a number.

What happens to PDFs over 10 MB, to SharePoint lists, and when you exceed the indexed-objects allowance.

Whether connector content counts as the "customer data" in Rovo's no-training sentence. Atlassian's connector privacy page promises no training only for Google Workspace data, and says nothing similar for SharePoint.

The setup page's own "Learn how permissions are kept in sync" link returns a 404 today. The page lives at a slightly different URL.

If you've clicked Authorize on a real tenant, what did Microsoft's consent screen and then Entra list under the indexing app's permissions, delegated or application? And did your security team sign it off as it was, or send you back with questions? Tell me in the comments. Even just the permission names would help everyone reading.

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.

Jira Formula Field: Build a Calculated Field in Jira Cloud

Mihai Perdum — Mon, 26 Oct 2026 05:59:27 +0000

Jira Cloud has a native calculated field now. It's called a Jira formula field. You create it like any other custom field, it's on all four editions, and it works in company-managed and team-managed spaces (spaces are what Jira used to call projects). We built five of them on our test site this week. Some parts surprised us: it can't read select fields or priority or other formulas, and an empty formula shows up in JQL as a zero.

The suggestion behind it, JRACLOUD-61966, "Calculated custom fields", was opened on 22 April 2015 and closed as Fixed on 3 August 2026, 4,121 days later, with 542 votes. Until then the answer on the Community was an automation rule that wrote a sum into a number field, or an app.

A lot of the questions during the beta were confusion, and they didn't stop at GA. Mikel asked on the ticket the day it closed: "How come a system field like Created is supported but another one like Resolved/Updated is not supported?" Nobody from Atlassian answered him there. The limitations table further down at least gives him a ticket to vote on.

By the end you'll have four formula fields in a company-managed space (one per output type) and one in a team-managed space. The screenshots are from wolfaenpak, our own test site, captured on 24 October 2026 (the account there uses Jira's dark theme, sorry about that).

[!NOTE]
Prerequisites — Jira Cloud on any edition (Atlassian's GA post: "Enabled by default across all Jira Cloud editions (Free, Standard, Premium, Enterprise)"). For a company-managed space you need Jira admin, because the field is created under Settings > Work items > Fields. For a team-managed space, space admin is enough (not sure which kind yours is? The first section of our Done-column tutorial has a quick check). You'll want a couple of number fields and date fields on your work items to calculate from. We used Story point estimate and a number field we added for the test, called Risk factor. Jira Data Center doesn't have this: its version of the request, JRASERVER-61966, was still Gathering Interest with 65 votes when we read it on 24 October 2026.

[[steps]]

Create the field — Settings > Work items > Fields > Create new field, type Formula.
Pick the space — one space or All Spaces.
Write the formula — choose the output, then the fields and functions.
Confirm the output type — it's locked after this.
Check the values — on a work item.
Search and report on it — JQL, list view, dashboards.
Repeat in a team-managed space — the Formula tile.

Step 1. Create a calculated field in Jira: choose the Formula field type (company-managed space)

Go to Settings (the cog) > Work items > Fields and select Create new field. A panel opens on the right. Open the Field type dropdown and type "formula". You'll get two results. Pick the wrong one and you get an error saying the field can only be used in Jira Product Discovery; two people hit that on the Community this summer.

Pick Formula, under Other fields. Custom formula is Product Discovery's own field type (it does roll-ups and weighted scores) and you can only use it in Product Discovery spaces. You know you picked the right type when a required Space field appears under Description.

Give the field a name. We'll start with the first of our four examples, a risk-weighted estimate called Weighted effort.

Step 2. Pick the space the field belongs to

The Space field offered "All Spaces" or one single space. Atlassian's page says the same: "You can't select more than one individual space." We picked our scratch space, Formula Lab (key FLAB).

If you want the field in three spaces but not the other forty, you'll have to choose between All Spaces and three separate fields. Our field wasn't on any screen when we created it (the REST view of the field said "screensCount":0). You'll see in Step 5 whether it turns up on the work item anyway. Ours did.

Step 3. Write the formula: Jira formula field functions and field references

Under Formula output leave it on Number for now (Step 4 is all about that choice). Then click into the editor. Typing { opens a list of fields you can reference, and typing a letter lists functions with a one-line description of each. The Format tab next to Formula sets how the value displays; Atlassian's page says you can show a duration as days or hours, or a number as a currency. We left it on the default.

Fields go in curly braces by their display name. Our first formula multiplies two number fields:

{Story point estimate} * {Risk factor}

To confirm the formula is valid, look for no red border or error line under the editor, the button still reads Generate formula, and Create is enabled.

Moritz on the Community spent a while on this step during the beta. He tried {issue.customfield_19054} * {issue.customfield_19055}, then double braces, then the bare field IDs. Then he tried the display names, {Probability} * {Consequence}, and still "the fields are always highlighted in red and cannot be saved." The thread never worked out why. If that happens to you, check that each field shows up in the { list.

The other three company-managed fields we built, with the output type each one needs:

Start by     (Date)      ADD_DATE({Due date}, -5)
Card label   (Text)      CONCATENATE({Summary}, " (", TEXT({Story point estimate}), " pts)")
Time to due  (Duration)  DATE_DIFF({Start date}, {Due date})

ADD_DATE counts calendar days. On a work item due Friday 6 November 2026, Start by came out as Sunday 1 November. There's an ADD_WEEKDAY() if you want working days. DATE_DIFF returns seconds, and a Duration output wants seconds. DAY_DIFF returns a plain number of days.

Which fields the formula can read

On our site the { list offered number fields, dates and date-times, short text and URLs. It also had four system fields: Summary, Created, Reporter, Team. These are the ones we typed in by hand and got refused:

{Priority}            Formula error: check formula text
{Change risk}         refused (single-select custom field)
{Severity}            refused (single-select custom field)
{Labels}              refused
{Weighted effort}     Formula error: check formula text (another formula field)
{Resolved}            Formula error: check formula text
{Updated}             refused
{Nonexistent field}   refused

Esha Gajula from Atlassian wrote on the GA article that "All fields configured for a Jira space (excluding Product Discovery / Service Management) will appear for Formula Fields." That didn't match what we saw. I think the field type matters more than the space: Resolved and Updated are system fields every space has, and they still weren't in the { list.

Created is a date-time and Due date is a plain date, and you can't mix them. DAY_DIFF({Created}, {Due date}) was refused. DATETIME_DIFF({Created}, {Actual end}) was accepted with Create enabled. Both of those are date-times (Actual end is a field we happened to have on the site).

The function names in the editor differ from the docs

Atlassian's supported functions page has 51 functions in four tables (17 number, 11 text, 19 date and time, 4 duration). The editor listed 56 when we typed every letter from A to Z, which is those 51 plus the five the page files under conditional operators. But ten names don't match:

Support page row	What the editor offers
LEN	LENGTH
DATEADD	ADD_DATE
TEXT_CONTAINS	CONTAINS_TEXT
HOURS_DIFF	HOUR_DIFF
MINUTES_DIFF	MINUTE_DIFF
SECONDS_DIFF	SECOND_DIFF
WORKDAY_DIFF	WEEKDAY_DIFF
ADD_WORKDAY	ADD_WEEKDAY
TO_DURATION	TO_SECONDS
DATETIME_FORMAT	FORMAT_DATETIME

Some of the page's own examples already use the editor's names (the LEN row's example is LENGTH({Summary})), so I'd trust the editor. We only typed the editor's names, so I don't know if the old spellings get rejected too. You won't find NOW() or TODAY() in either list. JRACLOUD-98610 asks for them (8 votes). Until then, a "days until due" field has to count from another date field on the work item.

If the formula has a problem, the button under the editor changes from Generate formula to Fix formula and Create is disabled. Both buttons use Rovo. On an unfinished SUM({Story point estimate}, it suggested SUM({Story point estimate}), which is valid and also pointless (a sum of one field). We couldn't find an Atlassian page that says whether these buttons spend Rovo credits.

Step 4. Confirm the output type, because you can't change it later

Select Create. Jira stops you with a dialog before it creates anything:

After you confirm, the panel closes and the new field is the top row of the Fields list, with type Formula. When we opened it again with Edit field, the formula and the name were editable, but there was no Formula output control at all. In its place was a new Searcher template dropdown set to "Number Formula Searcher."

So if you guessed wrong (say you made a Number when you wanted a Duration), you create a new field and delete the old one. Atlassian's GA post says the lock is there "to ensure JQL and reporting stability". I think that's about search: the output type decides how JQL indexes and compares the value, and Step 6 shows what that does to empty values.

Step 5. Check the values on a work item

We filled ten work items in FLAB over REST, with story points, a risk factor, a due date and a start date, and we left a few inputs empty to see what happens. FLAB-1 had 5 points, risk 1.5, due 20 November and start 2 November:

The formula fields appeared in Details without us adding them to a screen. If they don't on your site, the field's Actions menu in Settings > Work items > Fields has an Add field to screen option.

Two things caught us out in the values:

An empty input makes the whole result empty. FLAB-6 had no risk factor, so Weighted effort was empty. It didn't fall back to 0. If you'd rather get a number, wrap the field: IF(IS_NONE({Risk factor}), 0, {Risk factor}) (that's the editor's own example). Sara asked on the GA article how to get SUM to ignore blanks "without including heaps of IF functions"; as far as I can tell, IS_NONE around each field is the way.
Decimals come back raw over REST. 21 points times 1.8 showed as 37.8 on screen and as 37.800000000000004 over the API. If anything downstream reads that number, use ROUND().

Then we checked how fast it updates. We changed Risk factor over REST on three work items and polled every half second. The new Weighted effort was there on the first read, 0.74 to 1.31 seconds after the change. In the browser an inline edit from 1.2 to 2 changed the value from 15.6 to 26 in 0.81 seconds, without a reload.

Step 6. Search, sort and chart it: JQL, list view and dashboards

You can use a formula field in JQL by its name or by cf[id] (Weighted effort was cf[12644] on our site). Jira also adds a clause name with a [Formula] suffix. All of these returned the right work items, so you should see the same on your own fields:

"Weighted effort" = 16
"Weighted effort" >= 6 ORDER BY "Weighted effort" DESC
"Weighted effort[Formula]" > 10
"Card label" ~ "Checkout"
"Time to due" > 1000000 ORDER BY "Time to due" DESC

JRACLOUD-99328 says you can't order by a formula, but on 24 October 2026 our ORDER BY came back in the right order, through the API and in the search screen:

Empty formulas are indexed as zero

The two empty rows at the bottom of that screenshot could just be Jira putting blanks last. They aren't. JQL really does treat them as 0, and an empty date as 1 January 1970:

"Weighted effort" = 0                                -> FLAB-10, FLAB-6   (both empty)
"Weighted effort" < 5                                -> FLAB-10, FLAB-8, FLAB-7, FLAB-6, FLAB-3
"Weighted effort" is EMPTY                           -> no results
"Start by" < "2026-11-10" ORDER BY "Start by" ASC    -> FLAB-7 first      (empty, so 1970)
"Start by" = "1970-01-01"                            -> FLAB-7
"Start by" < startOfMonth(1)                         -> FLAB-7 only       (nothing real starts before 1 November)
"Start by" is EMPTY                                  -> no results
"Time to due" = 0                                    -> FLAB-8, FLAB-7    (both empty)
"Card label" is EMPTY                                -> FLAB-10           (text works)

(We ran the < 5 query as cf[12644] < 5; it's the same field.) We ran them again 26 minutes after creating the work items and got the same result, so it wasn't index lag. Text formulas index their empties properly. Number and date formulas don't, and we couldn't find a ticket for it. Until there is a fix, a filter like "everything with low weighted effort" needs a guard on the inputs. Those are ordinary fields and index their empties properly. We didn't run this one ourselves:

"Weighted effort" < 5 AND "Risk factor" is not EMPTY AND "Story point estimate" is not EMPTY

I'd put that guard in any saved filter you share with a team. And give the index a moment after an edit. After the Risk factor changes above, JQL matched the new values after 2.6, 20.6 and 19.0 seconds, while the work item had them within about a second.

Durations turn into seconds on dashboards

The work item and the search screen show Time to due as "2w 4d" or "4d". We added a Filter results gadget to a dashboard with the same fields as columns, and got this:

That's JRACLOUD-99330, "Formula field with 'Duration' formatting displays raw seconds in Dashboard gadgets instead of Days", a bug with 6 votes and "no known workaround". If a dashboard matters more to you than the nice "2w 4d", I'd make it a Number output with DAY_DIFF() instead. The gadget also listed our rows in key order even though the filter ended with ORDER BY "Weighted effort" DESC. And the date formula's format moves around. It was "Nov 01, 2026" in the search screen and "15/Nov/26" in the gadget, while the native Due date column said "Nov 6, 2026" without the leading zero.

Reading the value over REST

If you export or sync data with a script, this is what a formula looks like through the API. We ran this against FLAB-1:

curl -s -u "$JIRA_EMAIL:$JIRA_API_TOKEN" -H 'Accept: application/json' \
  "https://wolfaenpak.atlassian.net/rest/api/3/issue/FLAB-1?expand=renderedFields,names,schema"

Trimmed to the four formula fields, with the names and schema sections left out (the schema keys are quoted below):

{
  "fields": {
    "customfield_12644": 7.5,
    "customfield_12647": "2026-11-15",
    "customfield_12648": "Checkout redesign (5 pts)",
    "customfield_12649": 1555200.0
  },
  "renderedFields": {
    "customfield_12644": null,
    "customfield_12647": "15/Nov/26",
    "customfield_12648": null,
    "customfield_12649": null
  }
}

12644 is Weighted effort, 12647 Start by, 12648 Card label and 12649 Time to due. The schema type for the number was com.atlassian.jira.system.formula.fieldtypes:numberformula. The date and text ones end in :dateformula and :textformula. Duration has no type of its own. It's a numberformula in seconds, so your script has to know which number fields are really durations. renderedFields was null for everything except the date. JRACLOUD-99559 reports the same for the search API.

If you were hoping to script the setup, you can only do half of it. A POST /rest/api/3/field with the numberformula type returned 201 and gave us an empty Formula field with no formula. There was no parameter for the formula or the output type, and the context configuration endpoint answered "This API works only with fields provided by Forge apps."

Step 7. Add a formula field in a team-managed space

In a team-managed space it's a space admin job. Open Space settings > Work types, pick a work type (we used Task), and look at the Fields panel on the right. Under Create a field there's a Formula tile. Atlassian's page lists a few other ways in, like Space settings > Fields or Add column (+) in the List view. We used the work type layout.

Drag it into the work type's fields, give it a name and write the formula. Ours was a number called Days to due:

Select Save changes, and you get a dialog that says "Create 1 formula field" and "A formula field's output type can't be changed once created." You'll see a "Work type updated" message when it's done.

Team-managed will save a formula field with no formula in it. We did that by accident on the first save, with no warning, and the value just stayed empty. When we added DAY_DIFF({Start date}, {Due date}) and saved again, the existing work item showed 18 without us editing it. So I'd look at the formula once more before you leave the page.

The team-managed field belongs to that one space. Over REST it shows "scope":{"type":"PROJECT"} and it didn't come back from the field/search endpoint at all, so a script that inventories fields through field/search won't see it.

Jira formula field limitations: select fields, rollups, formulas of formulas, output type

These are the gaps we hit or confirmed, with the ticket to vote on if one matters to you (votes as we read them on 24 October 2026).

What you can't do yet	What we saw	Ticket
Read a select list, checkbox or radio custom field	refused (Change risk, Severity)	JRACLOUD-98942, 2 votes
Use Priority or Labels	refused (Priority: Formula error: check formula text)	no ticket we could find
Roll values up from child work items	the formula "can only run using data within a single work item"	Atlassian says "not yet supported"
Reference another formula field	Formula error: check formula text	JRACLOUD-99874, 1 vote
Use Resolved or Updated	refused (Resolved: Formula error: check formula text)	JRACLOUD-99209, 0 votes
Use time tracking fields	not offered in the `{` list	JRACLOUD-99552, 1 vote
Use today's date	no NOW() or TODAY() function	JRACLOUD-98610, 8 votes
Change the output type	no control on the edit panel	locked by design
Show durations in days on a dashboard	raw seconds in Filter results	JRACLOUD-99330, 6 votes
Use it as a board's estimation statistic	not tested by us	JRACLOUD-99810, 1 vote
Write a formula longer than 255 characters	not tested by us	JRACLOUD-98844, 5 votes

JRACLOUD-99874 quotes a different message for formula-of-formula, "Formula error: 2 invalid fields", so the wording can vary. The 255-character limit comes from JRACLOUD-98844 and from a customer who said support told them the internal customfield_ IDs count toward it. Atlassian doesn't document it anywhere we could find, so treat it as reported until you hit it yourself.

I'd expect the select-field gap to hurt most. The beta article planned "Priority, Select (including checkboxes), Labels" as inputs for spring 2026. The GA post lists select fields as "not yet supported" and doesn't mention Priority or Labels at all. Julia on the GA article described risk select lists she was converting to numbers with automation: "It would be great if that could be done with a formula instead of automation!"

If your formula won't save

"Formula error: check formula text" under the editor, with a red border and Create greyed out. We got it for every bad reference where we read the message, so go through the formula field by field. Is each one in the { list? Are you mixing a date with a date-time? Is it a select, Priority, Labels, Resolved, Updated or another formula? Are the braces and quotes closed?

"Edit formula to generate number values" or "Edit formula to generate text values" means the formula is fine but returns the wrong type for the output you picked. {Summary} in a Number field gives the first, {Story point estimate} * 2 in a Text field gives the second. Wrap numbers in TEXT() for a text output.

"Example: SUM({field1}, {field2})" under the editor, together with the error, means a function isn't finished yet.

An error that the field can only be used in Jira Product Discovery means Custom formula was picked instead of Formula (see Step 1).

No Formula type in the dropdown usually means the site hasn't got the release yet. During the beta it needed a toggle in Beta features. Since GA, Atlassian says there's "No more admin opt-in via the Beta Features toggle." During the beta Atlassian also said that sites on bundled release tracks get it a few months later. That's a Premium and Enterprise option where an admin takes most Cloud changes as one monthly bundle, set in Atlassian Administration > Apps > Release management > Release tracks.

Division by zero passes the editor's check. {Story point estimate} / 0 and DIV({Story point estimate}, 0) both left Create enabled. We didn't save them, so we don't know what they show on a work item. Guard the divisor with an IF() if it can ever be 0.

When a Jira Cloud calculated field still needs automation or an app

A formula only sees the work item it's on, so an epic that adds up its stories, or a WSJF score built from select lists, is still out of reach. Atlassian's support page puts it as "It can't calculate costs across work items B and C, or any other work item."

For a rollup, the native option is still an automation rule. A Lookup work items action can find the children (Atlassian caps it at 100 results) and {{lookupIssues.Story Points.sum}} adds them up. Then an Edit action writes the total into a number field on the parent. It works, and it's still an automation rule: each trigger, condition or action it runs counts as an automation step, and extra usage gets billed from 3 December 2026. We measured how many steps common rules use if you want to cost it before you build it. Atlassian's FAQ calls the formula field "a new custom field type that doesn't replace or modify any existing fields or automations", so your existing rollup rules keep running. Atlassian also says formula fields can trigger automation rules and be used in them; we didn't test that part.

On Premium and Enterprise, Plans can roll up estimates and dates from children inside a plan. Atlassian started rolling out scenario recalculation for formula fields in Plans in July, and it was still labelled rolling out in late September. Those roll-ups are calculated in the plan, though. Atlassian's page says rolled-up dates aren't saved when you commit changes back to your work items, so don't count on the parent's own field getting the total.

For select-list maths, people use the workaround Julia described. An automation rule turns each option into a number in a separate number field, and the formula reads that. Decide what None maps to as well, because an empty number field empties the formula (Step 5). If a default value has hidden None from that select's dropdown, here's how to bring it back. Before GA, Atlassian's ticket pointed people who wanted calculated fields to apps (sumUp for Jira, Abacus and ScriptRunner, "neither built nor maintained by Atlassian"). We haven't tested whether any of them does rollups or formulas of formulas.

What you have now

[[takeaways]]

Formula fields in a company-managed space (Settings > Work items > Fields) and a team-managed space (Space settings > Work types), with the output type chosen for good.
The field and function names the editor accepts, and the fields it refuses.
JQL that searches and sorts by a formula, plus the guard for empty values.
What it doesn't cover: rollups, select fields, formulas of formulas and dashboard durations in days, each with its ticket in the table above.

Have you found a formula that does something clever within these limits, or a way around the empty-is-zero search? Tell me in the comments or mail gabriela at leanzero.net, and I'll add the good ones here :)

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.

Can't Delete an Atlassian Organization Because of Rovo

Mihai Perdum — Sat, 24 Oct 2026 11:07:40 +0000

In July someone opened a Community thread called "Stuck in loop: Cannot delete account due to platform apps and Rovo, but restricted from opening a support ticket". They wanted the whole account and organization gone. Delete organization told them to "Remove platform apps and Rovo - Contact Support", and that really is the only way through: Rovo can't be removed from an organization without someone at Atlassian doing it for you.

We looked at the same screen on our own test org, wolfaenpak, on 23 October 2026. The Delete organization button is grey. The Outstanding steps dialog lists two blockers, and you can clear the first one yourself by cancelling subscriptions. The second reads, word for word: "Remove platform apps and Rovo. Contact Support to request removal of platform apps and Rovo."

So you raise a ticket with Atlassian's billing team and ask them to remove Rovo and the platform apps. Then you wait out the grace period, and the button should unlock. We also found a second route that none of the 17 Community threads we read mention. Rovo has its own subscription in Billing, and its Cancel subscription item opens a box that says to email sales-ops-support@atlassian.com with the entitlement number.

I think this matters more than it looks. It doesn't only hit people tidying up a forgotten trial. If you're consolidating organizations after a migration, the Transfer apps flow checks Rovo too. On our org it checked something the docs don't mention.

What we found when we tried to delete, transfer and cancel on our own org

We did this as an org admin on wolfaenpak, our Atlassian test organization (nothing on it is production). Mihai's test harness is a script that drives a real browser. It opened each screen, saved a screenshot and the page text, and recorded the requests the admin pages sent. We checked Organization settings (Profile), Apps, Billing and the Rovo access page. We changed nothing, and we closed each dialog before its last step.

Delete organization stays disabled with 2 outstanding steps. They are "Cancel subscriptions and trials" and "Remove platform apps and Rovo". The button has no tooltip. You see the reason only after you click View steps.
Rovo is an organization-level entitlement on our org. The deletion check itself just returns "productsRemoved": false. But the same page loads the org's entitlements, and com.atlassian.rovo is listed there as ACTIVE.
Rovo isn't in the Apps list. Searching Apps for "Rovo" showed "Showing 0 results out of 90 apps", even though Atlassian's billing doc says to look for it there.
Billing has two Rovo rows. One is Rovo credits, the usage meter, with Upgrade plans, Enable extra usage and Manage customer contacts in its menu. The other is Rovo itself on a Free plan, with Change plan and Cancel subscription.
Cancel subscription on Rovo doesn't cancel it. It opens "Contact us to cancel your plan" and asks you to email sales-ops-support@atlassian.com with the entitlement number. The only button is Got it.
Transfer apps showed a Rovo blocker of its own. We could pick 3 destination orgs. For 2 of them the transfer stopped on "Your destination organization doesn't have Rovo enabled". For the third, that card wasn't there.
We found no separate merge screen. Merging is the Transfer apps flow. Its first page says "When the transfer is complete, we'll delete your current organization."

Why you can't delete your Atlassian organization while Rovo is on it

Atlassian's deletion doc says so in its list of things to do first: "You can't directly cancel certai[n] apps, like Rovo and Atlassian Guard, you need to contact Atlassian support to request removal." (The missing letter is theirs.) That line is pretty new. The Wayback Machine copy from 5 October 2025 has no Rovo in it, and the copy from 4 November 2025 does.

AX-429 on Atlassian's public tracker explains why: "Since Rovo is a free product that admins can't delete, it blocks the organization deletion to happen, requiring manual intervention from Atlassian." To delete an org, its apps have to go first. And Rovo is one you aren't allowed to remove.

The blocker also says "platform apps". Atlassian's doc defines those as apps "pre-loaded onto any Atlassian site", and lists Home, Goals, Teams, Analytics, Administration, Rovo, Chat, Search and Studio. Community askers also name Projects. You can't remove these yourself either, so put them in the same ticket.

How did Rovo get there if you never bought it?

Most people asking on the Community didn't add Rovo. Atlassian did. On 9 April 2025 it announced Rovo for all customers, "included in your existing subscription". Its Rovo licensing FAQ says that on a paid Standard, Premium or Enterprise plan "Rovo will be automatically added to eligible sites as part of the rollout". The same FAQ says you can trial Rovo through a trial of Jira, Confluence or JSM on those plans.

So the usual story goes like this. Someone starts a Premium trial and Rovo comes along. The trial ends. With no payment details, Atlassian "will change your app to a Free plan" (its doc on adding apps). Jira or Confluence can then be cancelled like any other app, but Rovo stays behind. One asker said Rovo and Teams showed "Managed by Atlassian" with no remove or cancel option.

Sandboxes are the odd one out. Atlassian's doc says Rovo switches itself on in sandboxes created after 14 April 2025. But there you get a self-service "Deactivate Rovo" on the site row. I'd love to see that on production orgs too.

Blocking Rovo isn't the same as removing it

Admins in the Community threads keep mixing these two up. Atlassian Administration has a Rovo access page where you can put apps on a blocklist. It turns AI features off. It doesn't remove Rovo from your org.

The page hints at it. On our org the blocklist section reads: "Rovo can still access data for the apps you block, but external AI models don't have access to that data." Atlassian's doc on Rovo access says blocking an app "will disable all current and upcoming AI features for that app". It also says "Any content previously generated by Rovo will remain." We found nothing in it about cancelling Rovo.

James O'Connor wrote a Community article called "Why is deleting Organisations so painful?" (1,451 views, 26 comments). In the comments someone suggested deactivating AI, and he replied that to delete an org, Rovo "has to be removed", and "the only way that can be done is by the Atlassian support team." We didn't flip the blocklist to test whether it changes the deletion blocker.

How to delete Rovo from your Atlassian organization: the billing ticket that works

There are two documented doors, and both lead to Atlassian's billing people. The ROVO-144 workaround says to "raise a ticket with our billing support team to get the Rovo subscription cancelled", and links the Pricing, Billing & Licensing page. The Contact Support button in our Outstanding steps dialog opens that same page. The other door is the email address in Rovo's own cancel box, sales-ops-support@atlassian.com. That's the same address Atlassian's transfer doc gives for cancelling Enterprise plans.

Jessica, answering for the Atlassian Team in June, wrote: "our billing team is the channel where you can ask deletion of products directly". She added that Free accounts can open requests there "with no restrictions". In another thread she said technical support "are also not able to perform the deletion of those products". We haven't sent either request from our own org, so I can't tell you which door is faster.

What I'd do, in order:

Decide what you want first. If you're deleting the org, cancel the subscriptions and trials you're allowed to (Billing, Manage subscriptions) and remove your domains. Cancelling an app deletes its data once the grace period ends, so export first. If you're moving apps to another org, cancel nothing and only ask for Rovo to be deactivated (see the transfer section below).
Screenshot the Outstanding steps dialog. Organization settings, Profile, then View steps under Delete organization.
Find Rovo's entitlement number. In Billing, find the row named Rovo with the Free plan (on our org it was on page 2 of the list, and Rovo credits is a different row). Open it, and the number starting with E- is in the breadcrumb at the top.
Send the request. Either email sales-ops-support@atlassian.com, as the cancel box says, or use the Pricing, Billing & Licensing form from the Contact Support button. Log in first on the form, it shows "YOU'RE LOGGED OUT" otherwise.
Ask in one plain sentence. Something like: "Please remove Rovo (entitlement E-xxxx) and the platform apps from organization , so we can delete it. Per ROVO-144 this can't be done in Atlassian Administration."
Include the identifiers. Your organization URL (admin.atlassian.com/o/ and your org ID), the site URLs in it, and the screenshot. Arkadiusz Wroblewski, a Community Champion, suggests exactly these. Say whether the org should be deleted afterwards, or whether you only need Rovo gone for a transfer.

Which menu path in the contact form gets you to a ticket?

I couldn't verify this part. The contact form builds its options in the browser, and our headless browser couldn't open the dropdown. Community answers give three different paths. Tomislav Tobijas (a Champion) says "Your Account → Cancel cloud subscription, then click Need more help?", then a Submit a support request button under the chatbot. Marc from Devoteam says Quotes and Plan Changes, then Change cloud plan, then Need more help. An older answer says admin.atlassian.com, Support, Billing & org management. The email route skips the form entirely, which is one reason I'd try it first.

What if you're on a Free plan and can't open a ticket?

Five of the askers we read say they couldn't open a ticket on a Free plan. Two say the form sent them to articles or to the Community instead of letting them submit. Atlassian staff say Free accounts can open billing requests "with no restrictions". In the threads we read, posting on the Community anyway did work. Three times an Atlassian Team member opened a ticket for the asker, after 16, 29 and 32 hours.

How long until Delete organization unlocks after the ticket

Probably weeks. Atlassian's deletion doc says apps "aren't fully deactivated until 15 days after the date the cancellation takes effect". With the original billing experience you can delete the day after. With the improved billing experience you wait "an additional 60 days after the apps are deactivated". Atlassian's doc on removing apps says 14 days. You can't easily tell which billing experience you have, so ask in the ticket.

Champions answer fast on the Community, 7 to 25 minutes in the threads we timed. But we read 17 deletion threads with 6,369 views between them, and none says when the org was finally gone. One admin, Carla, shared the ticket wording she reuses: "Please expedite the removal of all apps and deletion of org ID- org name-". She says it lets her delete orgs "within a few weeks instead of months". Two others still have old orgs: one that a support ticket "couldn't get rid of", and demo orgs another admin has been "unsuccessful in getting removed, even after support tickets".

Before you start, know that once the org is deleted, you can ask support to restore it within 15 days. And deleting an org also deletes its admin API keys and audit logs, so export what you need first.

Transfer all apps to another organization: deactivate Rovo first

If you're merging organizations, read this part twice. Atlassian's transfer doc says: "If your organization has a Rovo subscription, you'll need to contact our billing support team to deactivate Rovo before you start the transfer. After deactivation, Rovo subscriptions can be re-enabled in the destination organization through the Apps section in Atlassian Administration." That sentence appeared between August and September 2025, per the Wayback Machine. The checklist also asks you to turn AI off for each app before the transfer and back on afterwards.

Our transfer screen showed something extra. We opened Transfer apps, picked a destination org and got seven blocker cards. Most were about our test org's own setup (Atlassian Guard, API keys, data classification levels), and one of them read: "Your destination organization doesn't have Rovo enabled. Enable Rovo in your destination organization, then try again." The check behind it said "Destination org is missing org-level packages required by source org: Rovo". We tried all three destinations. For one, the Rovo check passed and the card went away.

The wording says "required by source org", so that check exists because our source org has Rovo. Deactivating Rovo on the source, as the doc asks, may clear it. We didn't test that. AX-2002 on the tracker adds another twist: a Rovo licence on the source can grey out the Transfer products button without showing up in the pre-check list. The ticket quotes the hidden reason, "reparentBlockers": ["ROVO_LICENSE"]. Our button wasn't greyed out, so we didn't hit that one.

So for a transfer, ask billing to deactivate Rovo on the source. Then click through Transfer apps again and see whether the destination card is still there. If it is, enable Rovo on the destination.

Merge Atlassian organizations when the source org has Rovo

Atlassian's merge page says merging "is done by transferring all apps from one organization to another". After the transfer, the unwanted org is deleted. So the Rovo checks above apply to a merge too. ROVO-144 calls it out for the new user management experience: "Customers cannot merge organizations until Rovo is deleted." With the centralized user management experience you can't transfer apps yourself. The merge page says support "may be able to help" if the orgs have 1 to 20 sites and under 180k events (users, groups and memberships added up).

Where this bites in a migration (DC to Cloud and Cloud to Cloud)

If you're coming from Data Center, watch the orgs you create along the way. Atlassian's cloud migration trials run on Standard or Premium for up to 12 months, and can go on a new cloud site. Rovo can be trialled through those plans, so I'd expect Rovo to turn up on a rehearsal org. Atlassian doesn't say that about migration trials, so treat it as my inference. The trial doc also says that if you don't subscribe, "your data will also be deleted after 15 days". It says nothing about the org, so the org (and its Rovo) can outlive the trial.

If you rehearse JCMA (Atlassian's migration assistant) runs against a throwaway site, that site sits in an org of its own unless you put it somewhere else. Darryl Lee wrote under the same "so painful" article that his accidental sites date from April 2024, "shortly after migrating from on-prem to Cloud". Before your first test migration, decide which org is the real one and put the rehearsal sites in it. On Premium or Enterprise you can use sandboxes, where Rovo has a self-service Deactivate. Even there, CLOUD-12357 (In Progress) says Rovo can make a forced sandbox deletion fail.

If you're doing Cloud to Cloud, the leftover is the source org. Copy product data (Atlassian's cloud-to-cloud tool) moves projects and spaces between orgs. It leaves the source where it was, and Atlassian's billing doc says you pay for both until you move the source to Free. On Free, Rovo is still there, and so is the org. Maybe you'll consolidate by transferring the remaining apps instead. Then the workaround on Atlassian's own bug COMMERCE-49 (closed in 2025) is blunt: "Make sure to cancel the Rovo subscription, before the org consolidation." Mihai wrote more about how orgs relate to Copy product data in our guide to Atlassian cloud architecture for migrations, and about keeping user and group identity straight in a C2C move in migrating Jira users and groups with the same name.

So put the Rovo request in your migration plan with an owner and a lead time of weeks. Don't leave it for cutover week.

What I'd do if I were cleaning up orgs this quarter

Send the Rovo request as soon as you know an org has to go. Delete organization can't unlock until Rovo is gone, and the grace periods above only run out after that. In the same request, ask for the org to be deleted after the apps are gone. For a consolidation, ask for Rovo to be deactivated on the source, then walk the Transfer apps screen once to see the other blockers before you book a date. And vote on ROVO-144 and AX-429 (114 votes). Neither has an Atlassian comment yet.

Keeping Rovo and watching the cost instead? We measured what each action spends in Rovo credits per user. And how to set or turn off extra usage before 3 December covers the spending cap you can change yourself.

Now I'm curious. Have you had Rovo removed from an org this year? Did the sales-ops email work, or the billing form, and how long did it take until Delete organization was clickable? Tell me in the comments. I'll add the answers here, because I couldn't find anyone who has written that number down.

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.

Rovo Agent Pricing in Jira Automation: Cost per Agent Call

Mihai Perdum — Sat, 24 Oct 2026 07:59:06 +0000

Rovo agent pricing in Jira automation comes down to one number: a Rovo agent inside a rule costs 10 Rovo credits each time the rule calls it. We built eight rules on our test site on 23 October 2026 and read the org's Rovo credits meter after each run. Twelve calls on the Quick answers tier all cost 10, and an agent switched to Claude Sonnet 4.6 cost 13.

You pay per question to the agent. Rule runs don't matter. One run of a rule that branched over three sub-tasks cost 30 credits, and a scheduled rule cost 20 because its JQL found two work items. Jira Standard gives each seat 25 credits a month. That's 2.5 agent calls per person.

From 3 December 2026 Atlassian bills usage above the pool at $0.01 a credit. Say a rule triages each new work item and your people raise ten a month each. If nothing else uses the pool, that's roughly 75 cents per seat a month on Standard, and $1.00 if Rovo Chat already spends it. At 200 seats that's $150 to $200 a month for one rule, which runs on each new work item whether anyone reads the comment or not.

Our earlier Rovo credits per user piece measured Chat and left agent runs out. This one measures them, and the per-seat numbers below sit next to our 2027 usage budget for 50, 200 and 500 seats.

[!NOTE]
Prerequisites — Jira Cloud on a paid plan with Rovo, and Rovo agents allowed in automation. To read the Rovo credits meter you need to be an organization admin in Atlassian Administration. To build rules and read the automation audit log you need Jira admin (or project admin for project rules). Everything below was run on our wolfaenpak test site on 23 October 2026 between 07:28 and 08:37 UTC, under our test admin account, in a fresh company-managed project, one rule at a time. Atlassian's prices and allowances were read on Atlassian's own pages the same day.

An agent call cost 10 credits, and a rule pays per call

We named the rules ROVO-A1 to ROVO-A8 and ran them against work items in a scratch project, RAGT. Here's what the meter showed:

10 credits per agent call on the Quick answers tier. Twelve calls, nine runs, six rules. They used Atlassian's Bug Report Assistant or our own custom triage agent, on created, manual and scheduled triggers. For the branch rule and the scheduled rule, that's the run total divided by the number of agent calls.
Credits follow agent calls. One rule run can hold several. A branch over 3 sub-tasks cost 30. A scheduled rule whose JQL matched 2 work items cost 20.
A condition before the agent made the run free in credits. Our copy of Atlassian's "triage bugs" template skipped a Task at its issue-type condition, and the meter stayed at 321 for five minutes.
Think deeper alone still cost 10. Switching the model to Claude Sonnet 4.6 made it 13. That's one run on the default model (Gemini 3.5 Flash) and two on Sonnet, so treat it as a first reading.
No automation steps for the agent. Everything else in the rule was billed as steps. The agent call wasn't.
Only Allowance used kept up. It had moved by our first reading, about 22 seconds after the trigger, in almost every run, and within 45 seconds in all of them. The Features tab and the "Rovo credit usage in Automation" card were about half an hour behind.

How Atlassian bills a Rovo agent in a rule: Rovo credits and automation steps

Atlassian's automation doc is clear on the split: "Agentic components like Use Rovo, Use agent, or Use Jira Coding agent are billed separately under Rovo credits and do not consume automation steps." The Rovo licensing FAQ says the same from the other side, and adds that "a single automation rule can consume from both meters in one run, but each meter is tracked and billed independently". So the agent comes out of your Rovo credits, and the rest of the rule out of your automation steps.

Atlassian doesn't publish a per-call price for the agent step. The Rovo rate table has "Basic Rovo Agents (no model selection)" at "10 Rovo credits per billable event" and "Advanced Rovo Agents (with model selection)" at "Variable credits per billable event". Neither row names Use agent or automation. In our runs the basic case was 10, and switching the agent to Claude Sonnet 4.6 took it to 13, twice. We didn't price Use Rovo, the other agentic component, because we only built Use agent rules.

Atlassian's pages said this on 23 October:

	Standard	Premium	Enterprise
Jira Rovo credits per user a month	25	70	150
Jira automation steps per user a month	400	750	1,000
Over the pool, Rovo credits	$0.01 per credit	$0.01 per credit	$0.01 per credit
Over the pool, automation steps	$0.50 per 1,000	$0.50 per 1,000	$0.50 per 1,000

Both pools are shared across the whole org, and Confluence seats add their own 25, 70 or 150 credits each. Atlassian's usage doc says "On December 3, 2026, extra usage billing takes effect", and its pricing FAQ says extra usage is on by default "for most organizations". Our test org shows "Extra usage disabled", so its new credit-consuming requests would pause at the pool instead of billing on. If you'd rather set a cap first, our Rovo usage limit tutorial walks through it.

Add a Rovo agent to a Jira automation rule (Use agent)

If you haven't built one yet, Atlassian's own template is the quickest way in. In your project go to Space settings > Automation > Templates, open Rovo AI Agents and pick Use Rovo Agent to triage bugs in Jira. That gives you a Work item created trigger, an issue-type condition, a Use agent step and an Add comment to work item step that posts {{agentResponse}}.

One catch: on our site the template opened with Let this agent take actions already switched on, even though Atlassian's doc says the toggle is "off by default (including exisiting automations)". Switch it off before you save unless you want the agent writing to your work items.

In the Use agent panel you pick the agent from a list of Atlassian's agents and your own. We looked for a model or reasoning setting there and found none. Those live on the agent itself, in Rovo Studio, so if someone changes an agent's model, each rule that uses it changes price too.

The prompt takes smart values like {{issue.key}} and {{issue.summary}}, and the agent's text comes back as {{agentResponse}} for the next step. With actions switched on, the agent can change your work items. With a User's account it does that with the permissions of whoever set up the rule (our panel said "This agent will use Mihai Perdum's permissions"). With an Agent's account it uses only what the agent itself has been granted. Our piece on Rovo agent permissions covers who ends up acting.

You should see the run show Success in the audit log, and a comment from "Automation for Jira" on the work item. Ours arrived 15 to 31 seconds after the trigger. If the audit log says "Agent invocation failed" but the comment did arrive, count the call: ROVO-1071 is an open bug where the log reports that "even though the agent completed successfully".

We first tried to create the template rule through the automation REST API and got a 400 back, because a Use agent step needs its own Rovo connection. The builder worked first time. If you script rules, give each new rule its own new connection.

Measure what one run of your rule costs

The rule won't tell you what it spent. You measure it from outside, about ten minutes per rule.

[[steps]]

Open the meter — in Atlassian Administration go to Insights > Platform usage > Rovo credits, Usage tab, current billing period, and write down Allowance used. Leave Credits this period and the Features tab alone for this; they lag.
Check nothing else is spending — reload after two minutes. If Allowance used moved, someone else is using Rovo and your reading will be off, so try again later.
Switch on only the rule you're testing — then trigger it once: create a work item, run the manual trigger, or wait for the schedule.
Read Allowance used again after two minutes — the difference is what one run cost.
Open the audit log — in Automation > Audit log, expand the run and count how many times the Use agent component ran. Credits divided by agent calls is your price per call.
Switch the rule off — if it was only a test. Our 13 test runs cost 156 credits, which would be $1.56 over the pool, and they came out of the same pool everyone else uses.

Allowance used should show no change during the quiet check and then move once, by the price of the run. Here's our first run (ROVO-A1, one new work item), polled every 20 seconds:

quiet check   [0 s, 291] [21 s, 291] [43 s, 291] [64 s, 291] [85 s, 291] [106 s, 291] [128 s, 291]
after trigger [22 s, 301] [44 s, 301] [65 s, 301] [86 s, 301] [107 s, 301] [129 s, 301] [151 s, 301]

And the same run in the audit log, Success in 3.67 seconds:

jira.issue.event.trigger:created x1
rovo.invoke-agent.action x1
jira.issue.comment x1

Here's the whole run log. RAGT is the scratch project and the keys are the work items each run touched:

run        rule                                   items          meter       credits
A1-r1      created -> agent -> comment            RAGT-8         291 -> 301  10
A1-r2      created -> agent -> comment            RAGT-9         301 -> 311  10
A2-r1      template, Bug passes condition         RAGT-10        311 -> 321  10
A2-r2      template, Task stopped by condition    RAGT-11        321 -> 321   0
A5-r1      manual -> agent -> comment             RAGT-7         321 -> 331  10
A5-r2      manual -> agent -> comment             RAGT-7         331 -> 341  10
A3-r1      manual -> branch 3 sub-tasks -> agent  RAGT-2,3,4     341 -> 371  30
A6-r1      created -> custom triage agent         RAGT-12        371 -> 381  10
A6-r2      created -> custom triage agent         RAGT-13        381 -> 391  10
A4-r1      scheduled JQL, 2 matches               RAGT-5,6       391 -> 411  20
A8-r1      Think deeper, Claude Sonnet 4.6        RAGT-14        411 -> 424  13
A7-r1      Think deeper, default model            RAGT-15        424 -> 434  10
A8-r2      Think deeper, Claude Sonnet 4.6        RAGT-16        434 -> 447  13

I added the 13 runs up to check: 156, the same as the meter's 291 to 447. Our quiet checks before the runs were all flat. Nothing else on the org was spending.

Count the automation steps from the Usage tab, not the audit log

The audit log counts the agent as a component, and the bill doesn't. The Usage tab is what Atlassian bills, and it leaves the agent out.

On our branch rule the audit log showed 8 components: the trigger, the branch, 3 agent calls and 3 comments. The Usage tab billed 5 steps. On the six rules whose numbers had caught up, billed steps were exactly the audit count minus the agent calls. If you budget steps from the audit log, as we suggested in our automation steps tutorial, take one off for each agent call.

Next to credits, steps are a rounding error. Trigger plus comment is 2 steps a run, and at $0.50 per 1,000 steps that's a tenth of a cent. The agent call in the same run is 10 cents once you're over the pool.

Jira Rovo agent cost per seat at 50, 200 and 500 seats

A typical first rule has an agent triage each new work item and post a comment. Its monthly cost is one formula:

rule's overage = min(rule credits, max(0, what the org already uses + rule credits - pool))
cost a month   = rule's overage x $0.01
rule credits  = new work items a month x agent calls per item x 10

My assumptions: 10 credits per call (what we measured on Quick answers), one call per work item, and the Jira-only pool of 25 credits a seat on Standard or 70 on Premium. The Jira + Confluence column assumes each Jira seat also has a Confluence Standard seat, so 50 credits a seat. For new work items per seat, count last month's new work items and divide by your Jira seats. In Jira search the JQL is created >= startOfMonth(-1) AND created < startOfMonth(), with project in (...) added if your rule only covers some projects. If you'd rather script it, Jira's approximate-count endpoint takes the same JQL (use an API token):

curl -s -u "$EMAIL:$API_TOKEN" -X POST \
  -H 'Content-Type: application/json' \
  https://your-site.atlassian.net/rest/api/3/search/approximate-count \
  -d '{"jql":"created >= startOfMonth(-1) AND created < startOfMonth()"}'

You should see one number. It only counts work items your account can browse, and a wrong or missing token prints {"count":0} without an error, so check the token if you get 0. Ours, run on 23 October for September:

{"count":14398}

That's high because our test tools create work items by the thousand. A real team of 200 raising ten each would show about 2,000.

Cost per seat a month, by new work items per seat:

New items per seat	Jira Standard, pool unused	Jira Premium, pool unused	Jira + Confluence Standard, pool unused	Pool already spent, any plan
2	$0.00	$0.00	$0.00	$0.20
5	$0.25	$0.00	$0.00	$0.50
10	$0.75	$0.30	$0.50	$1.00
20	$1.75	$1.30	$1.50	$2.00

Company size doesn't change the per-seat figure. It only multiplies it. At 10 new items per seat on Standard, with the pool otherwise unused, that's $37.50 a month at 50 seats, $150 at 200 and $375 at 500. With the pool already spent it's $50, $200 and $500. Steps barely register: 20 a seat a month against 400 on Standard.

Which column is yours? I'd set the Rovo credits Users tab on Last 30 days, add up what your org used, and compare it with Allowance on the Usage tab. The gap is your buffer. It absorbs a new rule before billing starts. If last month's use already sits near the allowance, budget from the last column.

Two kinds of rule cost more than a seat count suggests, because they grow with work items:

A branch over related items. Our 3 sub-tasks cost 30. A parent with 25 sub-tasks would cost 250 credits, $2.50 a run over the pool, at the same per-call price. We only tested 3.
A scheduled sweep. A rule that asks an agent about 20 open items once each weekday is 440 calls a month over 22 weekdays: 4,400 credits, or $44 once you're over the pool. Make it hourly over an eight-hour day and it's 35,200 credits, $352. With a Sonnet 4.6 agent at 13 credits the daily version is $57.20.

Choose the model and the reasoning tier on the agent, not the rule

We duplicated Bug Report Assistant twice in Rovo Studio. One copy got Think deeper on the Default model, which the picker showed as Gemini 3.5 Flash. The other got Think deeper with Claude Sonnet 4.6. Same prompt, same kind of work item.

The Default-model copy cost 10 and the Sonnet copy cost 13, in both of its runs. So on our short triage task (about 120 words of answer) the premium model added 30%. I'd honestly half expected a multiple. Atlassian's rate card puts these agents under "Variable credits per billable event", and for Think deeper it names reasoning steps, search volume, tools invoked and model power as what moves the price. We didn't try Opus-class models or long multi-tool tasks. That's where I think the bigger numbers will be.

Atlassian's reasoning-tier doc carries a warning worth taking literally for automation: "If you're setting up autonomous or high-volume agents, carefully consider which reasoning tier is most appropriate for your task. These tasks can quickly consume credits." Because the setting lives on the agent, whoever edits a shared agent in Rovo Studio reprices the rules that call it, and nothing in the rule's builder shows that.

Put the condition before the agent

Our copy of Atlassian's template checks the issue type before it calls the agent, and a Task stopped there for 2 steps and 0 credits. If your rule calls the agent first and decides afterwards whether to use the answer, you pay 10 credits for each work item it looks at.

Scheduled rules work the same way. Our sweep matched 2 work items and paid for 2 calls. Twice the matches, twice the bill.

What we didn't measure

No agent call failed or timed out for us. So we can't tell you whether one is billed. None of the Atlassian pages or tracker tickets we read say either. Our agents never used write tools in a run, so an agent that edits work items may cost more than one that only answers. Each rule ran once or twice. Repeats never differed, but it's a small sample.

We also didn't run a rule into an empty pool. Atlassian's Rovo plans FAQ says that with extra usage off, "new credit-consuming AI features and enriched Teamwork Graph API and tool calls are paused until the allowance resets next month", and that an "Agent task" already in progress "will complete". What a Use agent step does at that moment (skip, fail or post an empty comment) is something we haven't seen.

The Usage tab has a Rovo credits column per flow, which helps you find the expensive rule. On our site it read 90 when the meter had moved 156, so check it again the next day before you act on it.

If your screens don't match

If there's no Rovo AI Agents category in Templates, or Use agent is missing from the action list, an admin may have turned off agents in automation, or your plan may not include Rovo. If the meter doesn't move after a run, check the audit log first: a run that stopped before the agent costs nothing. And if Allowance used jumps by more than your rule should cost, someone else is using Rovo at the same time, so repeat the quiet check.

What you have now

[[takeaways]]

A per-call price from our test site: 10 Rovo credits on Quick answers, 13 with Claude Sonnet 4.6, and no automation step for the agent.
A ten-minute way to measure your own rule from Allowance used and the audit log.
A formula and a per-seat table for a triage rule: $0.30 to $0.75 a seat a month at 10 new items per seat when the pool has room, $1.00 when it's spent.
What it doesn't cover: failed agent calls, agents that write, Opus-class models, or a rule running into an empty pool.

My recommendation before 3 December: list the rules with a Use agent step and move each condition in front of the agent. Then find the busiest one in the audit log, multiply its runs last month by its agent calls per run and by 10, and put that next to your Monthly average and Allowance. If the total goes over, set a monthly cap on Rovo credits so a busy sweep stops at a number you chose.

Have you got a rule that calls an agent on each new work item? I'd love to hear what it costs on your site, especially if it runs a Think deeper agent on a bigger model than ours.

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.