Simmo Atlassian Team

Hi @Allison Stewart, A few things to check first. Are you a participant on the issue? Or are you in an organisation in that service desk? If so, Automation might be thinking that you're a customer as well. You can probably easily setup a sample rule to test if that check is treating you as a customer? If not, or you're…

Hi @A.J. Apple, That selector can be a little funny and I'm not sure that it was designed to work with both project types. Having said that, for the Service Management Projects drop down can you choose Internal and then choose Share with customer again? And leave the Software and Business projects alone? Save it and then…

Hi @Anthony Soller, You can use smart values to get both: {{issue.Epic.key}} {{issue.Epic.self}} The first will return the epic key (you can also do .name) and the second returns a link to the epic. Cheers, Simeon.

Hi @Sergiy Yermak, Is Issue B created from a rule that is triggered by some event from Issue A? If so, you should be able to do this: This is my example multi select field. By using the ... menu I have put it into copy mode and told it that when it creates the issue it should copy the values for that field from the issue…

Hi @Allie Nelson, I'm afraid that the reason why this isn't working is due to there being a one to many relationship between an issue and sprints. An issue can have multiple sprints, so that field Sprint is a list type. There's some good available…

@Quinn Moffat Apologies that you've run into this, we really need to rename these actions as it is a bit deceptive. They should be called issue deployed successfully. The trigger runs once for each issue in a deployment. This is why you are seeing this behaviour. Cheers, Simeon.

Hi @Gareth Blake-Coggins, We don't have any Automation integration with Essential Accessibility so at first glance it sounds like web hooks would be the right vehicle for what you are wanting to achieve. Is it a case of send a webhook and then lookup the issue and apply a label? Cheers, Simeon

@Mary Mascari, If I'm understanding you correctly then it all depends on where you click as to where the component ends up. Hopefully this image will help: Cheers, Simeon. 

Hi @Sravan Duddella @Bill Sheboy is right on the money here! The related issues condition is the one he mentioned as well. You'd do something like this after you've branched: Cheers, Simeon

Hey @John Funk Doing well mate! The teams been growing so we are sharing around the community responsibilities. I'll pass your hello on to John when I see him next! Good to see you're still about mate. Take care!

Hi @Denny Pujo, An interesting one this one! So, the reason that it isn't working is that I think when the smart value doesn't match you get an empty string as one of the addresses and that doesn't go down well. What I think you could do is to use the Create Variable action to get a smart value and then use that smart…

Hi @Alex Shirokov, My buddy @John Funk has given you a nice and easy solution. If it you wanted to try and get fancy with smart values you could also try using the conditional logic that they offer. More of that at https://support.atlassian.com/cloud-automation/docs/jira-smart-values-conditional-logic/ Cheers, Simeon. 

Hi @Anthony Soller, Are you wanting to get a link or the name of the epic via smart values? Cheers, Simeon.

Hey @Darryl Lee, I can tell you that there aren't too many hops. We're within the Atlassian private network :)

Hi @Denis Collumbien, could you expand a little on your question? Is the epic moving when the status of one of its issues changes? 

Hi @nik_shivamprajapati, There is no out of the box solution to telling the difference here. From an Automation point of view, the requests look the same. You'll need to come up with something along the lines of what @Mark Segall has suggested. Cheers, Simeon.

Hey @Gaurav Dhuppar Is there any chance you can raise a support ticket? These things are really hard to debug without seeing what is going on and thats lots of screenshots. But to answer your question, we need to have a look at what issues are triggering this rule and redesign your rule. The loop is happening because the…

Hi @Gaurav Dhuppar, The loop detection limit cannot be changed. As @Mark Segall pointed out, if you're hitting that then it is a sign that you need to restructure your rule. Can you provide a screenshot of how you have configured your rule? Cheers, Simeon.

Hi @Peter Reiser, Can you raise a support request for this? It needs to be looked at in greater depth and possibly looking at your site data. Cheers, Simeon. 

Hi @Peter Reiser and @Stefan Salzl, Right now there isn't a way to filter down the smart value: {{issue.issuelinks.inwardIssue.CUSTOM_FIELD}} To just one of the issue links. @Stefan Salzl suggested looking at the issue linked trigger. If you use this and then filter for your link type you get access to the information that…

What is the issue you're facing, can you provide some examples please?

Hi @Ops Linux, This looks like it should work. Can I suggest you open a support ticket so that we can investigate further? Cheers, Simeon. 

That makes sense. I think you can probably simplify it to: issuekey != {{issue.key}} However, are you trying to refer to the issue that triggered the rule or the issue with the similar description? If it is the one that triggered the rule you should change your smart value to: issuekey != {{triggerIssue.key}}

I'm not sure where you're planning on using it? As a guard?

See my response below. If the rule is running as Automation for Jira then we set the override screen security flag which allows us to edit fields not on the screen. This is only available to connect app users.

Hi @Harmeet Singh I am under the impression that Teams is still in EAP and, as such, isn't supported by Automation yet. Cheers, Simeon.

@Andrea Robbins, there isn't anything in Jira Automation that can ensure this. The best approach are to put the checks into your rules before they do the linking. Automation cannot stop links happening but they can detect duplicates. Your best bet is to solve this by doing a check up front before you link them.

@Dirk Ronsmans is right on the money here, schedule triggers to check is the only way. You can do a scheduled trigger that does a JQL search and then send an email for each result.

Hey @Bill Sheboy and @Brock Jolet, I've raised a bug to track this one, thanks for pointing it out Cheers, Simeon. 

Sorry mate, I mean, you want to have an automation rule that can affect what the Jira UI is presenting?