Maybe this is a bit of an unusual use-case, but here I go anyway:
I have a task with a number of subtasks underneath it. The subtasks Summary field is the name of one of the statuses of the Parent, eg: Subtask Summary = "In Progress"
Through an automation on the subtask, I would like it to transition the parent to the status corresponding to the name of the subtask.
But when I do this, I get an error: "Destination status could not be resolved. If using a smart-value ensure this resolves to a numeric status ID or untranslated name for issues (with current status)"
I've looked at the documentation, online and in the community but haven't found the answer.
Here's the JIra records, automation and error.
Other than as an experiment, I am unclear what problem you are trying to solve by doing this. Would you please explain? Thanks!
Regardless of the "why", I suspect you need to use the Status Id value when performing a transition with a smart value. Two possible options are:
Thanks for your quick replies.
In terms of the "why", I am using Jira Automation for Business Process Automation.
Imagine I have a business process with a number of steps and those steps can occur at different times and sequences, eg: 1 week after Task A is done, then Task B can start. And each step is a status in the workflow of the parent.
I have an automation that is checking the subtasks to work out when a step in the process needs to happen. And when it picks up that Task B needs to start, then it updates the status on the parent to the status that is the Summary of the subtask. And when that status changes, it then kicks off another automation to do whatever is required for that step.
You are probably wondering why I would want to change the status based on the subtasks and it's adding a lot of unnecessary complexity. What it means is you can change the dates on the subtasks, meaning you don't have to hardcode dates and time periods in the automation - it just looks at the dates on the subtasks. You can even show it visually as a timeline.
One way I have got this to work is to set the status I want on the subtask itself, and then just copy the status from the subtask to the parent. I would prefer that the status of the subtask represents whether it is To Do, In Progress or Done.
So I suspect that I can't use a string to refer to a status. I did try the Status ID value, but I got the same error. If it would be great if I can get it to work with a string as it would make the most sense, not haven't to mess around with ID's.
Here's another thought, can I programmatically determine what the ID is for a given status?
Thanks so much!
FYI that I tried your use case with the status Id and it worked for me. To make it work I did the following:
The key is where do you get the status Id for the subtask? You could:
Hi @Bill Sheboy
Thanks again for your suggestions and have got it working using the ID - the key was making sure it is converted to a number.
I'm now wrestling with the REST API technique - thanks for the links. I'm a bit of a novice with REST API's but am learning quickly (although not as quickly as I would hope).
What's blocking me at the moment is
I have confirmed that https://XXXXXX.atlassian.net/rest/api/3/status does provide JSON with the status - I can show them in a browser using that URL. But in the automation, it doesn't want to step through each of the statuses.
Here's my test automation and the web request
And the branch:
In the audio log, I just displayed some simple text. But it's not showing any log entries after running the automation. This is telling me that it's not branching.
Hi @Bill Sheboy
Once I followed this and encoded the token, it started to magically work.....
So thanks again (and thanks to Asim) for your suggestions.
Hey @Bill Sheboy
While I've got you here, do you have any suggestions in terms of dealing with the non-deterministic nature of Jira Automation? It's really hard when there are a number of steps that need to occur in a certain order, ie: a step is dependent on something that is done in the previous step. I've seen a few discussions in the community and you have commented on a number of them.
It's really important as I need the automation to be robust and allow for situations when the data is not as expected, so there need to be a number of checks that take place with different actions.
This is a challenging issue, and may be better addressed by watching for a few things:
First thing: consider divide-and-conquer when possible, If a single issue is the context for a rule it is more likely everything will happen as you expect and in the order you expect. One way to do this is having one rule mark other issues (like a semaphore flag/value in a comment) to indicate processing-needed and then have a second rule for the decentralized processing.
Next, watch for rule components which lead to asynchronous execution: web requests, and any branches which could lead to more than one issue. Web requests have a "wait until I'm done" setting, but it apparently has some problems when done inside of an if/else component. For branches there is a suggestion to add something similar, but for now only the one-and-only-one issue branch types get converted to in-line processing (per some Atlassian posts).
Thanks @Bill Sheboy for the tips.
I've raised a ticket with Atlassian to get more clarity on this. Jira automation is promoted as a no-code, drag-and-drop solution that anyone should be able to use. But these issues with it are going to confuse and frustrate users when it doesn't work as they would expect.
I'll let you know how it goes.
Hey @Bill Sheboy
I've asked this as a separate post, but it relates to what I have been discussing and gives the context of my question, so am repeating it here.
I've got a number of automations that are triggering off data changes but also triggering other automation to update the data. I'm now starting to hit the limit for the number of loops, which is set at 10. These limits are described here, and the one relating to loops states "This controls how many times a rule can trigger itself (or other rules) in quick succession before the execution is stopped and marked as a LOOP."
So I'm using the "divide and conquer" approach to deal with the issues I mentioned previously, but this contributes to the number of loops, meaning I'm hitting the limit.
Anyway, any tips on dealing with reducing the number of loops.
Wow, that's a lotta loops if you are hitting that limit. And, it could mean that some of your intended executions will not fire (and so be lost due to loop detection).
I am curious: what is your use case/problem you are solving, which is causing this symptom? For example, is it a lot of data and batch processing?
Have you thought about how to reframe the problem with a tree-solution of rules? This may distribute the load so you do not hit the limit.
Hi, Jira users! Do you use Jira alongside Microsoft Teams? We want to hear how you’ve used the power of Jira Cloud and Microsoft Teams (via the Jira Cloud for Microsoft Teams app) to achieve a team...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events