Kaseya Community

Service Desk Variable usage in checkVariable()

This question is not answered

Hi all,

I am trying to setup Service Desk to make use of de-dupe functionality and automation, prior to synced tickets being handled by engineers in ConnectWise.

I've run into an issue with de-duping alerts which the in-built isDupliateRequest() step cannot handle. For example two event log alerts with different Event IDs and different alert text. To resolve this I wrote a SQL query which will do the check for me based on [$SourceValueN$] and other ticket properties. The SQL query then writes the matching IncidentID of the already existing ticket into a variable. So far so good, this works and when I write this variable [=incidentID=] via addNote(), it gives me the correct result.

What I failed at was to check if the variable did indeed contain any data or not.
IF checkVariable([=incidentID=]) Exists ELSE did not work at all. In fact it worked so bad, that it would run neither the IF nor the ELSE.
So I tried the same using #incidentID# as suggested by the checkVariable() function itself. This would always produce the ELSE result.
What am I doing wrong here?

The same happened when I tried to assignCustomField () a field called "Duplicate" within the de-dupe procedure. The idea being to set this to "true" when a duplicate is detected. The Mapping procedure (which appears to be called either way, no matter if a ticket is considered to be a duplicate of an existing ticket or not) was to then check this custom field. But that didn't work. Same problem as above. [=Duplicate=] would not run IF or ELSE. #Duplicate# would always run ELSE.


Another question related to this issue: In situations as above, where I cannot use the in-built isDuplicateRequest() step, how do I add the text of the new alert to the existing ticket, rather that discarding it completely? I thought about using SQL to actually write an entry into the database, but that seems a bit excessive?
Can I somehow do the same thing the isDuplicateRequest() procedure apparently does and switch the "ticket context" (for lack of a better word) from a new ticket to the already existing ticket?


I am guessing someone else would have done something similar to this already and can point me into the right direction?


All Replies
  • Hi all,

    I thought I'd update my own post after spending more time on Service Desk.

    Using [=incidentID=] in notes and #incidentID# in checkVariable() steps worked.

    checkVariable() is only for variables defined via GetVariable. Don't try to use it for Ticket/Incident Properties or CustomFields, it won't work. And as it happens the Request Mapping procedures cannot check CustomFields, hence my problems with this.

    So right now I think I am on the right track with a de-dupe setup like this:

    - If I can properly de-dupe it in the De-Dupe procedure, I do that

    - If I can't, because the alerts are just too different, I handle that in the Request Mapping procedure.

    The mapping procedure uses some basic logic and a SQL query to determine if a ticket already exists that I should be adding a note to.

    It then sends an email to a mailbox which is checked by Service Desk. The email has a subject line which consists of nothing but ~ticid=<TICKETID>.

    This incoming email will hit the mapping procedure again, so I sort any incoming emails which have a subject line starting with ~ticid out (at the top of the mapping procedure), to avoid the original ticket being re-categorised. The body of the email is added to the original ticket automatically.

    So far so good.

    Now I have also started playing with automation.

    It took a while as Service Desk doesn't handle passing variables between SD and Agent Procedures very well. But I could overcome that using a single custom SQL table. Service Desk writes relevant fields into the table, calls an Agent Procedure and the Agent Procedure reads all relevant variables from that table. Once it's done with it's job it sends an email back to Service Desk (using the ~ticid subject as above) and then clears those details from the table again to avoid clutter.

    Using the above approach I can now detect a failed service, automatically create a ticket, attempt to restart the service, send the results back to service desk and either automatically add time entry and close the ticket or pass the ticket on to a tech to investigate.

    As this setup allows me to pass an unlimited number of variables to Agent Procedures, I can use this approach for any kind of automation I can come up with, so I'm happy with that. :)

    Having said that, there are still a few annoying little things like the fact that notes written within the same procedure end up all over the place in the ticket - with notes being a major way of troubleshooting procedures, seeing them in the correct order would be really nice...

    I has also been a painful process to get to this point.

    Limited documentation and a lack of technical Techjams or webinars on the subject are not helping with adoption. I guess Service Desk is not much loved by Kaseya (anymore)? Not enough sales?

    I'm marking my own response as answer as while both the question and answer have probably been a rather incoherent babble, they might still be useful to someone in the future. :)



  • Roman,

    Better Nate than lever, I always say! :)

    I've built a highly automated service desk, almost in spite of the limited automation capabilities of SD procedures. (What kind of program or procedural language designed for task automation can't do basic numerical comparisons or simple increment/decrement operations?? Yikes!) We've turned to SQL to handle many of these simple tasks, creating a virtual Swiss Army Knife of functions that don't even touch a table.

    Anyway, DeDup and tracking repeating events has been a considerable issue in the design our our SD. I do use the DeDup procedure, but require an exact match of the event, and keep the time short - tied to the remediation time assigned to the event. I might allow 20 minutes for remediation to complete, so I'd use that for the DeDup time as well.

    Like you, I also write a SQL table to track the events, which allows communication to the agent procedure (another huge shortcoming - the inability to directly pass even one arg from the SD procedure to the Agent Procedure.)

    I think that one of the challenges is that the intake procedure runs prior to a ticket actually being created. I had to move much of my logic out of that procedure and into a Stage 1 proc to actually associate data with a ticket, but by then, the dedup is too late - it's already a ticket. I also run some logic to see if the event is repeating - alert - fix - close, repeat ad-infinitum. After a few of these, we send a New/Open/Repeating Event event to our ticketing system.

    How are you identifying the record to use in the SQL table? Does the AP simply look for it's ID? How do you handle simultaneous events? I'm using an external procedure to scan the table and invoke the AP via the API, passing the record ID so the AP knows exactly what to do. Are you tying multiple events on a single agent to a single ticket? (ie - 2 services stopped  on Machine-X = 1 ticket?)

    I can relate to the issue with notes being a jumbled mess. I write a lot of notes for debugging and it's very difficult to "watch" the progress of the automation with the notes being displayed in an apparent random manner. What - no event sequence tracking or timestamp with ms accuracy to keep these notes in sequence?

    Honestly, I think that SD isn't much loved because it's so dang'd hard to do any real automation without external processes. Add basic math, "real" numeric comparisons, and argument passing to AP's and it would be hard to beat.

    Good luck with your efforts, I feel your pain!


  • We have built our own dedup function that does not rely on Kaseya's  , and allows partial matches on summary / description etc and is configurable via a custom page allowing dedup "rules" to be defined

    Send me an email to paul@mspassist.com or checkout our website at www.mspassist.com

  • This is just what I needed at the moment, thank you.

  • Going back and forth between SD and Procedure scripting... not sure what happened... I just stopped trying to use the testIncidentproperty option... oops