Comments
-
Having the ability to duplicate a ticket due to it containing multiple issues would be very beneficial. Tim
-
That's already an option from the group ticket list. Tim
-
I believe you can use the rules engine for this and flag on specific Request Types on ticket creation. You can then assign it to a specific person.
-
Having read the discussion, and your rational behind this, why can't the tech just create a new ticket by hand? Thus picking the correct client and doing everyone a service by picking the correct request types? This is a non-issue. Tim
-
Besides running queries to get this data, which is only marginally helpful. This would be a big help identifying problems areas and training needs.
-
Support for modern interactions with the notes field would be huge! Tim
-
This is the same issue and resolution I'm facing. It just seems so wrong to have a tequest type per Tech Group. The ability to assign/change the Tech Group would greatly simplify this process.
-
So in this model there's still no way of pinning it to just a Tech Group and not a an individual person? It seems like the ability to do this should be there where I know it exists in other platforms.
-
Exactly. That's why you need to change that clients config to block emails from WHD. I attached a screen shot of it. Tim
-
But question, it seems like the padlock or "mark private" is broken in 12.2. The client can no longer see the ticket, but if they previously received an email on it, they can click the link and the ticket opens right up. Is this the expected response? Tim
-
Well that's not encouraging news for me at all since I'm facing this exact same issue of not being able to import devices from JAMF. Any idea where on the roadmap this is? Tim
-
The "First Level Resolution" is for the helpdesk folks as they are taking calls/emails. Each time they resolve a ticket on their own, as part of the Helpdesk, they "close" the ticket under this status. These staff also do other things, and are even handed tickets as an escalation (of sorts). The focus of the "first level"…
-
I am also using resolved as a status. I guess this is just not something SolarWinds wants to support, configuring that "closed" means. Tim
-
This sounds like a good enough reason to not use this feature. Are you seeing success with the auto escalation?
-
The issue with that is for some Request Types, there can be 3 or more different groups the ticket could be assigned to: Helpdesk, Technician, Sever. So hitting the escalate button would send it to the next group, possibly incorrectly. It would also send the escalation email to them. How to you manage events like this? Or…
-
OLD post, but any movement on this being fixed? Thanks, Tim
-
I guess I could have said which minor version I'm on, too. I'm on 12.2. But it just seems like every time I build a report incorrectly, and loop on something foolish, it locks the site up for everyone until it completes. When I open up another browser and try to go in, it just sits and spins because the thread is tied up.…
-
Oh you mean the "Fear and Loathing of Roadmaps: Why your PM won’t give you a date" didn't help you?
-
Some of these feature requests are from 5 years ago. Is there a timeline of actual implementation? Or is it just a guess that they will be implemented, eventually? Tim
-
You can set that client to have "Block WHD E-Mail to Client" enabled. Though this leaves a nasty message in each ticket about failed email messages. But still better than unwanted emails.
-
Perhaps you could add a new location group and set them the types are only visible to that location group? Then just don't add that location group to techs. Worth a shot. Tim
-
Hopefully someone else out there is using the Approval Process and can help me out here. Is it as simple as needing a new Request Type per location? Seems like the request type should be able to be applied to as many locations as needed? Next step is a ticket to SolarWinds. Tim
-
Seems like you need to add each location in the system as a Location Group. Then add the actual location as a location under it and assign techs to those groups respectively. When a client from the Middle School adds a ticket to any Request Type, it doesn't matter as it will flow to the "Technician" Tech Group and only…
-
Turns out an update to my CA solved the issue. But needed to submit a ticket to get this update. Tim
-
I'm (now) able to use WHD with multiple accounts with Office 365. I ended up needing to update my CA to make it happen. You may need to do the same. Just log a ticket with them and they will be able to help.
-
Did you ever get a response from this? Or log a ticket? I'll be needing to connect to Office 365 as well, soon, and possibly be facing this same issue. Tim
-
Here we have the ticket come in via email and drop into a specific request type. The helpdesk staff then updates the request type accordingly and that is what assigns it to the correct tech group. To help track this I added a custom field of "Ticket Origin" and the staff (for all tickets) selects the correct origin, e.g.…
-
So is there a question here? Or is this just a junk/spam post?
-
I'm not sure that's wise, or possibly really. Different industries have different regulations. Such as heath care, it's possible to have protected health information that not everyone may be privy to, in the tickets. Most ticket systems are designed so the end user (the client), is only ever able to see their tickets. Or…
-
It looks like what I want is still just a pipe dream. But it looks like the ability to change Tech Groups is a feature request of at least a couple people: