Bill Sheboy Expert

My understanding is one specific issue type may have one workflow for one specific project. As you are describing different status values (and workflows) for the same work item (perhaps at the same time), I am unclear how team members could know the actual progress of work. There have been other community posts on this…

Although the CHANGED operator cannot be used for other fields, if you have saved a date / time custom field when the field changes, JQL may still be used. For example... project = myProjectName AND myCustomFieldLastUpdated > startOfDay() Where myCustomFieldLastUpdated is the date / time value refreshed by that other rule I…

Please adjust the case to match what I posted earlier, including the default value of 0 when no issues have story point values: {{lookupIssues.Story points.sum|0}} The rule you showed using the Lookup Issues should work correctly to update the epic for the child issues. If it is not, please post an image of the audit log…

Hi @Ben Vere -- Welcome to the Atlassian Community! As this is an older thread, I recommend creating a new question, and perhaps linking back to this one. That will ensure the maximum number of people see it to offer suggestions. Until we see that... I recommend not naming custom fields with the same name as built-in…

Hi @Yash Sheetal Bhandarkar I recommend creating a new question, helping to focus the conversation on the specific problem you are solving. When you create the question, please include: * describe the problem you are trying to solve; that is, "why do this" * what version of Jira you are using, as that impacts the available…

You may use smart value, list filtering to only include the results you need: https://community.atlassian.com/t5/Automation-articles/Filtering-smart-value-lists/ba-p/1827588

You may either: Add an h at the end to set as hours, or Enter the number in the original estimate as seconds and it will convert correctly.

What are the units of measure of your source, custom field: seconds, minutes, etc. My understanding is the built-in, time tracking values, available to rules, are in seconds. When you divided by 60 that gives a value in minutes. And so you could divide by 3600 instead or add a units of measure of h (for hours) at the end…

Hi @Brandon Moberg Yes, diff().businessDays would be a good place to start as there is no diff().businessHours built-in. For your 48h figure, I assume you were initially checking for 2 calendar days of flow time, and not 6 business days (6d x 8h/d = 48h). If you also assume your custom field and now values are never on…

Hi @Fede B. The parsing order can cause symptoms like that. One workaround is to use created variables. For example: * action: create variable* name: varSearchValue * value: some text containing {{ * action: create variable* name: varReplacementValue * value: some replacement text * action: something needing the replace…

Please post an image of the audit log details showing the rule execution and of the issue's change history showing the changes. And, what changes in value do you notice in the Original Estimate field when the rule runs?

Hi @Jacques Dussault First thing I notice is your rule's Edit Issue action is trying to edit the Remaining Estimate field twice: * once by selecting it from the dropdown list * and once in the advanced edit with JSON. Only one of those may be used in a single edit action for the same field. Please try removing that and…

Hi @Lucca Fernandes Short answer: I do not believe that is possible, although many have asked that question. Please look here to learn about usage calculations and limits: https://support.atlassian.com/cloud-automation/docs/how-is-my-usage-calculated/#What-are-my-usage-limits And so to get more automation execution…

Hi @Mathieu Fairfield -- Welcome to the Atlassian Community! Short answer: that may only be partially possible. I recommend describing what problem you are trying to solve (i.e., the "why do this") to help the community offer better suggestions. Until we learn that... There are some fields which work with the JQL CHANGED…

Hi @Sam The smart value in your edit is incorrect. If you want the field from your custom field, use only the trigger issue prefix: {{triggerIssue.yourfield}} Next, the remaining syntax of your field edit is puzzling. What are the name and type of the field in your Story? The syntax you show looks more like a cascading…

Hi @Jesus Octavio Gutierrez Villegas For a question like this, please post an image of your complete automation rule, images of any relevant actions / conditions / branches, an image of the audit log details showing the rule execution, and explain what is not working as expected. Those will provide context for the…

Hi @aperez -- Welcome to the Atlassian Community! I am curious why you would do that for a customer who still has the app installed, and so likely has an understanding it will continue to function. Regardless...I suggest checking the developer community and having a conversation with your Atlassian marketplace contact…

That is correct; to edit an issue with a rule, either the trigger or a branch needs to provide it. If you only want to trigger the rule on that condition, the rule would instead need to trigger on Field Value Changed for Labels, and then add a condition to check the value needed. Note this will operate on only one issue at…

Awesome; I am glad to learn that helped! FYI...I recommended that simple rule approach as you appear to be on the Premium license level, and so have more automation usage executions per month: https://support.atlassian.com/cloud-automation/docs/how-is-my-usage-calculated/#What-are-my-usage-limits And so that rule will…

Hi @ben.flowers -- Welcome to the Atlassian Community! What is the purpose of the additional unique workflow spanning the projects? Until we know that... You could create a Kanban board for a company-managed project, with a filter spanning all of the relevant projects / issue types, and map the different status values to…

Hi @chm That appears to be a known defect, and you may watch / vote for these items to see progress: * https://jira.atlassian.com/browse/AUTO-566 * https://jira.atlassian.com/browse/AUTO-1098 The workaround is to use an advanced edit with JSON to set the field, as described in the second link above. Kind regards, Bill

Hi @Tara Bell To remove the "CLONE - " prefix from the issues, you could use a rule triggered on Issue Created, and the grab the text after that. However...an observant person may remove the prefix when the issue is created, and so try a technique that will only remove() the value when found:…

Hi @agnes BOURLON With the Scheduled Trigger using JQL, the rule is executed for each issue found. When you only want one email for your scenario, you may remove the JQL from the trigger and use that with the lookup instead: * trigger: scheduled, with no JQL * action: lookup issues, use the JQL that was in the trigger *…

Hi @Odilon Nagay The key value in the lookup table must exactly match to work with the get() function. Have you checked if the spacing or case are the same for the displayName values and the keys in the lookup table? You can check that by writing the {{issue.assignee.displayName}} to the audit log to confirm it matches…

Hi @Osama Al-Areky Yes, that is possible, and... First thing, I recommend learning more about writing JQL queries like this. That will help you write and maintain the queries in the future. To learn more about that, please see this free training and documentation from Atlassian: *…

For the rule image you show immediately above this post ^^^ I assume the scheduled trigger uses JQL to find the epics, and the Lookup Issues action then tries to find the child issues of each epic for updates. First, smart values are case-sensitive. Please change the JQL in that Lookup Issues action to this: parent =…

There are several open suggestions to add that option for branching, such as this one: https://jira.atlassian.com/browse/AUTO-32 Although due to the potential to make longer running rules exceed the service limits, it might then halt all rule executions! If you want additional help with alternatives for your more complex…

Hi @Dhiraj Kumar Sinha -- Welcome to the Atlassian Community! Is this a question about automation in Xray or in Jira's built-in automation rules? * If in Xray, I recommend checking the vendor's documentation or contacting their support team * If in Jira's automation, please post images of your complete rule, specifics of…

Hi @Fede B. Yes, that is the expected behavior. Branches which could be on more than one thing / issue are run in parallel and asynchronously, and so any variable created inside the branch is gone by the end. And...there is no guarantee when such branches will complete, up until the last step of the rule. Thus you could…

Yes: as I described it, the rule will trigger and perform no actions when the condition is not met on the parent field.