K1000 Service Desk and Process part of it.
It's a question with k1000 and it would be a service desk problem as well. Is there a way to edit the process before it creates all of the child tickets. Also can you only have one process, for some reason its not letting me create more. I'm trying to make a new user process but not all employees would have the same thing tings for tickets. Just think it would be better to have a template which then one could edit what happens. Is there a way to do this?It wouldnt make this effective if i have multipl processes that are all just different slightly.
Hopefully this can be solved, thanks.
Jon
Answers (2)
When the bug affecting this blog has been fixed, I'd suggest taking a look:
http://www.itninja.com/blog/view/k1000-service-desk-setup-tips-things-i-have-learned
In short, though, I do have processes setup for *slightly* different ticket setups (i.e. default values). For my user change queue, I have three processes (new user, term user, change user) with each process spawning three child tickets, and they are basically the same except for the default values in the parent and child tickets. Works pretty well here.
To answer your question directly - yes, you could go into the process every time and change the values for the parent and child tickets before you run them, but I think it's more time saving just to setup multiple processes and be done with it. More work on the front end, but much time saved on the back end.
And yes, you can create as many processes as you want. It's been a while since I set mine up, but if I remember correctly you need to have at least one parent ticket and possibly at least one child ticket before you can keep going.
Hope that helps!
John
Another idea is to document all of the variations of your setups and determine exactly what "components" are common between things and which are unique. When I first started, I had the grand idea of setting up tickets for all of the major processes of user adds/terms/changes, but once I realized how things worked I found it better to handle those items through checklists (that I have populated in KB articles and can drop into the child ticket comments) rather than through separate tickets. All depends on who is doing things of course - for example, I have a child ticket for ERP system changes go to our ERP guy and I get the other two (one for user account items, the other for machine specific items). If you have things split out further, it would make sense to create child tickets for each responsible person and then differentiate between roles/tasks by way of a checklist. I brought this up at the last Advisory Kouncil and they are baking checklist fields and unlimited custom fields into v5.4, so the possibility is definitely there for this type of setup. I'll have to revisit my own setup once 5.4 is out, but for the time being hopefully this will give you some ideas. Honestly, I spent more time building out process maps and breaking down all of the different user process variations that I did setting up the K1000 - but it was definitely worth spending the time on as things go very smoothly now.
John