, 2007 3:41 PM
To: arslist@ARSLIST.ORG
Subject: Re: Escalation creating dup tickets
**
Thats the another odd part of it. Although the first firing indicates
that the escl failed, then the next log entry is the firing of the same escl
again, but if you wade through the push fields, you
, October 02, 2007 12:41 PM
To: arslist@ARSLIST.ORG
Subject: Re: Escalation creating dup tickets
**
Thats the another odd part of it. Although the first firing indicates that
the escl failed, then the next log entry is the firing of the same escl
again, but if you wade through the push fields, you
Re: Escalation creating dup tickets
**
I noticed duplicate actions but actions with no mappings on them.. I was
wondering what was with that too..
Joe D'Souza
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Pickering
GlacierChris,
What is the workflow behind the creation of the ticket?
I mean when the Escalation fires, is the Escalation directly creating that
ticket? Or is a Filter set to fire on that Escalation create that ticket?
What are the exactly actions on your Escalations as well as filters created
list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Monday, October 01, 2007 12:50 PM
To: arslist@ARSLIST.ORG
Subject: Re: Escalation creating dup tickets
**
Chris,
What is the workflow behind the creation of the ticket?
I mean when the Escalation fires, is the Escalation
] Behalf Of Pickering, Christopher
Sent: Monday, October 01, 2007 1:41 PM
To: arslist@ARSLIST.ORG
Subject: Re: Escalation creating dup tickets
**
Joe,
There are no filters firing on this. Only 2 escalations, one for US and
one for Row. Each escalation has 3 actions.
1. A push field
--
*From:* Action Request System discussion list(ARSList) [mailto:
[EMAIL PROTECTED] *On Behalf Of *Joe D'Souza
*Sent:* Monday, October 01, 2007 12:50 PM
*To:* arslist@ARSLIST.ORG
*Subject:* Re: Escalation creating dup tickets
** Chris,
What is the workflow behind
To: arslist@ARSLIST.ORG
Subject: Re: Escalation creating dup tickets
**
Chris,
What are the chances that both your escalations evaluate to True, thus
firing actions twice during the runtime of both the escalations
resulting in 2 tickets?
Joe D'Souza
-Original Message
Other than some scheduled, external event that could trigger a filter I don't
think its possible (i.e. create filter against EMAIL form and set up a
scheduled job in SQL to email the AR email account every X hours/days)
If you could elaborate a little more about what you are trying to
You could use an on interval active link to push fields to a dummy form.
Filters on that form could then fire to perform whatever action you are trying
to make happen.
I wouldn't recommend this for a number of reasons (the biggest being that the
few times I've had to look through log files
Well it sounds from your description like you already know how to do it.
Create the hidden Escalate Time field and make that a Date/Time field.
Create a filter that populates that field on Submit with $TIMESTAMP$ +
whatever your escalation time is in seconds. I'm assuming here that
that's
System discussion list(ARSList) [mailto:[EMAIL PROTECTED]
Behalf Of Kaiser Norm E CIV USAF 96 CS/SCCE
Sent: July 9, 2007 11:29 AM
To: arslist@ARSLIST.ORG
Subject: Re: Escalation
**
Well it sounds from your description like you already know how to do it.
Create the hidden Escalate Time field
To: arslist@ARSLIST.ORG
Subject: Re: Escalation
Sorry for my ignorance but when it comes to calculations, I'm lost. You
stated:
Create a filter that populates that field on Submit with $TIMESTAMP$ +
whatever your escalation time is in seconds
Let's say the Incident was submitted at 9:00 a.m
Sent: July 9, 2007 12:25 PM
To: arslist@ARSLIST.ORG
Subject: Re: Escalation
**
Yes-7200. 2 hours x 60 minutes x 60 seconds = 7200.
So the filter should fire on submit and then populate the field in question
with $TIMESTAMP$ + 7200.
Effectively, then, the filter sets the criteria
James,
An escalation is about the only Remedy way to do this. Here is an
excerpt from the Runmacro vs Macro in client thread from earlier this
month:
I recently did something very similar and encounter some of the issues
you are seeing. What I have is an escalation (because the report is
You will probably need to create a new date/time field...and every time the
diary is updated update that date/time fieldthen fire your escalation
off of that field instead of your diary
_
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of
I'm not sure if you can parse through that with an escalation, but you might
consider setting a hidden timestamp field through a filter each time the
diary field is modified, that way your escalation can just look at that
timestamp field.
_
From: Action Request System discussion
Mike,
I would create a working date field on the form, and set it to $TIMESTAMP$
every time there is an entry made to the worklog, then with your escalation,
you can check Status = 'Working' and Last Worklog Entry $TIMESTAMP$ - 129600
Hope this helps.
Rem
Date: Mon, 29 Jan 2007 11:58:55
That time would be hard to capture and use in a qualification in a Escalation
so instead why don't you use a Date/Time field specifically for that and have a
filter, which when the TR value of the diary is not null, set the Date/Time
field.. Run your Escalation against this Date/Time field
Is the diary required on each modification of the record? If so then
you can just do a check against the Modified Date field. If it is not
required then adding a new datestamp on when the diary changes would
probably be the best way to go
Fred
From: Action
Subject: Re: Escalation question
**
I'm not sure if you can parse through that with an escalation, but you
might consider setting a hidden timestamp field through a filter each
time the diary field is modified, that way your escalation can just look
at that timestamp field
: Re: Escalation question
**
I'm not sure if you can parse through that with an escalation, but you might
consider setting a hidden timestamp field through a filter each time the diary
field is modified, that way your escalation can just look at that timestamp
field.
From: Action Request
I have SD 7 without SLM and there are OOTB escalations.
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
John,
I use basically the same process. I add one more qualifier to the
escalation filter so that it doesn't fire every 5 minutes. In turn, my
process also calculates a new time to fire so that the escalation keeps
firing until someone responds.
Here's the qualification that I use:
. - paraphrased
by me
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Shellman, David
Sent: Friday, September 08, 2006 8:30 AM
To: arslist@ARSLIST.ORG
Subject: Re: Escalation reminder every X hours
John,
I use basically the same
That's just about the way I do that type of thingjust remember that
depending on your data you may want to make the status first in the query
assuming you have an index on status...any maybe add an index on ESC_Time
just to ensure your escalation isn't hitting the DB too hard
L. J. Head
John,
Personally, I would push the business to decide what should happen
instead of sending an email.
Like:
Auto assigning to the main Help Desk
Auto assigning to 'Submitted by'
Auto assigning to 'Submitted by's Manager
And MAYBE doing some email too. (or let you assignment emails do that
, 2006 10:26 AM
To: arslist@ARSLIST.ORG
Subject: Re: Escalation reminder every X hours
John,
Personally, I would push the business to decide what should happen
instead of sending an email.
Like:
Auto assigning to the main Help Desk
Auto assigning to 'Submitted by'
Auto assigning to 'Submitted
John,
Remember, that escalations by nature are singled threaded. If you can adjust
the workflow to utilize filters for the bulk of the processing you will be
much better off since they are by nature, multi-threaded. For example, if
your HD form has 1/2 mil or a mil+ records, running
We do something similar. What we do is on Create of a ticket we push
to a table called Pending Notifications. On any Modify of the ticket
we first delete any related records from the Pending Notifications (This
allows us to create any additional ones we need).
We run the Escalation against the
**
AR_ESCALATOR is
run with admin permissions, yes, maybe you have some workflow checking for
$USER$ and triggers filters? Try to add and $USER$ != "AR_ESCALATOR" in those
filters if so. /L ars
-Original Message-From: Action Request System
discussion list(ARSList)
nt: Sunday, September 03, 2006
9:56 PMTo: arslist@ARSLIST.ORGSubject: Re: Escalation -
Cannot change Assignee information
**
AR_ESCALATOR is
run with admin permissions, yes, maybe you have some workflow checking for
$USER$ and triggers filters? Try to add and $USER$ != "AR_ESCALATOR" in
201 - 232 of 232 matches
Mail list logo
