Triggering Autotask Workflow Rules on Ticket Changes

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]