I'm trying to use variables within a note template in our service desk, and not having much luck with it.I've created a note template with a big block of text (which includes variables). Each line is identical, indicating variable, and including it in all forms which it MIGHT use.
Example from the note: Assignee: - [$Assignee$] - [=Assignee=] - #Assignee# - [#Assignee#]AssigneeEmailAddress: - [$AssigneeEmailAddress$] - [=AssigneeEmailAddress=] - #AssigneeEmailAddress# - [#AssigneeEmailAddress#]
We're doing this for the following fields: AllNotes, AllPublicNotes, Archive Flag, Assignee, AssigneeEmailAddress, Category, Changes, ChangesasHtml, ClosedDateTime, CreateDateTime, Description, EditingUserName, EscalationDateTime, EscalationLevel, GoalDateTime, LastEditDateTime, Machine, MachineGroup, Manager, Organization, Owner, OwnerEmailAddress, PolicyName, Pool, PreviousStage, Priority, ReadFlag, RelatedTicketsAsBulletList, RelatedTicketsAsString, Resolution, ResolutionDateTime, ResolutionText, ServiceDesk, Severity, Source Type, Stage, StageStartDateTime, Status, SubmitterEmailAddress, SubmitterName, Summary, TicketId, TicketURL
This SHOULD, in at least ONE of those fields, have the appropriate variable replaced with the corresponding value. I've used all variable forms which they might use - Object level, Procedure level, and temporary (not sure what to refer to it as).
Unfortunately, instead of getting: AssigneeEmailAddress: - email@example.com - [=AssigneeEmailAddress=] - #AssigneeEmailAddress# - [#AssigneeEmailAddress#]
I'm getting the exact block of text: AssigneeEmailAddress: - [$AssigneeEmailAddress$] - [=AssigneeEmailAddress=] - #AssigneeEmailAddress# - [#AssigneeEmailAddress#]
Is this wrong? Should I be able to use variables within a predefined template? Or am I over thinking this for our SD people? Many of their responses will be canned, and I'd like to pre-populate the majority of this information if possible.
Hey tkindree , did you get anywhere with this?
No, we bailed on Kaseya's ticketing systems entirely (both Ticketing and Service Desk). There were things in there which I really liked, but unfortunately it wasn't going to fit our needs appropriately.
We now have all of our ticketing handled within Connectwise. All things Kaseya which require a "ticket" to be open (Eg: Server down, Network unreachable, Disk full, Service unavailable) send an email to one of several different email addresses which are pulled into ConnectWise and dealt with from there.
I feel your pain!
You're missing the boat by not leveraging Service Desk (which is NOT a ticketing system, really). We bring everything into Service Desk - emails get tossed (UPS Started a self-test - who cares?) or reformatted, leaving only what's important. We use Service and Event Monitors, many of which trigger remediation procedures. We even process "Request" procedures that trigger a procedure but not a ticket - these perform new agent initialization, "run maintenance now" and similar requests from end users (install apps is coming), and our engineers can suppress alerts via a command-line tool without connecting to Kaseya. We use ConnectWise on our back end, but by leveraging service desk, we've seen roughly 62% fewer tickets in CW, and have reduced hours on alert tickets more than 50%. Some of this is through better alert quality, but much is due to auto remediation provided by Service Desk, and what we refer to as "Smart Monitors". These monitors track events and conditions intelligently. They auto-adjust to the conditions (disk alert threshold based on disk volume size, for example), transient suppression (don't alert unless the condition persists for a specific duration), and self-remediation (AV definitions outdated forces an "update definitions now" command for about 9 different AV products).
When we do create a ticket and send it to ConnectWise, we can determine if there's already an open ticket and update it, otherwise we send a new ticket. Service Desk has allowed us to send both Open/New and Closed tickets to CW, depending on whether the remediation was successful, providing a detailed history of all alerts. We even leverage Service Desk to send Voice Incident Notifications - when a priority event is detected AND the help desk is not operating AND the customer is within extended coverage hours, we perform an Internet Voice Call to alert the on-call staff (we call our after hours answering service, who intelligently alert the primary, and then the secondary engineer only if needed).
What we've also been able to do with the automation is to increase our managed endpoints from 1700 to just over 2500 with no increase in staff. With just 3 engineers on help desk most days (some days just two engineers are available) we can handle live support calls with no hold time or callbacks -AND- the alert ticket load.
It's kind of a shame that Kaseya has positioned Service Desk as a ticketing system for so long. It could, but you shouldn't. You SHOULD use SD for what it excels at - ticket triage and automated remediation.
You can see what we've done at www.mspbuilder.com or on the Automation Exchange. We have two Kaseya solution options - the Multi-Tool, which adds 60 powerful functions to those who want to build their own Service Desk automation, and the RMM Suite, which is a turnkey Kaseya platform that leverages Service Desk to the max. Take a look just to see what you can do with Service Desk.
I will say, it wasn't easy - it took research (what alerts are BS? which are important, and which are VERY important? What can we remediate? How?) Then came planning - logic, methods, etc.. it took about 9 months of dedicated effort to develop, and another year of use internally to polish and enhance, but was it ever worth it!