Set approvers via workflow post functions or automation?

[Jeremy Wood]

In JSM, when setting an approver for a ticket and that approver is a static person. Is it best practice to set that approver via a post function on the transition moving into the approval status OR to set it via an automation that is triggered when the ticket transitions to that status?

We are currently using automations but we are overhauling our JSM project so now would be the optimal time to change if i wanted to. 

I kind of want to continue to use automations as i feel like those are easier to maintain than workflows. I also want to make sure that others that come behind me, and our more junior technicians, know where to look for approvers. We still have the need for dynamic approvers (if software = A, set approver A. If software =B set approver B) so if we do set the static approvers in workflows this would mean having to look in two places. 

Although, i do see the appeal of using a post function. It runs faster/sooner then an automation would. It could cut down on our automation counts (we haven't had a problem with the limit yet. But it helps ensures we don't in the future.) Atlassian has had several issues over the last month with automations being delayed and while i know those are not the norm, it would remove that from being a point of failure. 

What does everyone else do? 

[Kris Dewachter]

Hi @Jeremy Wood

Besides the answers already given here, you also have to consider the possibility to re-use workflows. I always try to streamline processes over different Jira spaces. That includes re-using workflows as much as possible. Having a static approver in a workflow, just for 1 spaces, makes that more difficult. That's why I always prefer automation rules in this case.

[Christopher Yen]

Hi @Jeremy Wood 

Unsure which is best practice but personally I do use automations for setting approvers as it's easier for me to manage. It would be good practice have a naming convention and label your automation rules / flows to make it easier to search and understand from the perspective of a junior technician like you mentioned. If you were to use workflows and strictly have all approvals done via workflows then it would be easier for someone else to know exactly where to go to make updates or troubleshoot but in my case we use automations. We have many different request types and sometimes issue types sharing 1 workflow and automations allows us to create different approval triggers and approvers depending on various criteria pretty easily. 

Whichever way you choose, I agree with what Matteo said, some level of documentation in Confluence would be good practice. I often need to reference some of my own documentation to refresh myself on certain configurations when updates are requested. 

[Matteo Vecchiato]

Hi @Jeremy Wood ,

Thank you for interesting question.

In my opinion, it is more correct setting the approver inside the worfklow because:

• The logic and business rules should be inside the workflow
• The approver assignment is done at same time of transition as a block
• It is more easier to debug
• No automation execution counting increase

About you mention the problem to do the things in two different ways: you should document your configurations in Confluence, for instance, and create a page with all the assignment rules and tech references.

Hope could helps.