Thank you very much for this feedback. You are correct in your assumption that I have not done much ARS development work. To complicate matters (for me) my employer will not spend the money to have me properly trained in ARS development.
I definitely do not want to over-complicate the solution. We are a 24x7x365 operation and our service targets are rather simple at this point in time. I will therefor follow your advice and develop the active link. Again, thanks for the feedback. I really appreciate it Richard On Oct 19, 6:22 pm, Carey Matthew Black <[EMAIL PROTECTED]> wrote: > Richard, > > I think you maybe over complicating things a bit. > > The real difficulty is in defining the formula for the calculation. > However, I will talk thought a very simple example and see if this > idea might work for you. > > Let us say that you have three priorities and for each priority there > is a fixed amount of time that will be used. So... > > Priority 1 --> 1 hour > Priority 2 --> 8 Hours > Priority 3 --> 24 hours > > If the math is as simple as that AND you are working with a 24x7x365 > business then you might only need three filters that fire on Submit to > set the 'estimated resolution date' = $TIMESTAMP$ + <number of seconds > for the given Priority> > > However, if you do not have a 24x7x365 business then you should look > at the Application-Bus-Time-Add functionality to avoid setting the > value to business hours when the business is not open. > > But you also mentioned that you have the SLA out of the box > application too. I would hope that the functionality in SLA would be > able to "figure out" when the record should be complete. ( Although > the value may not be in the 'estimated resolution date' field, the > value should be knowable by the support agent. The agent might even be > instructed to input the value that SLA calculates into the 'estimated > resolution date' field.) > > HTH. > > Also it sounds like you have not done much ARS development work. ( So > please forgive me if this is not the case. ) Due to the complexity of > the Out of the Box applications I would suggest that if you are going > to try to get the application to "use the SLA" date that you do not > try to do it with an ARS Push Action. Instead, I would suggest that > you add an active link (that fires on After Submit) to pull (via a > SetField Action) the value from the related SLA record. The hardest > part should be getting the Set Field qualification correct. > > Good luck. > -- > Carey Matthew Black > Remedy Skilled Professional (RSP) > ARS = Action Request System(Remedy) > > Love, then teach > Solution = People + Process + Tools > Fast, Accurate, Cheap.... Pick two. > > On 10/19/07, Ri Mez <[EMAIL PROTECTED]> wrote: > > > > > Thanks for the input DJHuang . I was hoping for something that > > wouldn't involve creating a new form (I've never done it yet) but it > > looks like I need to start learning how to do it. > > > What I was wondering was if it's possible to use SLM to push a value > > to the 'estimated resolution date'. My biggest problem is how would I > > get the calculated date? > > > The work flow I'm thinking of goes like this: > > 1. An incident is created. It matches a service target (say 24 hours) > > for resolution > > 2. The 0% milestone would take the service target time (say, 24 Hours) > > and calculate the time of resolution by the reported date of the > > incident. So if the reported date was 1.10.07 5:12:46 PM the pushed > > value would be 2.10.07 5:12:46 PM. > > 3. This value would be pushed to the estimated resolution date field > > of the incident. > > > Is there a way to have ARS calculate this? Or am I just going with > > the completely wrong approach? > > > Thanks, > > Richard > > > On Oct 18, 2:11 pm, DJHuang <[EMAIL PROTECTED]> wrote: > > > Hello, > > > > Pardon and correct me for typo or poor grammar if there's any. > > > I have similar situation but need to calculate based on user's site. > > > But I think it's not that different. > > > > You can create a form, keep the mapping in the form like: > > > Priority=High, ETA=1hr, EstResolved=2hr, something like this. > > > Then you need to compose a filter to calculate and push the value. > > > > 1. Create a filter when priority is modified or has been set a value. > > > 2. Use the value of Priority as keyword, lookup in the form you just > > > created, you get the ETA and EstResolved factor accordingly. > > > 3. Use Application-Bus-Time-Add sort of functions to calculate the > > > real ETA EstResolved date/time. > > > 4. Push the calculated value back to the incident ticket. > > > > Hope this could help a little bit. > > > > DJHuang > > > > 2007/10/18, Ri Mez < [EMAIL PROTECTED]>: > > > > > Hi Everyone, > > > > > I've a situation right now where the IT Mangers are requesting that > > > > Remedy be able to calculate the estimated resolution date > > > > automatically based on the priority of an incident. As far as I know > > > > this functionality is completely missing from Remedy. > > > > > Does anyone have any experience with this type of requirement? If so > > > > how were you able to provide it? > > > > > The only thing I can think of right now is tying in the Service Target > > > > of the incident to the "estimated resolution date" field. > > > > Unfortunately I'm not sure how to tackle this. > > > > > All feedback and comments would really be appreciated. > > > > > thanks, > > > > Richard > > > > > _______________________________________________________________________________ > > > > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgARSlist:"Where > > > > the Answers Are" > > > > _______________________________________________________________________________ > > > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgARSlist:"Where > > > the Answers Are" > > > _______________________________________________________________________________ > > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgARSlist:"Where the > > Answers Are" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgARSlist:"Where the > Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
