There are a few stages of Autotask Workflow Rule (WFR) savvyness. The 1st stage is when you discover that you can automate changes to tickets based on events+current ticket state. That is, you can make things happen based on how the ticket is Right Now when some external factor happens (e.g. a ticket is created). The 2nd stage is when you realize that you can automate based on changes in ticket state. Let’s tackle that 2nd one.
Remember that an Autotask WFR triggers when something changes, not because something merely “is.” In our 1st stage, we are focused on event+current ticket state, like in this example:
Event Edited By [anyone] Condition Status [EQUALS] Complete Update Status = ReOpen
That’s a very vanilla approach, and it usually works.
But there are many situations where we want to only trigger when the Condition is a state-change, i.e., when it is changing from one value to another. An example is if you want to automate emails going to your techs when a mail reply comes in.
This WFR will nag your tech every time an email comes in until they update the status:
Event Edited By [anyone] Condition Status [EQUALS] Mail reply Notification ... [Primary Resource]
Let’s be more merciful and ensure the tech only gets the FIRST notification:
Event Edited By [anyone] Condition Status [CHANGED TO] Mail Reply Notification ... [Primary Resource]
Yes, in the example above, you could update the status to Mail Reply Sent or something, but sometimes you want to keep the status (or other field) as it is, and just make the WFR smarter.
This gets even more powerful when you realize you can also trigger WFRs based on TWO changes of state, like so:
Event Edited By [anyone] Condition Status [CHANGED FROM] Complete Status [CHANGED TO] Mail Reply Update Status = ReOpen of Old Ticket Notification ... [Primary Resource]