Auto Closing Tickets if time is less than 30 minutes and repeat offenders

Hi. Has anyone managed to add time concepts into tickets? We are struggling to get it working. Hopefully someone can help.

Here is our scenario:

We get an Alert generated if a threshold is breached for longer than 5 minutes. We then get a resolved notification when it transitions to a healthy state again. What we want to implement is a auto close if the time between the alert and resolution is less that 10 minutes. If its over 10 minutes we want the resolution added but not closed.

Similarly if we have a server that is logging alerts and then auto closing constantly. Is there a way to build some logic that says if x alert has fired y amount of times in the last 7 days and auto closed then dont auto close so we can then investigate the cause.

Thanks for any help in advance

The key tool to do date range comparisons is the date text helper. Here is the documentation link on this: MSPintegrations

Note there are also separate pages on date formats and time zone commands.

This command will return the current date and time minus 10 minutes in the Internal AutoTask time zone.

  {{date subtract="10 minutes" to_tz="Autotask"}}

Here is a script to only complete a ticket that is <= to 10 minutes old:

Step 1 saves the current date and time less 10 minutes in the variable {{custom.NowLess10Min}}.

Step 2 (not shown) finds the open alert ticket and you will need to work out the logic that selects the proper ticket. You will also want some error checking logic to handle the ticket not being found. I do not show that here.

Step 3 completes the found ticket only only if it is < 10 minutes old:

This works because Autotask stores dates in the format YYYY-MM-DD HH:MM:SS and that allows string comparison for >, =, < to work for dates.

I will add a separate post on counting ticket reopens.

Implementing a process to count the number of repeat alerts is possible. This post outlines one of several approaches.

Add a Ticket UDF named Alert Count of type number. We will use this to count how many times the alert happens. But only up to a set max, I chose up to 5 times.

When a new alert is received you want to search for an existing ticket for that alert, in either an open or closed status. But you probably only want to find an alert ticket that was active within a set time-period. Let’s assume <= 24 hours. The statement below gives us that date and time:

{{date subtract="24 hours" to_tz="Autotask"}}

We store that into a variable named NowLess24Hours and use the variable in the query for the existing ticket.

In addition to any logic to find the proper alert ticket add this additional query condition:

Last Activity Date >= {{NowLess24Hours}}

By looking at Last Activity Date you will get any alert ticket created, updated, or closed in the last 24 hours. I would use the query for one object command and sort descending on the Last Activity Date. This ensures that you will get the newest ticket.

Then we will reopen this ticket and update it rather than create a new alert ticket. But if all prior alert tickets are inactive for more than 24 hours, we will not find a ticket and will need to create a new one.

If we found a ticket we now need to update the ticket status to make sure it is open and increment and update the Alert Count UDF. We do not have math operations at this time to do the counting, so I use the brute force method shown below.

Get the current count from the ticket and move it to variable custom.AlertCount.

Now we work backwards from our max count value (5 here) and update the variable:

We do this for each possible value from 4 down to 1. I dont show all steps…

The last statement handles the empty or 0 value.

Finally we update the ticket with the value new value.

You can add a test for any trigger value for Alert Count that you want to bring to someones attention. Maybe sending an email or moving the ticket to a new queue or new status.

Thanks Alex for coming back to me. I’ve tried to get this to work but to no avail. Wondering if you would be able to assist.

Ive created 4 steps as below

First I query the existing ticket and I can see that the variable populates

and I can see a ticket create date value of


The next step then sets the date back 10 minutes

I can see this value is


I then do a ticket update to the ticket which always works ok.

The last rule is set to close if the create date is larger than the date back 10 minutes

However, it keeps skipping the step.

I’ve even tried a value more than 10 mins but doesn’t work.
Any ideas?

Hey @dale,

Text rendering (values rendered with {{ ... }}) is not available in the expression builder. It’s not apparent in the UI, but the expression builder uses a boolean logic test of the values (i.e. !=, and the text rendering converts the value of an expression to strings when the expression is placed between {{ and }}. The expression builder does not recognize any text rendering functions.

What this means for you is that you will need to render the {{date}} value to a variable first, and then test that variable in the next step. You won’t be able to render the date value and test it in the expression builder at once.

Thank you for asking this question. I’m re-thinking this design to see if we can make this more apparent or streamlined.

Actually, I think this is much simpler than I initially recognized.

You are using {{ and }} in the expression builder. You should not include the curly braces. Instead, the right side of the expression should be custom.NowLess10Min (instead of "{{custom.NowLess10Min}}"). No quotes, and not curly braces.

It’s probably as simple as locking the right side and selecting the field instead of typing it free-form.