David,
You may also want to include a check of the Priority in the Action as well.
For example, one of your T&C's might contain a Run If statement of:
'TR.Priority' != 'DB.Priority' AND 'TR.Priority' = "Urgent"
and another might look like:
'TR.Priority' != 'DB.Priority' AND 'TR.Priority' = "High"
With this, each time the priority is modified (between Urgent and High), a
new SLA Action is created in the SLA:TimeActionsInfo form.
But once the Priority changes from Urgent to High, you do not need nor want
the Urgent SLA Action to fire, thus along with your other Action criteria,
you might also want to include this in the Action's, Run If statement:
'Priority' = "High"
This ensures that the only Action that will fire is the one that was created
where the Priority was High, and the Urgent one will be ignored.
HTH,
Tim Powell
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:ARSLIST@LISTSERV.VISTAIT.COM]On Behalf Of Lazar, Todd
Sent: Monday, December 31, 2001 9:00 AM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: Help Desk SLA actions
**
SLAs take a bit of getting used to! If you think in terms of 'contracts' it
sort of helps. The Terms and Conditions definition is the 'contract'. In
your case it's based primarily on Priority and yes, use the 'TR.'
designation on your terms and conditions or else you will get a new SLA for
every modification on the ticket.
So when your priority changes, it in fact does change contracts. So you may
have an SLA for a Low priority ticket for "X" hours and a Medium priority
ticket has a "Y" hour SLA. When you switch from Low to Medium, the low
priority contract is obsolete and you are now running on the Medium
contract. Even though you see the 2 SLA entries, only the Medium one will
now execute. This highlights another important factor. The conditions of
the contract (Terms and Conditions) have to still be met if you want the
subsequent actions and measurements to be invoked.
In the 'out of the box' SLA, there are SLAs for group actions if the ticket
isn't assigned to an individual. Once the ticket is assigned to an
individual, the group SLA is ignored (and you don't even get a time
measurement if it is closed while assigned to an individual).
So, you may want to make a "blanket" SLA action if you want to always take a
measurement. Then subsequent SLAs based on the normal life cycle of the
ticket or based on more specific things like CTIs or assignment groups.
Todd Lazar
813-301-2912
tlazar@americanaships.com
-----Original Message-----
From: David Schoaff [mailto:dschoaf@KIMBALL.COM]
Sent: Thursday, December 27, 2001 10:06 AM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Help Desk SLA actions
**
When a call is submitted or modified in Help Desk our zAutoGnHPDxxx filters
check to see if the TR value of the Priority has changed (among other
things). If it has, they use rappreq to submit a new entry to
SLA:TimeActionsInfo.
The problem is when a Priority value is modified on a current call it
creates a new entry in SLA:TimeActionsInfo form in addition to the existing
entry. Therefore we get more than 1 set of escalations for the call or
escalations go to more than 1 group. This seems to be the out of the box
functionality.
I can find KB articles discussing the problem when the filter is firing for
a modification to any field and they say to use TR values to eliminate the
unnecessary actions. But these articles never discuss how to avoid
duplicate actions when the filters fire for valid reasons.
Is there someone out there that has worked around this that can point me
down a good path?
HPD 4.03
ARS 4.5.2
Oracle 8.1.7
Thanks,
David Schoaff
NT Support Administrator
Kimball International
Jasper, IN
__________________
_____________
You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org
__________________
_____________
You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org
__
You may also control your subscription options, including UNSUBSCRIBE, at www.ARSLIST.org
Previous Topic
Index