12 Replies Latest reply on Apr 28, 2016 3:28 PM by cgaboury

    Onboarding process managed by Web Help Desk


      I am looking to see if anyone is currently using Web Help Desk to manage the new hire onboarding process. If so how did you accomplish this task.


      What I am trying to do is have a single ticket to start a process to provide various tasks for different technicians. We are using Web Help Desk as a centralized one stop shop to receive help. That means we are using it for all departments within our company and there will be technician for each department. An end user can go to a single spot to request help and it will get routed to the correct people.


      So with our onboarding process I want certain Request Types to trigger new tickets for the various department technicians to be responsible for. Is there a method to make this happen?

        • Re: Onboarding process managed by Web Help Desk

          There is now the ability in WHD to establish Parent/Child relationships between tickets.


          This page talks about using it for a new hire process:  http://www.solarwinds.com/documentation/webhelpdesk/flarehelp/whd_12-3-0_pa_en/content/helpdeskautomateparentchildtickets.htm



          Essentially, there are three parts:


          • Create a Task  under Setup -> Tickets -> Tasks.  A Task is a collection of "Task Elements", with each Task Element basically being a ticket that will be created when the Task is run.  You can have as many Task Elements as you want as part of a Task and each Task Element will be assigned to a specific Request Type (just like any other ticket).


          Here is an example of my demo environment's New Employee task and the 7 Task Elements which will become tickets when it is run:

          2016-01-06 16_49_04-Web Help Desk - Task Manager.png



          • Define a Request Type for your end users to select when they want to put in a New Hire ticket.    e.g.    "New Hire".    If you'd like, you can define some Ticket Custom Fields (Setup -> Tickets -> Ticket Custom Fields) so that the submitter can be asked to specify things like "new hire name", "organization", "office", "hire date", etc...


          • Create an Action Rule that runs the Task when someone submits a New Hire ticket.



          Once those things are done, it flows like this:

          • End user submits a ticket and chooses the New Hire Request Type, answering any questions that are prompted by the Ticket Custom Fields.    For our example here, we'll say the ticket number for the New Hire ticket is 59.
          • Once that ticket is submitted, the Action Rule will automatically run the Task which will then generate the other Tickets.    All of those tickets generated this way will become CHILD tickets of ticket 59.
          • Each ticket generated will be assigned to the appropriate Tech Group based on the Request Type of the ticket.
          • You can now go into the original ticket (Ticket 59) and see the current status of all the Child tickets.


          One of the nice things here is that within the Task definition, you can say that you want the tickets generated by the Task to automatically pull information from the original ticket down into the child tickets...so if you had the person that submitted it answer a bunch of custom fields, that info can flow right down to the child tickets if you want it to.


          Another nice thing is that you don't have to generate all the Task Element tickets at the same time...in the screenshot above you can see that task element #3 has "Status is: Closed" in the "Generate Next" column.  Essentially this is saying:  "When the task is run, generate tickets 1, 2, and 3, but then don't go to step 4 until step 3 is Closed...then generate tickets 4, 5, and 6, then wait for 6 to be Closed, then generate 7.    Often i would see people put Task Element 1 to be a "create an AD account" ticket, but configure that Task Element to wait until Task Element 1 is closed before creating the other tickets for Task Elements 2 through Task Element n.

            • Re: Onboarding process managed by Web Help Desk

              This process is exactly what we are trying to do, but we are having some issues.  We are trialing WHD now, looking to replace our current product, and this is the #1 feature we need to implement.


              We have set up a simple task with 4 elements, one to create an AD account, one to set up network stuff, one to grant security in applications, and one to set up the employee's computer.  I want the first task (AD account creation) to be created with the ticket, but the other three to be created after the AD account is created and that ticket is closed.  When I create a new hire ticket, it created the AD account ticket as a child, but when I close that one, none of the others are created.


              I would imagine it has to do with how I have my action rule set up, but have not been able to figure out how to do it.  We are looking at possibly creating a second action rule to trigger on the closing of the AD account ticket, but that is a bit clunky and then those tickets will be children of the AD ticket, not the initial new hire ticket.


              Any thoughts?

            • Re: Onboarding process managed by Web Help Desk

              I know SW released this feature with a lot of fanfare but for me, and I think the OP, I don't want an extra 10+ tickets just to on-board an employee.  A much better solution would have been to allow multiple assignments on a single ticket which is what other solutions do.  My workaround is to use the approval request flow for this.  All recipients know the process and "approve" the request when their task is done which then shows up in the single ticket.

              • Re: Onboarding process managed by Web Help Desk

                I see the merit with both ways of implementing this onboarding process as kellytice has described with the parent/child tickets, as that is currently how our process worked before (manually, prior to implementing WHD), but as kjette mentioned there seems to be more merit using the approval process as a "flow", maybe in combination with an Action Rule to inform all associated parties that an Onboard action has been initiated, with the approval process subsequently started.