Kaseya Integration in 30minutes or less

Basically CommitCRM will open tickets based on email alerts that match rules configured in the CommitCRM MSP email connector. This is purely a one-way path Kaseya alert email is interpreted and creates a CommitCRM ticket. There is no back path to Kaseya to close alerts.

I am still running Kaseya 4.8.x, but the concepts should be the same for Kaseya 2008.

First, in Kaseya go to each of the following areas, select Email Format, and add the following to the subject of each email template: “site:<gr>.” <gr> is the Kaseya variable for the Group ID. (change “.” To “:” if you wish to use Kaseya sub groups to link to the CommitCRM account ie “site1.location5”)

Monitor – Alerts (for each alert type in the pull down)
Monitor – Assign Monitoring
Patch Mgmt – Patch Alert
Backup – Backup Alert
Security – Security Alarms

Kaseya alerts will need to be setup to email to your CommitCRM support email address for processing.

Second, set up Commit’s Email Connector using the serverconfig program. Go the Email Connector tab, scroll down to Email Processing Settings, Select Automated Emails. Set System State to On and click Automated Email Settings.

Add a rule at the top for “Rules for detecting and identifying incoming emails as automated” and enter the email address your Kaseya uses for the From field of alerts and hit OK. Skip down to Account Record Detection Rules and create a rule:

Account Name (file As … field )
Located: between
The Word/Phrase: “Site:”
And “.” (replace “.” With “:” if using subgroups)

Third step is to modify the (File As Field) in the CommitCRM account to be the primary Kaseya group for the client. You need to be in a CommitCRM View that includes full details to see the File As field. Since we are using “.” to terminate the subject search, subgroups in the <gr> will be ignored and should not be included in the File As field (.ie if <gr> = site1.location5 the rule above will return a File As value of site1). Case is significant!

The only negative affect of this config I have found is that the CommitCRM Outlook Syncs the CommitCRM File As field with the Outlook File As Field and then Outlook displays the File As field as the contact’s company name in the Outlook Contact screen.

I do not see any more or less ability in this configuration versus the Level Platforms and N-Able configs presented in the CommitCRM Documentation.

Thanks vsouthmayd for sharing this with other members and for taking the time to list detailed instructions on how to integrate with Kaseya.

Following this post, and some additional feedback we've recently received from other users, we wanted to let everyone know that we are working on an enhancement to automated emails feature.

In a day or two we will release an update that will let users define smarter Account Record Detection Rules. In addition to detecting Accounts by their name (File As...) and Record ID, you will also be able to detect them by other fields in the Account record. This way you'll be able to keep using the File As field for its original purpose (the master name of the Account) and use other fields to store the Account IDs as found in other systems.

For example, you'll be able to use the Account Field1 field to store the account identifier of your MSP system - for example, if in your MSP system the Account has the following identifier: "234.234" you'll now be able to store this id in the Account' Field1 field in RangerMSP and use it in an Account detection rule so the Account in RangerMSP will be identified using its id in your MSP system!

If you're using more than one MSP system, no problem - you'll be able to use several different fields to store the MSP system IDs in RangerMSP and it will all work simultaneously (i.e. you can integrate RangerMSP with more than one MSP or a similar system at the same time).

More on this will be posted soon.

Thanks for the great feedback!

Eitan

Eitan,

Thanks for the update. The change will definitely improve the ability to integrate CommitCRM account with multiple MSP systems. This also will fix the Outlook File As defect I noted. Responsiveness and reacting to customer needs are some of the primary reasons we are considering CommitCRM over other solutions.

If I could be forward and make a feature request. It would be valuable to extended the MSP integration to the account asset level so that specific assets ie. servers could be tagged. By allowing rules to search individual assets and adding an employee contact for the specific asset, this would allow us to configure higher response levels to high priority assets. If the specific asset was not found the ticket rule would fall through to the less specific account level rule. This way we can have server tickets page the on call tech and queue workstation level tickets in email. While we are asking for things how about a per asset priority value for the same issues above.

Last but least in a future version it would be fantastic to look for open tickets for the same account with the same email subject before creating a new ticket. Ideally the logic should be [ticket subject] contained in [Email subject] to handle RE: fwd: etc. then append the email to the ticket, else create a new ticket. I have customers receiving duplicate alerts during a day and each alert is opening a new ticket.

Thanks

Vernon Southmayd
Creative Computing

Vernon,

Thank you for the additional feedback and suggestions. Everything was filed and logged into our system.

Eitan

Good news!

We've just released an update to RangerMSP 4.4 that lets you store your MSP IDs in RangerMSP and lets you define Account Detection Rules that will tell the system to detect the Account in RangerMSP based on the Account' MSP system ID !

This means that you should not use the 'File As...' field anymore (as described above) and that you should use one of the new supported fields, such as the Account#, ID, Field1 etc., to store the MSP system Account ID.

You can read more about this and about how to update your system here.

Eitan

We've been playing with this most of the day and can't seem to get CommitCRM to parse our emails from Zenith. The format is as follows:

Service Ticket ID # 200808010003190 ( Password vault - User Configuration could not be read. (Site Name:CompanyName / Resource :SystemNAME) )

We've told it to look for the appropriate email address and have added the CompanyName to the Acct# location inCommitCRM.

We've told the automated email parser to look right after "Site Name:" I've also tried between "Site Name" and "/"

Any suggestions on how we might get this subject to be legible to the automated parser would be helpful :)

Hi,

From the subject line you have provided, this should work fine. Just make sure you use the correct rules as follows:
1. In the "automated email detection rules" - add a rule:
The Sender: "incoming email address for the Zenith alerts"
The following phrase: <can be empty>

2. In the "Account record detection rules:
Search for: "Account #"
it should be located: "between"
the word/phrase: "Site Name:" (make sure to use the colon)
and: "/"

Please note that the Account # field is quite short, so it is not ideal to use it when holding the company name as the account identifier. The Account # usually can keep the ID for the site, rather than the name. I would recommend working with the File As field if possible (make sure to select it in the Account detection rule if you change this), and use the "Account Name (File As... field) in the Account Detection rule.

In any case, make sure to restart the RangerMSPServer service, so the new settings will take effect.

I hope this helps.

Neta