Why do my Automations hate me?

Automations can be a bit fickle at times, preventing you from creating a new automation with cryptic demands of nullifying a condition and saving the universe from an infinite loop. I would like to assure you, however, that your automation has your best interests in mind and is not just being passive aggressive because you forgot its birthday.

One of the most common issues people run in to when setting up an Automation is the error message "Automation must contain an action that nullifies a condition."

Oh the humanity!

This error message pops up even when you have created a perfectly logical automation that should work according to that big old head calculator of yours. The reason this message appears is because there is an extra layer of requirements around automations that you may not be aware of. Unlike triggers, which are only checked when a ticket is updated, automations check to see if their conditions are met every hour. Automations are so eager to please you that they work overtime, checking and firing on tickets even while you sleep. Especially when you sleep.

Because of these constant checks, the possibility of your inbox filling up with 18 copies of the same email notification is a constant fear that can make grown administrators cry. Like a blazing sword of justice, a requirement was added to new automations that an action must nullify one of the automation's conditions, forever banishing the threat of being spammed by your own creation.

Nullifying a condition with your action is fairly simple if you know what to do. You, of course, could follow the example in the error and look for a High priority ticket and then change the priority to urgent with your action, but where's the fun in that? Let's take this automation off-road.

The basic thing you need to understand about this requirement is that your automation should only fire once, without an end-user or agent taking additional actions on the ticket. If the logic of the automation means that it could fire multiple times without anyone noticing, that means it doesn't nullify a condition. The most common example that I see people using is Hours since Greater than instead of Hours since Is .

Let's look at an example.

This automation will not work.

The reason this automation does not work is because it's conditions will be met each and every time the automation checks a ticket that has been open longer than 4 hours. If you activate this automation, and the 4 hours passes at say, 6:00 pm on friday, you would have two and a half days of hourly notifications to sort through when you got back to work on Monday. Mondays are hard enough as it is.

Let's look at another example.

This automation will work.

This automation works because it fires only a single time after the ticket has been open for 4 hours. If this automation is active, and a ticket passes 4 hours at 6:00 pm on a Friday, your agent would receive a single notification telling them to get back to that requester--thus giving your agent more time to find new, exciting ways to procrastinate.

If you don't want to use the Is condition for automations because, for example, you have a backlog of tickets that have already reached the 4 hours mark, that's perfectly fine. You can use the Greater than condition as long as you have another condition, such as Priority Less than High (which includes tickets without a set priority) that can be nullified with an action that changes the Priority to High. Just remember the principle that an automation should only fire once if left alone.

Now we all know that automations are soul-less, conditional logic checkers--but even soul-less, conditional logic checkers don't want to get overworked. Follow the advice in this article and you can expect a great big bear hug from a soul-less, conditional logic checker's non-existent 0 and 1 encrusted arms.