| Author |
Message |
|
|
|
bump
|
|
|
|
Anyone?
|
|
|
Bump... two months, no replies.
It sounds like this may be specific to our install if no one else is having the problem. I guess I need to submit a helpdesk ticket to Ilient.
|
|
|
|
Why is it that activities disappear from the calendar once a ticket is closed? I need to be able to review/see the history of activities for closed tickets - how else would the calendar be helpful for having activities show up if they disappear once a ticket is closed?
|
|
|
|
Is there any way that I can convert an admin user into a regular user? I want their old helpdesk ticket history for tickets where they were the request user to still be accessible to them, but they have no need to be a SysAid admin any longer. Also if I can't convert them, we have to go in an rebuild all of the belongs to & all CI relationships, etc.
|
|
|
When I open a CI, I can click the Gear symbol at the top to set what the different "pages" should look like based on the CI type. I have customized these to be different for each different CI type.
The problem that I am finding is that when I click on a CI and open it, the system isn't automatically formatting the view based on the type of CI that I have opened. To get it to display correctly, I have to open the Gear symbol again, pick the correct type from the drop down, and then click save.
Shouldn't the software be matching up the correct type & view automatically?
Thanks!
|
|
|
For the rest of you chiming in on this over the years, I can tell you from almost 4 years of battling for this to be an option that I just don't think that "they get it".
If all correspondence regarding an incident is supposed to be maintained within the helpdesk system, but the helpdesk system vendor provides no mechanism for recording correspondence with persons other than USERS, this is a product level, major failure of the solution to meet its core business need.
There should be a way to designate vendor contacts or attach additional communications that are with vendors and non-users - from within the system & without having to copy/paste, forward, edit subject lines manually in a separate email client, etc.
I can understand that you don't want people licensing the helpdesk for one user and just putting the actual user as a CC on the helpdesk ticket to get around licensing. It seems ridiculous that someone with means to purchase licensing would go through that much trouble, but I understand where you are coming from. I think that the only people that would do that (break the law) are the ones that couldn't afford to purchase your reasonable base licensing, anyways. If I'm right, you haven't lost a penny (because they didn't have it to give) - but you've gained some marketshare/adoption (not a great arguement, but I had to offer something).
If you are worried about the "thiefs", just don't let people assign non-users to the CC on the helpdesk ticket itself (which I still think is a FAIL, just not as big). However, at a minimum, we should be able to send messages/emails from within the system to non-users and have the correspondence maintained along with the ticket.
If the limitation is because you are licensing the email functionality from a third party (a limitation of your own licensing arrangement), I would suggest you look into an alternative base platform for the email functionality as quickly as possible (and provide us with a roadmap/timeframe for this critical need). Not allowing us to include correspondence (that is only an attachment within the ticket itself) to a non-user is a major FAIL for the system.
We need an ITIL compliant solution in place this year, and the fact that SysAid will not consider this key business requirement has me scrambling to find another vendor. After the years of working hand in hand with Ilient, it will pain me to leave the platform because it has served us well in the past.
The fact that there is not even a roadmap for this core need is is the single factor that just kept me from cancelling our planned upgrade to the enterprise product/modules & annual maintenance (already had the link for payment and the temp license keys in hand - check with your sales team). I know that we're small potatoes and that the lack of our single purchase won't be enough to give this issue the attention that it deserves. But I would bet that we won't be the last to be forced to leave since most IT governance now expects this as a core functionality of their helpdesk system (capturing all correspondence in the ticket details).
|
|
|
|
So the CMDB relationship views will only show a max of 5/6 characters of the name of the objects? How could you even use the relationship views in the proposed way to assess possible impacts, etc.? I can't imagine 5/6 characters providing a human-intuitive unique identifier. This just doesn't sound right? Hopefully I'm misunderstanding the issue?
|
|
|
I previously had a custom filter item with Caption "Awaiting - Any" defined within the ${list.status.caption} for the Service Desk Default View. Upon upgrading to version 7, it has disappeared.
This filter was used specifically to display a combination of all of our "Awaiting" statuses (tickets that are out of our hands and waiting on someone/something else). For example:
"Awaiting User Reponse"
"Awaiting Vendor"
"Awaiting Approval"
"Awaiting Delivery"
"Awaiting Further Research"
"Awaiting Onsite Visit"
"Awaiting Maintenance"
We use these statuses to insure that our counters, escalations, etc. for active tickets don't get saturated with bad rules for tickets that can't be actively worked. We also use a counter to identify the amount of time that a ticket is in an "Awaiting" status compared to Response & Resolution counters so that we get a more realistic picture of how long a ticket is "sitting still" (that could otherwise be actively worked if more labor resources were available).
I'm hoping for help with 2 things -
#1 - Tactical Solution for my Incident
I can't find my notes on how I defined the filter originally, so I was hoping that someone could point me in the right direction. Also, do I need to check my escalation rules, counter definitions, etc. to see if the upgrade broke any customizations there as well?
#2 - Strategic Prevention for the Problem
For those of us that customize our views, filters, counters, etc., I think that it would be helpful if Ilient provided a checklist of the areas of customization (views, counters, filters, etc.) that might be affected by an version upgrade so that we know what areas to check during our pre-production testing of a new version. Some of these customizations being changed by an upgrade might not be noticed in pre-production testing (like counters) but could have an impact on our reporting/data if the counters aren't active for a period of time between update and finding the issues.
|
|
|
|
Misread the question.
|
|
|
I just read the question again. Deleting my original post.
|
|
|
|
Would a recurring Project Task work for your circumstance, or do they want it to report as part of your helpdesk statistics/reports?
|
|
|
With this workaround, when an admin BCC's the helpdesk using their own email address, the vendor's response won't go to the helpdesk record of the ticket. If an admin uses the helpdesk email address as the from, then the history in the ticket doesn't identify/track which admin sent the email to the vendor.
I like your workaround better than what we have had so far, but it still doesn't fully meet our needs.
|
|
|
|
I don't want to have to search for a particular piece/name of software. I want to use my approved software list as the filter, and anything else that is not a part of this approved software list should show up as an exception. That way if someone installs an unapproved piece of software (that we don't know about and don't know what to search for) we have a way of knowing.
|
|
|
|
Are you essentially talking about a Hardware/Software Non-Compatibility List? Sort of an inverse of the software requirements?
|
|
|
