10 Replies Latest reply on Aug 18, 2014 8:30 AM by kjette

    How is everyone else doing multi-team tickets like New employees?

    pdonnelly@cobizfinancial.com

      We have several internal processes that require multiple teams to take action on a single request/incident. With the inability for client information to be automatically copied to child tickets thru tasks, what is your work around?

       

      For example a new employee ticket we have at least three teams that need to take action. The initial ticket has an SLA associated with it (let's use 14 days for this example).

      The first team has to create accounts (AD, exchange, etc.).

      The second team needs to create application specific account configurations AFTER the AD accounts have been created. This is a perfect setup for a task, but the client info does not carry over.

      The third team (which defines the SLA since account creation doesn't take that long) needs to order/provision equipment. This team needs the 14 days and the clock starts when the initial ticket comes in.

       

      Again, using tasks would be great just from this perspective.

       

      From the Request type perspective, what do you do? Do you create three hidden (from clients) Request types that are specific to each team (New Employee - team 1, New Employee - team 2, New Employee - team 3)? How do you associate all four (initial ticket, and the three task tickets) to one another? Has anyone come up with an impressive action rule or series of action rules? Maybe use a rule to change the initial ticket so there is only three tickets?

       

      The different Request types make sense from a SLA perspective. Each team's (Tech Group) manager can be aware of any breaches or status of work items assigned to their respective teams.

       

      We also had the idea to step out of the ITIL structure and make the initial ticket a problem and then try to associate the other three tickets as incidents. This may help with the association but not the client information.

       

      As the initial question states, just curious to know what more mature implementations of WHD have done to overcome the client info and association gaps in the product.

        • Re: How is everyone else doing multi-team tickets like New employees?
          typhoon87

          We have a 2 request type that is only seen by HR new employee, exiting employee. Then use an action rule to create an approval process and auto assign the ticket. The approval process lets each team know that there is a new person and what dept they are in. Note not all people in approval processes and cabs need to be techs so some normal employees are in there as well.

           

          The only issue is currently it does not close when it hits the end of the line and it could be more powerful if custom fields could trigger steps or additional info provided instead of all steps for every ticket.

           

          We do not have internal SLA times for this.

            • Re: How is everyone else doing multi-team tickets like New employees?
              pdonnelly@cobizfinancial.com

              I am not sure I follow what you are explaining. The approval process runs a ticket in series where I need to run tickets in parallel.

               

              This would be such an easy process except for the beiggest glaring hole in WHD of not relating tickets and copying request details between them at creation.

               

              I wonder if employing the REST API would fulfill this need.

              Another option would be to see if a single email could generate 3 tickets. Then I would at least have the request details in three tickets, but not relationship between them.

                • Re: How is everyone else doing multi-team tickets like New employees?
                  conners

                  Have a look at tasks, pre templated tickets that are linked via a task run. Found in "Setup, tickets, tasks".

                    • Re: How is everyone else doing multi-team tickets like New employees?
                      pdonnelly@cobizfinancial.com

                      Pre-templated tickets are not what I am trying to accomplish. I need information carried over from the ticket that initiates the Tasks.

                       

                      Here is the scenario:

                      • HR sends in an email with certain new employee information.
                      • A ticket is automatically generated.

                      At this point I need two additional tickets created that contain the information from the email from HR for two other support groups.

                       

                      I may have stumbled onto a loop I can use to copy the information across to multiple tickets.

                      • Have an Action Rule based on certain criteria of the ticket generated by HR's email that will launch a task.
                      • This task will actually send an email to the WHD system's incoming email address (in essence creating a ticket via email).
                        • In the pre-templated email, I will use the ticket attributes from the initial ticket. This will copy the necessary information to the second ticket.
                        • The tags I believe I can use will be
                          • <ticket_id> to establish a poor man's ticket association (parent-child relationship)
                          • <client> to copy initiating requester's information
                          • <report> to copy the contents to the request detail
                          • <subject> for title of the initiating ticket
                      • Then generate an identical task to generate the third ticket with the same tags.

                       

                      Although not perfect, this may be a decent workaround for the limitation of Tasks. Those limitations being:

                      1. The initiating ticket does not list any child tickets it generates in a field or section similar to the Linked Tickets (Problem/Incident) or the Task Tickets.
                      2. The information like client and request detail are not copied

                       

                      Now to get the second and third tickets to be auto assigned, I believe I read somewhere in the forums, that you can specify certain things in the subject of an incoming email to set certain ticket attributes like request type, subject, client, etc.

                       

                      All of this is what I plan on testing to verify my plan. This is the major stumbling block or gap in WHD that is preventing us from moving forward with this product. I will post my results here.

                        • Re: How is everyone else doing multi-team tickets like New employees?
                          pdonnelly@cobizfinancial.com

                          Sending from the outgoing email address to the incoming email address has been coded not to work and reject the emails.

                           

                          The email tags are working great. I am able to copy certain aspects of the ticket the action rule runs against to a new ticket. However, what I have had to do is send the out going email to an email account that has a rule to forward certain emails to the incoming email address for WHD. CAREFUL, this can create a loop of email updates that will be continuous. You may need to tweak an email rule on Outlook to not forward emails with "(updated)" to the incoming email address.

                           

                          I am continuing my testing as this is a poor mans way of doing what WHD should do out of the box (in my opinion and others on this forum). I will continue to update my results here as I progress thru options.

                  • Re: How is everyone else doing multi-team tickets like New employees?
                    filip.nespor

                    Hello,

                     

                    at Solarwinds, we have several queues in WHD (e.g. for Helpdesk, BizApps, R&D etc..) and we use action rules for moving tickets between them. HR just need to submit a helpdesk ticket and the subject has to contain a specific word (e.g. SYSTEM ACCESS REQUEST) and WHD will take care of proper routing...

                     

                    The rule looks like this:

                    Criteria:

                         When subject contains "SYSTEM ACCESS REQUEST"

                         When Tech Group is "Helpdesk"

                         When Status is "Closed"

                     

                    Action:

                         Assign to Tech Group "BizApp"

                         Modify Ticket and set up status to "Open"

                     

                    Regards,

                     

                    Filip Nespor

                      • Re: How is everyone else doing multi-team tickets like New employees?
                        pdonnelly@cobizfinancial.com

                        This works great when there is one ticket. However, what we need is to have 2 (or 3) tickets generated from the initial HR request. We have three groups that all have the same SLA to complete this request. So if a single ticket is used then the SLA are reduced or divided by 3 so that the final SLA isn't breached.

                         

                        Using tasks doesn't work because the content from the initial ticket is not copied over to the related tickets. Also, there is no easy way to see the relationship between the three tickets only the to related task tickets have some indicator of the related tickets.

                         

                        Based on further testing and the limits of this system we are going to move to our second option - which is another system.

                          • Re: How is everyone else doing multi-team tickets like New employees?
                            filip.nespor

                            What about to use Action Rules and “send email” action? You can use almost all ticket attributes and if you have multiple queues with different mailboxes assigned, it might work.

                             

                            You can use these tags: (the most important are <subject> and <report> = body of the email)

                            • <ticket_id> = Ticket number
                            • <request_type> = Request Type
                            • <status_type> = Status Type
                            • <priority_type> = Priority Type
                            • <client> = Client's full name
                            • <client_short> = Client's first initial and last name
                            • <client_phone> = Client's primary phone
                            • <client_email> = Client's primary e-mail
                            • <assigned_to> = Party responsible for Ticket (Tech, Tech Group, or manager)
                            • <assigned_to_short> = Short form of <assigned_to> (uses initials for first names)
                            • <tech> = Tech's full name
                            • <tech_short> = Tech's first initial and last name
                            • <tech_phone> = Tech's primary phone
                            • <tech_email> = Tech's primary e-mail
                            • <room> = Room
                            • <Location> = Location
                            • <model> = Model number
                            • <subject> = Subject
                            • <report> = Report
                            • <due_datetime> = Date & time Ticket is due
                            • <scheduled_datetime> = Date & time Ticket is scheduled to be worked on
                            • <work_datetime> = The same as <scheduled_datetime> (backward compatibility)
                            • <work_time> = Work time recorded in Ticket Tech Notes
                            • <custom_1> = 1st custom field
                            • <custom_2> = 2nd custom field
                            • <custom_n> = nth custom field
                              • Re: How is everyone else doing multi-team tickets like New employees?
                                pdonnelly@cobizfinancial.com

                                As I mentioned earlier, the sending of an email out and back in is coded to prevent an infinite loop. You will need to use a specific email account that does nothing but handle this loop externally. That email account will need to have complicated rules to make sure the loop is not infinite.

                                 

                                The tags are very good at what they do, but there isn't a tag for an attachment with would also be helpful in our situation.

                                 

                                WHD has so much going for it but this key functionality is going to force us to look at other options.

                                  • Re: How is everyone else doing multi-team tickets like New employees?
                                    kjette

                                    Imo this is one of the biggest feature gaps in WHD and almost kept me from implementing it.  The new employee scenario is a great example where there is just no clean way of doing it.  We finally settled on an approval process where each area gets the "task" notification in the form of an approval request and all areas have been fully briefed on what it really means.  Once completed they click yes to approve/complete the task.  A very clunky way of doing it and one thats been submitted as a feature request.  Ideally we would have ability to have multiple assignments on a ticket or multiple task requests.