Bill Sheboy Expert

When mapping a range of numeric values to a lookup table, each value would need to be provided as a key. For such cases, a conditional / logical expression with math tests may be better. For example, assuming the custom field is a number type: {{#if(and(issue.myCustomField.ge(0),…

Adding your comments from the duplicate question created: The problem I am trying to solve by merging the rules is they don't seem to work when the two separate rules are turned on at the same time. They work individually. So i thought that combining them would be best, turns out that isn't so great either. Basically our…

Hi @Holly Hammond Here is your original question link. Let's try to stay with that one for continuity. Thanks! https://community.atlassian.com/forums/Jira-questions/Combining-Automations/qaq-p/2978010 Kind regards, Bill

Hi @Ravindra Mehta -- Welcome to the Atlassian Community! Short answer: As you have described the scenario, that is not easily possible. Labels are case-sensitive. If you have a work item (formerly called "issues") with an existing label with lowercase characters and want that to be uppercase a new label must be created /…

Hi @Vishnu Jeevaji -- Welcome to the Atlassian Community! Jira helps teams to track the work needed to deliver value / features. And it is not typically used to track the typical sprint events: backlog refinement, sprint planning, daily scrum (i.e., standup), sprint review, and sprint retrospective. Doing this is a symptom…

Hi @Akira Nakayama -- Welcome to the Atlassian Community! Yes, that is possible using an automation rule. The rule outline would be: * trigger: scheduled, with your selected cadence * action: create issue To learn more, please see this documentation for Jira Cloud:…

Hi @MW -- Welcome to the Atlassian Community! Please use this how-to article to identify the custom field ID for the field: https://confluence.atlassian.com/automation/find-the-smart-value-for-a-field-993924665.html This will also confirm if the field is supported by automation rules. Kind regards, Bill

No; my suggestion was to use Lookup Issues and JQL in place of the original branch on linked issues. With that result, their subtasks may be found for each issue. Then combine those key lists into a single list of keys which may be searched with a JQL branch to finally update the date fields. If I have misunderstood your…

I recommend against hardcoding as that could lead to maintenance and other errors. Please try that last approach I suggested as it will allow the updates to happen within one rule, reducing the chance of errors.

Thank you for the additional information. When using the "add" operation for the field, there can only be one value in the JSON, not a list of values. That is why the iteration technique I noted is required to include an "add" expression for each one. If instead you want to "set" the value to replace all of the values in…

That value appears to be static text, and not variable like an issue key. Do you mean the Description will contain #CKV# rather than the key and then that value will be used somehow to identify the correct issue?

Hi @Julian Beardman -- Welcome to the Atlassian Community! First thing: Scenarios like this are quite challenging for automation because of the possibility of errors or missing some cases. And when implemented incorrectly, they can cause runaway rule execution and halt all automation processing. And so, what problem are…

That expression may be used with the Create Variable action near the beginning of your rule: https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Create-variable With that, the resulting smart value could be used as the parent key. For example, if the name used in the variable action was…

Hi, community! For those who want to understand what Dr. Winston Royce actually stated in his paper, including ideas around iterative and incremental practices, please consider reading the entire thing and the later writings on the topic where others only referenced content from the beginning of the paper, without noting…

Yes, and... First thing: I would not recommend automatically tracking / logging time this way. It assumes two things that may not be valid: people correctly transition issues as-soon-as work starts / stops, and logging calendar / clock time is what is desired (rather than actual working time). And, you are correct…

Hi @Diogo Rodrigues For a question like this, context is important for the community to help. Please post the following: * an image of your complete automation rule in a single image for continuity * images of any relevant actions / conditions / branches * an image of the audit log details showing the rule execution Until…

Hi @Philip Ng Well done solving your own question! And...have you tried using Lookup Tables to solve scenarios like this: https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Create-lookup-table It will make the rule shorter and often easier to maintain. For example, your rule could be reduced to: *…

Hi @Duval, Stéphanie -- Welcome to the Atlassian Community! Rather than using the Link Issue action, you can add the link at the same time the sub-task is created: * delete your Link Issue action * in the Create Issue action, select the Linked Issues field from the dropdown * select your link type and the trigger issue…

After creating the new Epic, the branch should be to Most recently created issue rather than to Current issue. Please try that and re-test.

Yes, that is one way to do it: * advanced branch:* smart value: {{issue.description.split(":")}} * name: varItem And inside the branch, reference the item as {{varItem}} Please note well: this assumes there is at least a non-empty Description field with a colon ":" delimiter and no newlines in the field. * When no data is…

Your Jira Site Admin should know the answer if the site was converted in the past. I recall other posts where converted users had some challenges in automation rules when the original site was in Data Center and moved to Cloud. At this point, I recommend working with your admin to create a ticket with Atlassian Support to…

This is how branches are designed to work, and so creating a "defect" may not help. The likely response from Atlassian Support would be: the rule is repeatedly trying to update the same issue's field in a short window of time, and so is colliding with its own updates. Essentially: the last one to process will win. Here is…

One of the challenges of re-building something that should already work in rules is our workarounds tend to be "brittle" and challenging to test. Oh well...let's try again :^) Please see my earlier post as I recreated the variables to handle the different cases, and account for the possibility a changelog's {{fromString}}…

Also, does your manual trigger have User Inputs? It does not appear to do so in the rule image, but there is an open suggestion / defect that when user input is too long for a field that error is shown: https://jira.atlassian.com/browse/AUTO-1543

Hi @Marco Affuso -- Welcome to the Atlassian Community! For which rule step did you see that error, or was it shown in the UX when manually running the rule from an issue? Also, it may provide context to post an image of the audit log details showing the rule execution (with all of the details at the right side of the log…

Hi @chadunbehaun Created variables are always text type. And when you split() the Description field, the result is the rows variable gets this: * first the Description is split into a list of text values: [1, 2, 3, 4] * and because it is then stored in text, it implicitly performs a join(", ") * with a result of: 1, 2, 3,…

Please post an image of your entire rule in a single image for context. Thank you! And something you describe puzzles me: normally Jira email handlers create an issue from the email. Do you instead have a rule triggered on Issue Created which is attempting to modify the issue? Back to the scope of your original question,…

First, when asking for automation help please post images in your question of your actual rule and audit log details showing the rule execution. Providing the exported rule JSON only helps in limited cases. Fortunately, I am in the process of writing my own compiler for Jira automation rules and so am quite familiar with…

Did you enable the option "Process all issues produced by this trigger in bulk"? When you do that, the plural {{issues}} smart value will work. Please see the documentation link I provided. Also, the {{lookupIssues}} smart value only works after first using the Lookup Issues action. That does not appear to be needed for…

When you review the audit log, how many times is the rule triggering when you change the field: one time or multiple times? If it is multiple times, have you confirm you are not exiting the field and so making it an edit for each change?