Have an automation create a ticket, but requiring or prompting with a screen

[Benjamin Peikes]

What we are trying to do is to improve our service desk workflow with "actions" that our agents can take. One action, would be to "Create an analysis ticket". Service Desks "Create Linked Ticket" does not do what we want.

One way to do this is to use a Manual Automation rule, the issue is that there is no way to limit manual automation rules to be available only if certain fields are set in the ticket.

Ideally, there would be a way to create a transition in our workflow, which could bring up a screen, and have an automation rule fire as a post action.

Is there anyway to do this easily?

Originally, one of our thoughts was to have the transition add a label as a post, and then have automation trigger on the addition of the label. The problem is transition post functions cannot add labels (have no idea why).

[Benjamin Peikes · Accepted solution]

Oddly, transition post actions can edit custom tag fields. We created a new custom tag field called "Needs Linked Ticket", which contains tags for the types of tickets that need to be created.

Then we added an automation rule:

• Triggered on editing of Needs Linked Ticket field
• If a certain tag is added, creates a new linked ticket
• Removes the tag from the "Needs Linked Ticket field"

[Daniel Ebers]

Hi @Benjamin Peikes

it depends if you are open to further Apps. I came across a requirement like this in the past where we used Clone Plus - it works really well (inside the same project and even outside the same project).

When opening an issue (for example, let's say Incident) there will be a (freely to named button) inside "More..."-menu which could be like "Create a problem ticket" they there is a screen where details can be filled out, corrected, adjusted, ... but the good portion of data is "copied", or better say cloned, from incident - which is the basic idea to get along quickly.

I know that there might be some special requirements which could, or could not, be met - but it showed a solution which saves (say) 95% of the time proved valuable.

This is not a ready-made-solution (by writing these lines) nor is it a one-click solution but it is not hard to configure, however it will depend if you are willing to pay for a different/additional solution to get some percent more satisfaction and value onto your processes.

Cheers,
Daniel

[Nic Brough -Adaptavist-]

Ok, so your thinking on what Automation is doing is right.  It's a background thing that is triggered, it's not a foreground process with access to the user's UI.  It has no way to pop anything up in front of a person to ask them anything, because it happens after whatever action the person has taken and they've moved on.

Your idea about labelling is one good way to do it though - an automation watching for any action, checking a condition like "labelled with X" and then executing the rest of the actins if there is a match.

The default post-functions are a bit weak, I usually have access to ScriptRunner or something else that can do a bit more, but without them, I think you're stuck on the labelling idea. 

What I have seen done in the past is a dedicated flag custom field.  Not put on screen, but set with a simple "update custom field" post-function.  Automation can then pick that up and look at it for the trigger, but also clear it out when it's done the main work, so it doesn't keep triggering on every edit or transition.

[Benjamin Peikes]

I was afraid someone would say that. There are two items that I'm just completely shocked that Atlassian doesn't support.

Post functions which add/remove labels
Post function, which can run an automation rule. To me this is the most important, because currently you can't trigger an automation rule based on the transition name, only on the from and to states. It's kind of a joke that a company as large as Atlassian, didn't think of this use case, and can't add the functionality in a day or two.