Based on Jira workflow changes, there are now more complex rules about how to handle issues where commits have been merged. Different types of issues need to be handled differently. Some issues may have Epic Links, and others may not.

Automation does not allow for complex if-else logic. You cannot nest if-else statements, for instance. My initial thought was to abandon automation altogether and perform everything client-side in a script, but there are some huge downsides to this:

• It requires much more traffic to be sent between the client and server. Every run would require multiple GETs to get issues, components, etc. Then it would require multiple POSTs to transition issues, set issue fields, set components, etc. Currently, we send a single POST and that's it.
• It removes the atomicity of the operation. If the connection to Jira is flaky, we are likely to partially run the logic instead of fully running it. The REST API does not provide an easy way to roll back changes if something goes wrong. With the writable changes happening on the server, we do not have to worry about connection issues.
• The Jira REST API (and by extension, the python library) does not provide a nice human-readable version of custom fields. Instead, they are rendered with such helpful names as "custom field 12316542" instead of the "Ready" field, for instance.
• The Jira REST API provides no method to clone issues. We would need to manually  copy all fields from the old issue to the new issue. If issue fields change (hint: they will), then we can find ourselves having to update our manual clone method frequently.

With this in mind, there are a few possible approaches to this:
1) Put some additional logic on the client side, and break the current automation rule into a series of smaller rules. For instance, the client side could check for the type of the issue, and whether it has an Epic Link. With this knowledge, the client could POST to different webhooks depending on the nature of the issue.
2) Break the automation up into smaller rules. We can do basic if-then logic on an issue and delegate the automation off to a different rule depending on issue properties.
3) We can try to continue using a single rule, but use automation rule variables to allow for more complex logic.