I wanted to share a use case we’re currently addressing:
Use Case
We’ve observed that tickets marked as Complete can be unintentionally reopened when a client replies to the original email thread. This happens because the reply is sent to our support address and includes the original ticket number, which causes the system to reopen the closed ticket. This behavior disrupts our reporting, particularly around ticket resolution times.
Proposed Solution
Identify incoming emails with a subject line containing "RE:" and a valid ticket number.
Check the ticket status in Autotask to confirm if it is marked as Completed.
Evaluate the ticket age to ensure it meets our criteria for archival or follow-up.
If conditions are met, append the new email content as a note to the existing (completed) ticket.
Create a new ticket, and include the note with the previous ticket’s details.
Add a reference link in the new ticket pointing back to the original ticket.
Proceed with standard ticket processing for the newly created ticket.
I’ve started building a rule to implement this logic, but as I’m still new to MSPIntegration, I’d appreciate any insights or suggestions on whether this is the most effective approach—or if there are better alternatives we should consider.
Within the “Autotask Update Existing Ticket” workflow action step is a checkbox to “Filter Tickets”. You can use this to limit what tickets are located when MSPintegrations tries to locate the existing ticket.
Here’s a thread showing how it works:
And here’s a post in another thread showing a more customized approach using that same option:
If you use that check box, you can modify your rule to have just two steps:
Step 1: Update Existing Autotask Ticket, with the filter enabled to only update if the ticket is not old.
Step 2: Create a new Autotask Ticket
Query Autotask based on the ticket number retrieved from the step above also then query the Create date, the ticket number is equal to what was retrieved, query the status of the ticket received this should be equal to complete
I recommend you use the query to determine if the ticket is older than 90 days. Instead of querying for the ticket and then checking the date, the query itself would only return the ticket if it’s old.
Your current step 2 already does this. If step 2 returns a ticket, you know the ticket is complete and old. If step 2 does not return a ticket, then either the ticket number wasn’t valid or the ticket is not old, but either way you know that the ticket number doesn’t represent an old ticket.
Your steps would look like this:
Step 1. Extract the ticket number from the ticket (done)
Step 2. Query for the ticket by ticket number, but only return the ticket if it’s old (done)
Step 3. If custom.QueryTicket.id is empty, stop processing this rule
Step 4. Create a new ticket
Step 5. Add a note to the new ticket with a link to the old ticket (use {{custom.QueryTicket.meta.autotask_url}} and {{custom.QueryTicket.TicketNumber}})
Step 6. Stop processing the email completely (so no more rules are executed)
That is correct yes that is the value being returned from the initial trigger which looks at the subject of the email to see if the ticket number exists.
The Query then takes the ticket number found and Queries Autotask to match the ticket and i then want to match the Create Date & Status and if i can do the checking of the date n the same Step that would be a bonus
The fact that that the query step returned a ticket is what tells you that the ticket is old. If you test with a recent ticket number, that query step will return nothing because no ticket matches all 3 criteria.
In other words, the query is telling Autotask “Send me a ticket but only if it matches all 3 of these criteria: the ticket number is XYZ, the status is complete, and the create date is older than 90 days ago”.
If Autotask returns a ticket, then you know it’s an old ticket.
If Autotask doesn’t return a ticket, then you know the ticket number does not represent an old ticket.
If the rule didn’t pick up a ticket you expected to be picked up, send me the URL to that history in your MSPintegrations account so I can review the logs and see exactly what was executed.
The reason it was skipped is because it has an expression that only fires it the email subject line matches “Assigned to you” with a ticket number AND it matches a ticket number:
Hi Travis i actually just saw that now let me amend and restest
I have tested the existing ticket and as you said it did not match on the regular expression
This is great can i delete all the other steps beneath the Query Autotask step and continue with your suggestion of creating the new ticket and appending the existing one
I am pleased to report the rule is working the core concept is working
I need to clean up some of the bindings in the email that’s just formatting so i am ok with that.
Last Question my rule sits at the top of all the other rules but there is once rule that also checks if a Ticket number is in the subject line and appends a note to the original ticket and this is a problem as it is appending it to the original ticket which is then opening that ticket so i need to create a condition that stops this from happening not so sure what that looks like
