ARE YOU SURE? Using Inputs with Manual Trigger to confirm actions

[#1]

Recently a user wrote a Python script to add a comment to all issues that met certain criteria in a JQL query. But she wanted to run it as a service account.

It seemed like a more secure approach would be to instead create an Automation Rule that could be manually triggered (by a group with just this user).

The rule was simple enough, but she asked if there could be a confirmation screen because selecting an rule from the Automation menu triggers it immediately. Additionally, the menu does not close, meaning there's a real possibility you could accidentally run the automation twice (which happened to me while testing).

Using the feature to Prompt for input when this rule is triggered allows us to put up a nice confirmation dialogue that allows the user to choose Yes and then Submit.

We get the added benefit that the Automation menu closes when the dialogue appears.

Here's what the rule looks like. Pretty simple, but useful!

[Rune Rasmussen]

I don't know why I haven't thought of this myself but I will absolutely be stealing this idea going forward.
Very nice work.

[Tomislav Tobijas]

Hah yes! We do the same thing when it comes to manual triggers. Started using this method a year or so ago and got positive feedback on the popup/confirmation panel.

[Bill Sheboy]

Hi @Darryl Lee !

Thanks for the article and tip to add more error-proofing to manually triggered rules.

And, as a reminder for the example rule you show...

Rules which supply a work item with the trigger, such as Manually Triggered, automagically exclude that specific work item from branches on JQL.  That is, they add this to the JQL behind the scenes:

AND key != {{triggerIssue.key}}

This is likely another form of error-proofing, built into the engine to prevent accidental endless loops, and is not described in the documentation.

Thus when a customer triggered the rule from a work item they wanted included in the actions, they will not see it processed, may think something went wrong, and run the rule again!  Additional steps are needed to help this case, to individually process the trigger one after first testing it with a JQL condition...perhaps after the JQL branch, or before within a current work item branch.

Kind regards,
Bill