| Author |
Message |
|
|
|
go to your integration section under your helpdesk settings. . . if you're still lost, check the documentation for your release . . .
|
|
|
Hi TechGuy,
It's been a while since we looked at this - where are we now in this regard?
Cheers
WeZ
|
|
|
Hi All,
Has this redesign been released yet?
Ciao
WeZ
|
|
|
Hi All,
Just to let you know the 2 step solution i posted earlier seems to be working very nicely. I also can add the timer to the view which lets me see quickly what requests are overdue the longest and can prioritise accordingly.
Ciao
WeZ
|
|
|
Hi TechGuy,
I take it you have not been able to progress with this yet?
Cheers
WeZ
|
|
|
|
all my escalation rules are triggered when the overdue conditions are met, which means all my escalation rules can mark the overdue requests.
|
|
|
Hi Joseph,
I really did not want to change the status of the request based on the reasons i provided in the feature request you mentioned earlier in this thread.
I might have found another way though, and I just wanted to bounce the Idea off you to see im not doing something silly here because it seems really simple:
1. On the Escalation Rule, under "Actions to perform upon escalation", set the Escalation Level to 1
2. Create a Timer Called "OverDue" and set the criteria where Escalation = true
Now on all your Service Quality and Service Breaches reports, you can use the "Overdue" timer and you can still get your reports without changing the status of the requests!
What do you think?
Cheers
WeZ
|
|
|
Thank-you for the update Haim. Looking forward to this release!! 
|
|
|
Haim wrote:Hey guys.
Although i can understand that status change is adding another action to preform in a service request, this is one of the ways SysAid was built to handle service requests and for me, as a SysAid user, it makes things easier for me when I'm looking at the helpdesk list.
I will bring your ideas regarding sending a notification to the admin/user even if the status hasn't been changed to the "higher ups" and make sure to bring you their comment.
Best regards.
Haim
Hi Haim,
any luck with the powers that be on this?
Cheers
WeZ
|
|
|
Michael.C wrote:Dear OCIO
We are currently re-writing our documentation for the Manager Portal and in particular customizing reports. The new documentation will likely be released towards the end of this year and promises to be far more indepth. In the mean time we will be more than happy to assist you with any customization of reports, simply submit a service to helpdesk@ilient.com.
Regards
Craig
Hi Craig,
Has this documentation been updated yet? where can I get a hold of it?
Cheers
WeZ
|
|
|
Hello,
I am having the same problem. Has this been looked into?
Cheers
WeZ
|
|
|
Hi All,
ok, I believe this will give me the functionality required - thanks!
Cheers
WeZ
|
|
|
Hi Haim,
Thanks for this guys. I will test it out over the next couple days.
Cheers
WeZ
|
|
|
Hi All,
When you go through the version history of a request, the Messages and History section does not update with the correct information for that version. I.E. The History and Messages always has the most up to date info and not the info relevant for that version.
Cheers
WeZ
|
|
|
Guys, Let not let the tail wag the dog here.
You shouldn't HAVE to Change the status when a response is received.
The fact of the matter is, all parties on the service request should be notified of any activity on the request regardless of whether there are category / status changes or not.
Status changes should in all rights be reserved for when the "Actual" Status of the request changes.
I have also had to implement the above 'change status' solution a couple weeks ago and in reality I have found that your admins are spending alot of time changing the status BACK to what it WAS before each e-mailed response. I'm not sure about the volumes for the rest of you guys but our workload for the past 30 days was over 700 service requests and when you have to change Statuses back to what they should be because of a 'workaround', not only does it bloat the "history" section of the request, but also impacts the performance of the department because more time is now needing to be spent administering the request versus actually working on the solution of the request.
So my vote is that this is a Bug, not a configuration issue.
Cheers
WeZ
|
|
|
