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

"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

1. 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.
2. 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".
3. "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.
4. Accepting the date change alone, then asking for the move, worked first time. Atlassian suggests the same workaround in ROVO-419.
5. 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.
6. 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.

1. 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".
2. 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.
3. 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.
4. 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.