Manual automation context

[Randy O_Neal]

I have a small Jira automation to simply modify labels under certain conditions.  I have verified that it works and does what I'm wanting it to do.  But my experience has seemed to indicate that when I manually launch an automation, it seems to only run for the context of the issue from within which I launch the automation.

For example, I have a manual automation to delete purged subtasks... we use it all the time to delete purged subtasks when not needed.  It's been my experience, however, that running that manual automation only runs in the context of that issue; if I have 2 issues - both of which have purged subtasks - my manual automation will only delete the purged subtasks within the issue where I launched the automation; the other issue containing purged subtasks will still have them following the execution of the automation.

Since I need to manually launch some automations (triggered by process, not by a Jira event), I need the automation to run for all issues meeting the criteria specified in the automation, not just the issue where I launch it.  Is this possible?  Is there another location from which I can launch the automation so that the context is the entire project, not a specific issue?  Am I doing something wrong?  Any intel would be greatly appreciated - many thanks in advance!

[Anne Saunders · Accepted solution]

It seems like Atlassian's intent for the Manual trigger for automation rules is more about testing than about actually kicking off a larger process by hand. You're correct that a manually triggered rule will only run on the issue you run it from. 

Without knowing more about your use case, it's tough for me to suggest a good option, but you might do well with a scheduled automation that runs on the (for instance) 5th Saturday of every 12th month. 

I use this kind of scheduled automation to create recurring issues on a weekly, monthly, or other basis. but a nice feature of this kind of scheduling is that it also gives you the option to run the rule (globally or in a single project) manually from the Automation itself. 

It sounds like you could maybe just use the scheduled automation, though, assuming you can use JQL to identify your "purged" Sub-tasks. 

[Randy O_Neal]

Thanks, Anne... I suspected as much.  I may be able to use some sort of schedule to do what I need to do... still noodling on that.  My other option is to simply use JQL to bring 'em up and bulk edit them... was trying to leverage automation, but I guess you can't have everything.

Appreciate the help!

Randy

[Anne Saunders]

If you set up the schedule, you can run it ad hoc from the automation itself (kinda like a bulk manual automation) whenever you want. (Assuming it won't hurt anything if it runs once a year or something as scheduled).

[Bill Sheboy]

Hi @Randy O_Neal 

You are correct that the Manual trigger's context is the issue from which the rule is run.  That is all the rule "knows" about.  There is no mechanism to select "input conditions" for a rule, or to multiple-select issues and then "run rule on these issues".

Yes, and...when you need more context for the rule (e.g. other issues to process) there are several options, including at least these:

• Let's assume the issue from where the rule is manually triggered links to others (or associated via custom field information).  The rule can use that information to branch to the relevant issues for processing.
• Let's assume the issues to process always meet some defined criteria, allowing them to be found with a JQL statement.  The rule could ignore the manually triggered issue, and instead branch on the JQL for processing.
• Let's assume an external process/tool event happens.  You might be able to use the web hook trigger to listen for that event, and process issues accordingly.
• Or, use another trigger which better matches your use case

Kind regards,
Bill

[Randy O_Neal]

I found this: https://community.atlassian.com/t5/Jira-Software-questions/Run-Automation-Manually-on-All-Issues-in-a-Sprint/qaq-p/1735115

Was hoping for a less kludgy solution...