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

Workflow Perform action overwrites user choices for the resolution field

Bernhard Willert

We have a transition Any -> Done in our workflow, which is also used by an external tool to close specific task issues via API (those issues that the tool also created in the first place).

We noticed that tickets closed via the API did not contain a set resolution leading to some issues, so we tried to follow the best practice guide: https://support.atlassian.com/jira/kb/best-practices-on-using-the-resolution-field-in-jira-cloud/

There was already a screen assigned to this transition and when manually finishing an issue this screen enforces a set resolution, so far so good.
In addition, we added a Perform actions rule intended for the API usecase. This rule does the following:

Rule: Update a work item field
Update this field: Resolution
The value will be set to done

This works fine for the API-based closure of tasks, but when we close an issue manually, no matter what is selected in the screen, the resolution is now also always done. The perform action seems to overwrite the user choice.

Is there a way to configure the workflow to apply a default resolution value, only if none is set? Or to differentiate between API-triggered transition and manual UI-triggered ones? Is the KB article outdated, since it also mentions post-actions which seem to have been at least renamed to Perform action rules?

Accepted answers

John Funk

Hi Bernhard - Welcome to the Atlassian Community!

I don't think you will be able to accomplish what you want to do with a single Transition. You can leave the All going to Done and use the API.

Then you can create additional Transitions from the other Statuses to Done and use the screen. Not sure how many other Statuses you have that could go straight to Done so that might be too much.

The other option would be to create another Status for Completed or something like that. Add the ALL to it and use the Screen.

All comments

Gunjan Kumar_xl3r1p

Hi Bernard, Welcome to the Atlassian Community!

This is expected behavior.

Automation “Perform / Update field” actions always run after the transition and do not differentiate between API and manual UI transitions. Therefore, the rule always sets Resolution to Done and overwrites any value chosen on the transition screen.

Atlassian recommends setting Resolution using a workflow post function, not automation:

https://support.atlassian.com/jira/kb/best-practices-on-using-the-resolution-field-in-jira-cloud

Recommended options:

Move the Resolution update to a workflow post function on the Done transition, or
Add an automation condition: Resolution is EMPTY → then set Resolution, or
Use a transition screen with the Resolution field for manual closures.

Automation actions reference:

https://support.atlassian.com/cloud-automation/docs/jira-automation-actions

John Funk

Hi Bernhard - Welcome to the Atlassian Community!

I don't think you will be able to accomplish what you want to do with a single Transition. You can leave the All going to Done and use the API.

Then you can create additional Transitions from the other Statuses to Done and use the screen. Not sure how many other Statuses you have that could go straight to Done so that might be too much.

The other option would be to create another Status for Completed or something like that. Add the ALL to it and use the Screen.

Duc Thang TRAN

Hello @Bernhard Willert

1 For your information, in the new workflow editor interface, post-functions have indeed been renamed to Perform actions. You can select “Update a work item field”, then choose the Resolution field and the value you want to set.

2 However, if you deploy this, the resolution selected on the transition screen will no longer be useful, since the post-function will override it and force the value defined in your rule.

3 Could you please share the JSON payload used by your API to close the ticket? Otherwise, here is an example you can refer to

{

"transition": {

"id": "31"

"fields": {

"resolution": {

"id": "10205"

}

Hope this can help

Bernhard Willert

Hi Gunjan,

yes that's the same KB article I also linked. It seems like the options listed there are "either or", if I add an action to the workflow transition as well as a screen, the function will overrule the choice on the screen.

I tried an automation as an alternative, but this rapidly consumes our automation budget.

Bernhard Willert

It seems like the tool only sends the transition and no further fields like resolution. Is the resolution id something fixed or how can I determine the IDs of our resolutions?

Bernhard Willert

Hi John,

thanks for the welcome!
Yes, seems like the options in the KB article are "either or" and not meant to be used at the same time.

Can I use individual transitions like "In Progress" -> "Done" in addition to "Any" -> "Done"? Which one would take precedence when I change a state manually?

A dedicated end status for the automated flow or a dedicated issue type might be a good solution. At least I can configure which transition is used by the external tool to close a ticket.

John Funk

Yes, you can use both the individual transitions. One doesn't really take precedent over the other as both would appear to the user. So in that case, I usually add conditions to one or the other transitions so the user only sees one. So if you are using a dedicated issue type, then you would just add that to the appropriate transition as a Rule. That would be your best solution I think.

Bernhard Willert

Thanks John, I'll try that

Duc Thang TRAN

@Bernhard Willert

Yes, the resolution ID depends on your instance configuration , the same applies to the transition ID. I assume you’re familiar with transition IDs since you’re working with the REST API
if not, you can ask a Jira admin to retrieve this information

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud