Announcement

Collapse
No announcement yet.

Advanced Kaseya Integration

Collapse
X
Collapse
 
  • Page of 1
  • Filter
  • Time
Clear All
new posts
Previous template Next

    Advanced Kaseya Integration

    I am looking to gather a group of CommitCRM users that also run Kaseya in-house to work on furthering the kaseya/ CommitCRM integration. I am interested in auto synchronizing assets from Kaseya toCommitCRM.

    Also I would like to compare notes on alert to ticketing rules and how where you are opening and closing tickets. We are currently emailing alerts from kaseya into the CommitCRM email connector to create new tickets. We currently are creating new tickets under the correct CommitCRM user, but we have the following problems:

    1. Duplicate tickets are created for the same issue if the problem is not not addressed before kaseya sends another alert. This can get out of control if kaseya is forwarding event log alerts. We want to know the problem is there, but I don't want 20+ tickets to tell me.

    2. There is no way to tie the tickets to individual CommitCRM assets using the email connector. Ideally if CommitCRM assets had account manager's and we could link new tickets to an asset using the kaseya machine id, we could implement basic SLAs where new tickets for servers or critical devices would be assigned to a role based account manager. (probably would eat an employee license)

    3. Overall no SLA management where priority of outages/equipment drives notifications at creation, or as timeframes expire. I realize that we can sort a report to pull this information, but I need to be poked if someone has not addressed a server issue within our response window. I do not currently have a dedicated dispatcher to do that for me.

    4. The connection from Kaseya to CommitCRM is currently one way.

    I am not asking CommitCRM to add these functions, nor do I believe it is their responsibility to do so. Between Kaseya database views, the CommitCRM API and throwing in email2db, I believe we have the ability to do this ourselves. We just have to develop the business logic and best practices before starting to write a Kaseya/CommitCRM connector.

    Please email me at vsouthmayd@gmail.com if you are interested.

    Vernon Southmayd
    Creative Computing, Inc
    http://creativenetcare.com

    PS. CommitCRM please tell me if you are planning on addressing these concerns already in a near version, and I will sit back and wait. :-)
    Re: Advanced Kaseya Integration

    Hi,

    Our input on this one refers to the duplicate entries you mentioned:

    "1. Duplicate tickets are created for the same issue if the problem is not not addressed before kaseya sends another alert. This can get out of control if kaseya is forwarding event log alerts. We want to know the problem is there, but I don't want 20+ tickets to tell me."

    We may be able to help with this one.

    If the email alert which arrives for the same issue again contains a word/phrase which indicates that this is a second (or more) alert, you can add a Skip Rule to the Automated Emails part, and set it up with the word/phrase. When the system will encounter an automated email with a subject which contains this phrase, it will simply skip it, and avoid the new ticket creation.

    Click here for more details on settings Skip Rules for the Automated Emails in the Email Connector.

    HTH

    Ethan

    Comment

      Re: Advanced Kaseya Integration

      Ethan,

      Thanks for the hint. I am unaware of a a way to indicate a duplicate alert email from Kaseya in the 4.8.x version I was running. I just upgraded to 2008sp1. I will check into the ability to note duplicate alerts in the new version.

      Thanks

      Vernon Southmayd
      http://creativenetcare.com

      Comment

        Re: Advanced Kaseya Integration

        Hi just a word on this. I get duplicate emails with the following format.

        ASMBIT job# 123 <client name>

        Now, the only thing that is different is the job # however i could be receiving the same job number twice or 3 times, if i was to create a skip on all those numbers, that wouldn't work right? so...what can i do about this?

        Comment

          Re: Advanced Kaseya Integration

          Hi asmbit, I see what you mean, however, in order to define a skip rule, you need to have a way to uniquely identify these messages in advance, so you will be able to define the rule.

          If you can make the sending system add a unique phrase to the email subject, which will indicate that this is not the first message for this job #, then it will be possible to define the skip rule for it. It has to be something you can use when defining the rules for the Email Connector.

          Ethan

          Comment

            Re: Advanced Kaseya Integration

            unfortunately the customer has their own system in place and they can't change that.
            any other method i can use? such as comparing the email subject with existing tickets?

            Comment

              Re: Advanced Kaseya Integration

              Hi asmbit,

              Identifying a ticket is done in RangerMSP by the ticket number, so if they could add the ticket number to existing cases, then the Email Connector would be able to see that this is a message related to an existing ticket, and avoid opening a new ticket for this.

              Additional options are not available, you may want to check whether they can adjust their system to one of the options already supported by RangerMSP (a fixed phrase in the subject for "second" message or adding the RangerMSP ticket number to the subject).

              Ethan

              Comment

              Previous template Next
              Working...
              X