Various issues
I am now in more serious need of properly-functioning custom views, so I am going to complain again. Custom view criteria do not work properly, period. If you specify any criteria for assigned technician, there doesn't appear to be any way to make it show unassigned requests as well, no matter what I do, even though "none" is a selectable option when choosing technicians for the view criteria. Here is the view I'm trying to create. I would like somebody from AdventNet support to try this and see just how impossible it is.
I want to display requests assigned to (out of 20 technicians) Technician A, Technician B, Technician C, and requests not assigned to any technician, in a group or otherwise, and limited to just requests that have not been closed. Alternatively, I would want to see all requests in two specific groups regardless of which technician they're assigned to, and also all requests assigned to myself, and any requests not assigned to a technician, in a group or otherwise. Both should not be that difficult to create, yet, SDP does not handle them properly, specifically in regard to showing unassigned requests. I think if you could just fix it so that unassigned requests are not omitted when you give the criteria (for example) "technician is none" or "technician is not Technician A", then the situation would be much improved. Right now my biggest problem is that applying any technician criteria omits all unassigned requests, which is a problem.
My goal is to not have to constantly switch between different views, hoping I don't miss something. Of course, the whole reason this is a problem is that we can't assign individual requests to more than one technician at a time. Because of that, we have been leaving those requests unassigned, and of course then nobody gets notifications about updates to the request because SDP isn't smart enough to forward those notifications to all the members of the group. I just had an idea to create dummy technicians with email addresses that get forwarded to all the necessary technicians, which would help by getting the notifications to us. However, that in turn will make said requests disappear from the standard "My Open or Unassigned" view. Therefore I'm trying to create a single view that shows us all relevant requests, but as it is now, we'll miss new unassigned requests unless we check our email first. This is beginning to feel like a "chicken and the egg" scenario.
Sorry for ranting so much, but I'm starting to get frustrated at how long it's taking to fix these basic problems. So in summary, I would like to know what the status is for fixing one or more of the following issues:
1. Forward notifications for unassigned requests in groups to all members of the group
2. Fix the custom views to allow displaying of unassigned requests, even when specifying technician criteria
3. Allow assigning of requests to multiple technicians simulaneously
These issues should all be fixed, but the last one is the most important to my company. It is one of the features our old helpdesk system had that we are missing very much. I have been asking for multiple technician assignment since we started using SDP on v5.5, and I have yet to receive word on the schedule for implementation. I look forward to hearing from the support team soon regarding these issues.
Sorry for being such a pain.
I want to display requests assigned to (out of 20 technicians) Technician A, Technician B, Technician C, and requests not assigned to any technician, in a group or otherwise, and limited to just requests that have not been closed. Alternatively, I would want to see all requests in two specific groups regardless of which technician they're assigned to, and also all requests assigned to myself, and any requests not assigned to a technician, in a group or otherwise. Both should not be that difficult to create, yet, SDP does not handle them properly, specifically in regard to showing unassigned requests. I think if you could just fix it so that unassigned requests are not omitted when you give the criteria (for example) "technician is none" or "technician is not Technician A", then the situation would be much improved. Right now my biggest problem is that applying any technician criteria omits all unassigned requests, which is a problem.
My goal is to not have to constantly switch between different views, hoping I don't miss something. Of course, the whole reason this is a problem is that we can't assign individual requests to more than one technician at a time. Because of that, we have been leaving those requests unassigned, and of course then nobody gets notifications about updates to the request because SDP isn't smart enough to forward those notifications to all the members of the group. I just had an idea to create dummy technicians with email addresses that get forwarded to all the necessary technicians, which would help by getting the notifications to us. However, that in turn will make said requests disappear from the standard "My Open or Unassigned" view. Therefore I'm trying to create a single view that shows us all relevant requests, but as it is now, we'll miss new unassigned requests unless we check our email first. This is beginning to feel like a "chicken and the egg" scenario.
Sorry for ranting so much, but I'm starting to get frustrated at how long it's taking to fix these basic problems. So in summary, I would like to know what the status is for fixing one or more of the following issues:
1. Forward notifications for unassigned requests in groups to all members of the group
2. Fix the custom views to allow displaying of unassigned requests, even when specifying technician criteria
3. Allow assigning of requests to multiple technicians simulaneously
These issues should all be fixed, but the last one is the most important to my company. It is one of the features our old helpdesk system had that we are missing very much. I have been asking for multiple technician assignment since we started using SDP on v5.5, and I have yet to receive word on the schedule for implementation. I look forward to hearing from the support team soon regarding these issues.
Sorry for being such a pain.