Bill Sheboy Expert

Hi @Firas Abdallah What version of Jira Data Center do you have? With version 9 and later, automation for Jira is included. With earlier versions, I believe it must be installed as an addon from the marketplace. https://marketplace.atlassian.com/apps/1215460/automation-for-jira?hosting=datacenter&tab=overview Kind regards,…

Hi @Anne Farr To use a rule such as @Sanjen Bariki described to copy fields between issues in different projects, the rule must be either global or multi-project in scope. Where is your rule defined? If it is only in one project, the rule scope will need to be changed. Kind regards, Bill

Hi @Mirela Todorova Adding to Murat's answer: You can learn more about answering questions like you have with this free training from Atlassian and documentation on JQL: https://university.atlassian.com/student/path/849533-gain-project-insights-through-jql…

Hi @Sascha Weyers -- Welcome to the Atlassian Community! Using your site admin functions, please review the global automation rules, audit log and usage information. Those will indicate if you have exceeded usage limits or SLAs. The limits / packaging model for automation rules changed on 1 November 2023. Please look here…

In that case, please consider updating your rule like this... * trigger: issue linked * condition: issue type is Requirement or Requirement Interface * action: lookup issues, with JQL for the issues linked to the trigger issue * advanced compare condition: check if the lookup returned any issues* first value:…

Thanks for the update, @Jessica Ketcham I hypothesize this will turn out to be a bad design choice, long-term, and will eventually require an option to enable / disable it. The intent of the backlog is to help manage items which provide value and can be delivered to production. But a sub-task is neither of those things,…

Some adjustments to improve your rule are: * Move the create variable action to after the issue create and before the branch. * Inside of the branch when you create the new child issue, you want the parent to be the new feature, not the trigger issue. Please type in the smart value from the created variable:…

To use the Lookup Issues action, create a JQL statement for the issues you need and used that with the action: https://confluence.atlassian.com/automation/jira-automation-actions-993924834.html The set of issues may be used as a list. It is unclear from your scenario if you need the lookup, but you are using it. And so the…

Thank you for clarifying the scenario. Next thing, I am just another Jira user, and not an employee of Atlassian. With that disclaimer out of the way... Please note those suggestions were created in 2015. I do not believe they will ever be implemented. The idea of the Assignee field seems to be accountability: there is one…

For your scenario, you would would use JQL to find any linked issues of the trigger issue. Once those are found the min or max functions of lists could be used, probably eliminating the need for the branch. One key question: which due date field do you want to update? Is it the one for the trigger issue only?

Hi @Gui Annunciacao Adding to Trudy's answer... I believe some of those advanced roadmap fields are text in automation rules, not date or date/time type. And so to be used in a diff, they must be converted first with toDate {{issue.Target start.toDate.diff(issue.Target end.toDate).weeks}} Kind regards, Bill

That JQL condition appears to have a problem, as it needs to be valid JQL and instead it just has a smart value with a date. What are you trying to test with that one?

Thanks for clarifying... There have been a couple of other questions / posts asking this, and I believe those new release section fields are not available to the public REST API functions yet, and so they are also not available to automation rules.

What value do you want in the Due Date field for the cloned issue? For example, do you want: * what I showed with the Due Date incremented from the trigger issue * incremented from the current date, {{now}} * something else? And does the trigger issue have a value in the Due Date field?

Hi @Bijal Patel 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 community to offer ideas.…

Hi @S For a question like this, please also post an image of the audit log details showing the rule execution. That may help explain what you are observing. Until we see that... Your spreadsheet image showing the use case seems to indicate all child issues should be cancelled for your "else" case. Is that correct, as that…

Hi @Marc Isikoff Did you post your reply in the wrong thread? What you described seems unrelated to the question that was asked quite a while ago. Kind regards, Bill

You could either store that in a created variable, or use the filtered value directly. Here is the Create Variable action for more information: https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Create-variable Variables cannot be used in all of the different rule actions / smart value…

Hi @Gianina Zeballos Are you trying to set the new issue's due date based on the existing one? If so, please try changing that smart value expression to this: {{issue.duedate.plusMonths(3).withDayOfMonth(5)}} Kind regards, Bill

Hi @Syd Heller That is not a built-in capability for Jira Cloud. It may be possible with marketplace addons, and it is definitely possible using an automation rule to call the REST API functions for sprint management. However, some of the reporting in Jira is very picky about sprint contents for starting / completing. And…

Hi @Hristina Devedzhieva What problem are you trying to solve by doing this? For example, to provide earlier visibility of scheduling / participation by different teams, to help teams see with whom they will collaborate, etc. Knowing that may help the community to offer suggestions to better help. In the meantime, have you…

Hi @Abhijit Kulkarni What problem are you trying to solve? Knowing that may help the community to provide better suggestions. Thanks! And...IMHO there are no "best practices", only better and worse ones, depending on what you are trying to accomplish and how the team collaborates. For example, if your team is trying to use…

Hi @Pablo Botas Are you asking: how can the markup in the field be used the Slack message? That may not be possible unless the markup syntax is the same. Automation rules do not have built-in translations to other markups. If the syntax is simple, you could try using the replace() or replaceAll() functions to perform the…

Hi @Anil Katasani -- Welcome to the Atlassian Community! That appears to be a product external to Jira. I recommend working with your Jira Site Admin to contact the vendor Pega for support. Kind regards, Bill

As you note it is an out-of-the-box field and not calculated, I am unclear why it would not be reportable with an issue search. I did a quick search of the public backlog and do not see this symptom noted. You are on a premium license, and so I suggest working with your Jira Site Admin to submit a ticket to Atlassian…

Thanks for the link to the open issue, David. There was a work-around noted for that ticket using created variables, but that may not help for your case while in the iterator (due to the other scoping problem with those).

Hi @Ulrich Kone Your rule is checking the {{lookupIssues}} smart value to evaluate all of the child issues of the Epic, but the rule has not used the Lookup Issues action first to load the issues. Please add that action with the relevant JQL in order to use that smart value. Kind regards, Bill

Thanks for clarifying your scenario. The match function is limited to finding the first thing, and...The advanced branch input needs to be a list, not an array. The details of your scenario seem to be: * when an issue is commented upon only (and not for an issue create) * for 0-to-many expressions found starting with #sub…

Is that a field from Advanced Roadmap? I am not using that tool and so cannot check that. Would you please show an image where you see that field in the UI? If it is a calculated field from Advanced Roadmaps, I would also expect it cannot be reported upon with an issue search.

Do your releases ever contain more than 100 issues? If so, automation rule triggers / actions / branches are limited to 100 items, and so the ones beyond that limit could be causing this symptom. Based on your answer to question #3 about other rules, you seem to be saying this is the only automation rule doing anything…