Hi SDP Team,
I hope all are staying safe and healthy.
I have some recommendations for the Problem Module, which we are really trying to take advantage of but which is still not quite meeting our requirements.
Create an Icon for an Incident Associate with a Problem: I believe I might have submitted this a few years ago, but it still applies:
Challenge: During an outage, we can be flooded with requests that we would like to associate with a Problem Ticket (and we're in a hospital setting, so this happens in real time). Once a Problem Ticket has been created and announced to our support groups, they will associate the requests with the Problem Ticket. Once associated, however, there isn't a good and quick way to tell which have already been associated, so we often have to go back through multiple passes of the same ticket. With screen real-estate at a premium, it would be great to have a field indicating that the Incident is associated with a Problem. As a work-around, we've had to create a status of "Assigned to Problem" so that we can know, but we would prefer an icon that, when <clicked> opened the Problem Ticket.
Challenge: There doesn't appear to be a way to bulk assign Incidents to Problems.
How about allowing us to use the checkbox and Action button to Assign to Problem.
Challenge: It's difficult for us to find and attach Incidents from the Problem view.
There are only three search filters for Incidents in the Problem module: Problem Category - ""; Open Requests; Open Request; and All Requests. What we really need is to be able to see the tickets that are currently in one of our support groups. That would be a good first step. Even better would be to allow the end user to filter that list just like we do Request View filters.
Don't force us to publish work-arounds or solutions in the Solutions Module
Sometimes, a work-around is so specific to a particular problem that it doesn't need to be published in a KB article. Additionally, a simple work-around like: "Please wait 5 minutes and try again." We don't need to or want to make that a KB article, but we would like to have it as a documented work-around for our technicians.
Challenge: Notify Incident Requesters shows should be a BCC
We support multiple organizations. When we want to notify Incident Requesters, we don't want them to be on an email string that shows everyone else's email address, both from a privacy and a security standpoint.
Challenge: Efficient post-event clean-up
When an event is over and we have quickly identified the root cause, the most important thing for us is getting the word out and getting those tickets closed. What we would like to do is similar to how the resolution works in the Service Request: We put the solution into the resolution, we mark it as resolved, the incident requester is notified and the ticket is automatically closed if we haven't heard from them in some specified period of time.
For the Problem, I'd like to do the same thing. Put in either a work-around or a solution, mark the problem as resolved, have the problem add either the work-around or solution to each incident's resolution, notify the requester of each incident of the resolution, and then automatically close the incident according to the same automatic closure rules.
Thanks again for hearing me out. Keep up the great work.
Sincerely,
Adam Marks