If anyone has experience using Autotask / Kaseya side by side, could i get some feedback?
We are using the round trip ticket closure feature of Autotask / Kaseya, i am guessing it works, i need to configured Kaseya alerts to go to Autotask which is cool, that will work fine. What I want to do, is take alerts from Kaseya's dashboard, and push them to Autotask, see the screenshot below for what I am aiming to do.
When i click that "New ticket", I want it to send it to our Autotask ticket creator email address thing. kaseya2AT or whatever it is, instead of Kaseya's default email parser.This is the only section in Kaseya that doesn't provide the flexibility for specifying an email address to submit tickets to.
Does this make sense? Am i missing something?
Lastly, for anyone reading this that doesn't use Autotask and is stuck for a working Service Desk solution, talk to Autotask, they are amazing :)
Nevermind - Our Service Desk was broken, everything works ace, Autotask is fantastic, ask me anything if you have any questions
Do you have Service Desk v1.3 with Service Billing working with Autotask integration? I am getting ready to Migrate to SD 1.3 and am told that my currently poor Autotask integration will be Broken. Since I'm not happy with the current integration, I'm looking for better options than vanilla kaseya2at.
We had Service Desk 1.3 but we hated it so much we "got rid" of it (deactivated it), service Billing was never used, much less with Auto task integration.
The one thing i'll say before anything else is you don't need Service Desk of any variety to get Autotask working sweetly.
Our Auto task integration is almost foolproof and requires very little intervention.I'd say it is more talioring your business rules to meet the quirks of either system.
We tend to keep it fairly simple, as explained below, i'd be keen to hear your thoughts though:- We have multiple work queues for different types of tickets (Server maintenance, breakfix, whole site down etc)- All tickets whereby customers call / email in are manually created (or through Autotask's Outlook extension)- All alerts that aren't specifically worthy of a ticket but we want to track for reporting purposes, we create a "Running Sheet" queue, use Kaseya2at to create tickets- Running sheet tickets are automatically assigned a low SLA, and set to complete with zero hours (makes our SLA reports look awesome too ;) )- We have the Kaseya NOC team monitoring stuff aswell - they create tickets in our ticketing module,- Kaseya integration extension in Autotask has Kaseya NOC tickets become autotask tickets, assigned low priority automatically, and have them open.-- note that its subjective, our low SLA gives us 20 days to action a ticket, response within 3 business days or whatever
For Autotask to be effective:
- Accounts in CRM, get these complete in Autotask, every single detail you care to import about your customer- Contracts setup properly - define your block hours / monthy payments etc- Work queues setup properly - every work type under every circumstance possible listed- All issues and sub issues carefully thought out- Careful consideration to how you allocate tasks to billable and non billable work.
What are you concerns around your existing Auto task integration? List them all and i will see what i can do about addressing your concerns.
I have a feeling i overshot the mark, and made a few to many assumptions, list everything you have thoughts about and i will reply accordingly.
Hi Mark . This post is a few months old but extremely relevant to where we are currently at.
We've been using Autotask integrated into Kaseya V6.1 Ticketing. It's simple and works well , the Autotask road trip works and so for each Alarm/Ticket created we get a corresponding Autotask ticket. We have added our own bit of code that closes the Alarm when Autotask closed the corresponding ticket as this part was missing and we ended up with the Alarm Dashboard lit up like a christmas tree even though all the tickets had been closed ...
Anyway .... question is will all this continue to work when we switch on Service Desk 1.3.
For various reasons we are forced into using the SD , so lets not get into the Pros and Cons .
My doubt is that Ticket States in the ticketing module where simple Open or Closed where as in Service Desk we have both Status and Stages of which both have there own states of Open/Closed etc.
If we want to add automation into Service Desk we can run procedure triggered from changes to tickets ... but this seems to only apply to when a ticket changes STAGE .
My concern therefore is Autotask integration will only change the Status not Stage of a ticket from Open to closed and prevent me from running any automated procedure.
I've sent numerous emails to Autotask but they seems to just ignore them .
So hopefully you can shed some light on this.
Seriously though. Paul, did you actually find a solution to your last post nearly 2 years ago?
I don't actually seem to be able to "close" a ticket based on a status change posted by the API
I currently using the KPSA module which will have Autotask integration at some stage
But to answer your question I’ve used various methods in the past to Close tickets using the API.
One is simply to use the API to add a note to the ticket , and in the note include a set phrase i.e. “This ticket can be closed”
Then in your Change Procedure [$Changes$] property includes this text , then have the change procedure close the ticket.
Or you get Autotask to email Kaseya SD when the Autotask ticket is closed and ensure within the Email Subject is the original Kaseya TicketID in the format ~ticid='[$TicketId$]' ( e.g. ~ticid='STD01234' )
And either in the Summary or email Body include your “This ticket can be closed” text.
The Actual API does allow you to directly manipulate various fields using the Update Incident method.. include Stage and Status ( and I presume you are referring to the Kaseya KSD API Web Services )
Fields you can update are list here , but include Status, Stage , Notes … etc.
I guess it comes down to how you are using the API
Not sure if this helps .. but let me know and I can see If I can add more detail if required.
Oh .. and are you using Kaseya 6.3 and SD 1.4 ?
Check this out as well
We actually use KPSA with 6.3 and AT as well.
We have dedup setup and working exactly how I want it. The solution is really good, and didn't involve stepping outside the box. We never create a new ticket for the same alert on the same machine. We always use the same ticket (in both autotask and kaseya)... regardless of if it is closed or open. It effectively creates a NOC style board in autotask (we have the tickets auto close when the alert clears). I reopen them in a "ticketmapping" procedure if they have been closed by kaseya.
Unfortunately, our Operations Manager wants to try it a different way.
I only have two real problems.
Ticket Change procedure doesn't actually fire when KPSA changes the status of a ticket to complete (which is what happens when someone closes it in Autotask).
I have overcome this by having an escalation procedure run every minute, and it uses logic to deduce if the ticket has been closed.
My next problem is that I cannot actually "close" a ticket from a procedure.
I have managed to move the stage into "Close" and I have an SQL update which changes the isTicketClosedFlag.
For all I can see, the tickets are closed, however, the "isDuplicateRequest" function (in the dedup procedure) with our newly added "include closed tickets" parameter set to "False" still doesn't recognise these tickets as closed.
I now have the full scenario working... with an ugly hack. I am archiving the ticket (using SQL update in a procedure triggered by the escalation procedure) which really does blind the "isDuplicateRequest" function in the dedup procedure.
I don’t use the Kaseya DeDup at all and do not have ANY escalation procedures as All our escalations are done in Connectwise
I have my own simple yet complex set of Stage and Change Procedures that use SQL commands to look for matching tickets and some VB running via SD Steps and some more VB run as an agent procedures on the VSA to make it all work
Sound messy but it works well.
With this I have managed to not only eliminate duplicates , but also eliminate seemingly unrelated duplications by using a table I have created in SQL
It allows me to dedup based on :
1) An exact match i.e. Same Group , Machine , Subject etc.
2) A Partial Match i.e. Same Group and Same Subject
3) A Partial Match i.e. Same Group and Similar Subject of “%Patches Pending% “
4) An unrelated match i.e. Same Machine with Subject = “..Low Disk..” matches Same machine with Subject “%MSExchange%”
Still find it Odd you can’t close a ticket though
I know that Connectwise KSPA does fire the Change Procedure for me , so have used it to trigger a close but currently the method I use is I have a custom field called “Can Close”
As I work through all my stage and sub procedures if at any point I determine the ticket can be closed I set the Custom field to “Yes”
And I have a final step in the process that check the field and if Yes sets the stage top closed , otherwise it leaves it open
I see. Thanks for the input.
I can close a ticket... it just isn't quite as closed as when you close it from within kaseya web interface.
eg, setting status to closed and moving to stage close, isn't actually a closed ticket. (you can still edit the ticket in kaseya web interface without "re-open"ing the ticket).
If I close it in kaseya, the function works as expected. If I close it myself in the procedure, the function still thinks it's open.
I have my escalate every 1 minute procedure archiving closed tickets... so I've solved my problem.
I have a ticket open with kaseya, so eventually, I am sure there will be a hotfix eventually (hopefully a "closeTicket()" function...