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.
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.
Have a look at tasks, pre templated tickets that are linked via a task run. Found in "Setup, tickets, tasks".
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:
- 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.
- 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.
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.
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:
When subject contains "SYSTEM ACCESS REQUEST"
When Tech Group is "Helpdesk"
When Status is "Closed"
Assign to Tech Group "BizApp"
Modify Ticket and set up status to "Open"
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.
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
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.
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.