Could I have different approval paths based on a custom field?

[Scott Hardegree]

We have a client scenario where an issue will either go to an approval step or not go to an approval step based off some description or field. For instance, if an issue has the description or field of "legacy", then the issue does not need an approval. If the issue has the description or field of "Short Term Fix" then the issue routes to approval path 1 and to approver group A. If the issue has the description or field of "Long Term Fix" then the issue routes to approval path 2 and to approver group A and B. Or some variation of this. Could this be accomplished in building out a workflow, or would this best be suited by automation? What would be an example of how to do this? I appreciate any help I can get with this!

[Dirk Ronsmans · Accepted solution]

Hi @Scott Hardegree ,

There are a couple of requirements here.

• Do these routes need to be enforced or just possible?
• Are the approvals required different depending on the route?

I would personally if the use case is truly different for the 2 approval paths (and the no approval path) build out the workflow with 2 different approval steps and one transition that jumps beyond those approvals.

Using conditions you can block when an issue can take a certain path.

Using automation you could then force the issue down a certain path and not allow them the selection based on a condition

[Scott Hardegree]

Hi @Dirk Ronsmans  Sorry for the late response, I was out of the office. 

The routes will probably need to be enforced if possible. Depending on the Standard Operating Procedure, the issues that need approvals will not need to progress unless that approval step has been fulfilled.

The approvals required would come from different approval groups, hopefully I answered this question for you.

So this seems possible by using a bit of conditionals for the transitions! I'll check this out and see what we can come up with. We would like to do as much in the workflow as possible, although we are not opposed to using automation.