Tickets created from process templates
This may be an KB article request... But does anyone have a minute to explain the Process Templates and the best practices/intended use of these?
Background, I am not a newbie to Kace SMA but this feature is feels so convoluted to me it's like a slippery fish. We are very invested in the SMA help desk in that we have over 20 queues and actively use all for asking and directing help all through our organization and different departments. We have process templates in use currently to create tickets on a recurring schedule of our IT queue - maybe there is a better way to do this simply, but I thought this was the point of this feature? The thing I am most struggling with boils down to the fact that I just want a simple ticket created. With process templates you have to consider child tickets and parent tickets, which is great if that is what you are after, but not so great if not. Parent/child tickets are not something we use often, only when trying to relate/consolidate related issues (i.e., multiple tickets submitted for the same issue, multiple people working on different solutions contributing to the same end goal), and maybe that is part of my problem. What if we just want a ticket with a comment outlining a process that needs to happen daily/weekly/monthly? Can't be a parent ticket then because the comments do not pass on scheduled ticket creation... So, it needs to be a child that can inherit parent fields?
I have asked Quest support about this and did not have a lot of success communicating my question. It's a feature request was the last thing they told me, and maybe it is. However, maybe someone here has delved into this hole and come back out and can offer better insight.
I have searched for articles to try to understand the processes feature better without luck and the manual is not great at explaining this feature either. I know there are experts out there.
Help?
Answers (1)
Mashby it sounds to me like you need a good review and rebuild, get rid of the stuff that new KACE functionality has now made easier!
To answer your question on Processes, a process is a predefined trail of tickets ran either in serial, one after the other, or parallel, all together.
The idea is that if you have a set number of tasks to follow you create a process, so when you log a process ticket the first child task is created, when that is closed, the second child ticket is created etc etc until the process is complete.
Not every queue needs to operate on processes and there are some clever things we can do if you want only 3 child tickets this time, in parallel, as opposed to 5 next time.
Picking up on a couple of other things you mention, if you need scheduled tickets to be logged, we have a way of doing that which is rock solid, tried and tested.
And using templates is really useful and may help you consolidate a number of queues into a single queue for example.
We are experts, we do this for Quest day in day out and have been doing so for over a decade, so if you want a chat to explore what you need, please contact me directly.
Comments:
-
Thank you for your reply, it definitely helps with understanding the use of the process. I disagree that a rebuild is needed as I certainly do not have every queue as a process and there is absolutely no way to consolidate the queues we have currently, they are as intended for different departments and needs (as I tried to explain originally). I think, rather, that a process is not intended for the use that I was trying to use it for and quite simply a re-occurring ticket is not supported at this time (hence the feature request answer from support - although you are mentioning some rock solid way of doing it...?). Regardless, with efforts better invested elsewhere I was able to easily achieve my goal through other means. I was seriously struggling with, two things: shouldn't a process be able to do what I want here (create a ticket a in a schedule that is)? And maybe if I can understand how they work better I can use it as intended...
I feel like, because of your explanation, the "process" offerings in Kace are a little less slippery for me so again thank you. I still feel like I could not find this information on my own, as the manuals are lacking and a KB could be written to explain the intended use, which you quite elegantly put as "a process is a predefined trail of tickets ran either in serial, one after the other, or parallel, all together." - unless that was taken from somewhere? So however silly it seems to me that the parent ticket cannot have content in the body of the ticket passed from the process, by your definition, it is overkill for this need. - Mashby1 1 year ago
