How to trigger based on previous automation routine executions

[Nick Jennings]

I am creating automation rules based on preventive maintenance (PM) schedules for my team. One type of our systems receives quarterly PM tasks performed to it every three (3) months and a more-involved annual PM task performed to it every twelve (12) months. This essentially amounts to the first three PM tasks performed are quarterly PMs, while every fourth PM is the more-involved annual PM.

Creating an automation routine for the quarterly PM has been quite simplistic: triggered by an issue transitioning to a 'Done' status, and meeting other conditions, a new issue is created with the due date set for {{now.plusMonths(3)}}. This allows for the next-scheduled quarterly PM to regularly be created every 3 months from the completion of the previous PM.

My thought-process on handling the annual PM scheduling is to trigger a similar automation routine, albeit with the additional information required for the annual PM, every 4th time the aforementioned automation routine is executed.

I am having trouble realizing this thought as an actual automation routine. Is my thinking flawed and a better solution exists?

TLDR; I want to modify the actions of an automation routine every n time it is executed to perform slightly different actions.

[Bill Sheboy]

Hi @Nick Jennings -- Welcome to the Atlassian Community!

I can think of a few ways to solve this, and the simplest may be to turn this problem inside-out: create an annually scheduled rule which creates all the PM tasks at one time, quarterly and annual.  You do not state why you are waiting for issue transition to create the tasks, so if that is not a limit, perhaps try the annual schedule rule.

If that will not work, two other approaches are:

• Pick a starting point (specific date) for your annual cycle, which will determine when quarters and annual PM tasks happen.  Then perform a date difference calculation for the rule decide whether to create a quarterly or annual task.
• Another approach is entity properties: set an entity property in the project for your counter, updating it as needed.  You will need to call the REST API to get the value for checking on the time for quarterly versus annual tasks.

Kind regards,
Bill

[Darryl Lee]

I was thinking about entity properties (probably at the project level?) too, @Bill Sheboy but thankfully you don't need to use the REST API to get at those (unless you need to use a Smart value to "lookup" a particular property).

Here's how to set them:

https://support.atlassian.com/jira-software-cloud/docs/automation-actions/#Automationactions-Setentityproperty

Documentation is poor on how to access them. For a project, Smart values should work like this:

{{project.properties.pmtaskcounter1}}

Bill and I discussed this previously here: https://community.atlassian.com/t5/Jira-Core-Server-questions/How-do-I-access-a-User-entity-s-properties-set-via-API/qaq-p/92490

[Bill Sheboy]

Thanks for the reminder, Darryl.

__Bill

[Nick Jennings]

Thanks for the replies, @Bill Sheboy @Darryl Lee ,

I am not familiar with entity properties. I see an action in the Jira Automation creator to set one at either project/issue/user levels and that you've suggested I set one at the project level. Is this something that auto-increments at execution of the automation routine setting it? I will look through the documentation to come up to speed on your suggestion.

To answer Bill's question above, The date a PM may be performed and completed for a given system may differ from the issue's set due date based on external factors, such as the system being in-use for a higher-priority task or access to the system not being feasible within the scheduled timeframe. It's not uncommon to either delay or even perform the PM ahead of schedule to accommodate for these external factors. Due to this somewhat dynamic nature, I've opted to schedule the next occurrence of the PM based on the known completion date of the previous PM, as opposed to setting static dates throughout the year.

The intent of automating the creation and scheduling of each issue at the completion of the triggering issue is to use the triggering issue's resolved date to calculate the created issue's due date (3 months from the previously-performed PM). The created issue is then used as both a placeholder for logging any correspondence between the assignee and stakeholder(s) and any work performed for that particular effort, and a way to notify the assignee of an upcoming PM for a given system. That notification prompts the assignee to take action in contacting that system's stakeholder(s) to perform the PM prior to or by that predetermined due date (or to reschedule, if a PM task is not presently feasible).

I was giving some more thought to the issue and I'm thinking the automation routine would have to resemble something like the workflow below; which may be more simplified than counting every 4th execution of an automation routine. Where the initially-created, triggering issue can be labeled as an Annual, upon completion, the created issue is labeled as a Quarterly with the {{now.plusMonths(3)}} due date assignment. Upon completion of an issue labeled as Quarterly, a conditional statement will check when the last issue labeled Annual was resolved. If greater than or equal to 9 months, then the next created issue is one labeled Annual. If less than or equal to 9 months, then another issue labeled Quarterly with the {{now.plusMonths(3)}} due date assignment is created. As I'm new to Jira automation, what's the cleanest way to locate the most-recent resolved issue featuring a specific label and compare it to a timeframe, such as 273 days?

[Darryl Lee]

Hi, sorry here's some documentation on entity properties: https://developer.atlassian.com/cloud/jira/platform/jira-entity-properties/

Basically it's a way to persist values outside of Automation. They don't auto-increment.

Your rule would need to do that. So like every time it ran, it would have to grab the value, check if it's 4, and if so, do the extra steps for the fourth PM and reset it to 1, else, increment the value by 1.

You could do that by setting the same entity property to:

{{project.properties.pmtaskcounter1.plus(1)}}

[Bill Sheboy]

Hi, Nick.  Thanks for your explanation and additional details!

I like the simplicity of your idea to use labels/a custom field as the indicator for the quarterly/annual maintenance switch.  The pros are simplicity and visibility (e.g. Q1, Q2, Q3, Annual), but the con is possible tampering with issue edits.  That can be mitigated with another rule and team conversation (e.g. "don't touch this, please" :^)

The converse pro/cons exist for using entity properties: less tampering chance, but less visibility to users who cannot find the entity property.  That visibility is a double-edged sword: people may not see it to tamper, but if someone does tamper you (and the rule) may not see it before an impact.