Thanks Carey! That's actually exactly what I was looking for, the record-lock thing. I forwarded that information on to my manager, who will see if it is at all feasible to apply or duplicate. We are currently doing our best to resolve this with workflow, but old habits die hard. We have many people working the same queues, and so for now we are trying to get in the habit of immediately assigning something to ourselves if we don't want anyone else to touch it. We have one person who generally triages and assigns cases, but sometimes if you'd already spoken to a customer you want to take their incident before it is assigned to someone else. In that case, it's a race to see who gets to it first, you, or the supervisor assigning them. This is where we've been running into workflow issues.
Thanks again for all of the great info. I look forward to learning more about Remedy through this board! Joslin :-) On Feb 19, 7:11 am, Carey Matthew Black <[EMAIL PROTECTED]> wrote: > Joslin, > > First... Welcome to the world of ARS! > Second... Your post is dead on for this list and most welcome. > Third... I think you do not yet understand a few things about ARS. :) > > I would specifically pick at this statement: > " > In Remedy, however, there is no alert until you do try to save, and > all of your work is lost because the other person, unbeknownst to you, > was in the incident making changes. > " > > I disagree with that as a stated behavior of the AR System. > > Specifically what actually happens is that most fields allow for users > to fight over the change in values. However, workflow can prevent this > and some ARS fields do not allow "regression of content" at all. > > Let me try to be specific. > > Lets say one record is "fetched" by two users one second a part. ( No > users committed any changes to the record in that second. ) > > Then User "A" changes two fields: 'Status'( a selection field) and > 'Work Log'( a Diary field) to "Work In Progress" and "I am working on > the ticket". and "saves" the record to the Database. > > User "B" however, had to go get a bagel and when they returned they > updated the same two fields. However User "B" set 'Status' to > "Rejected" and 'Work Log' to "This ticket should not have come to my > group. Please reroute this incident.". > > When User "B" saves the record what happens is actually this... > > The ARS server checks to see if the record that is about to be updated > was updated AFTER the user fetched the record. ( This is part of the > API structure and is totally transparent to users.) If it was updated, > then the user is asked a question. I hate the way the question is > asked, but it is a question.... (on a v6.3 ARS server/client) > > " > This record has been updated by another user since you retrieved it. > (ARWARN 1203) > Saving your changes will overwrite the changes made by that user. Do > you want to save your changes? > < Yes> <No> (buttons) > " > > This maps to this "error code" in the system. (Really a warning is not > an error, but it is a system generated message all the same.) > > Ref: ErrMsgsGuide-630.pdf Pg93 > " > 1203 Warning > This record has been updated by another user since you retrieved it. > > The request you are attempting to save changes to has been modified by > another user since you last changed it. You can Save your changes over > the changes of the other user, or you can cancel the operation (not > save your changes), retrieve the request again, and re-enter your > changes. > > If you are updating a diary field, your changes do not overwrite > changes made by the other user. If you are changing fields where the > data you enter is supposed to be the final value, continue with the > operation (saving your changes). > " > > So... > > If the user answers "No" then their changes are, by the users choice, > never sent to the DB at all. However, the local window retains the > changes so if the user clicks the "Save" button again they get the > (ARWARN 1203) message again. Since this is mostly a trivial case so I > will focus on the user answering "Yes". :) > > If the user answers "Yes" then their changes "update" the ticket > without them knowing what User "A" entered/updated. > > If the change of the 'Status' fields value is regulated the update may > still fail if "Work In Progress" to "Rejected" is not allowed. (Or any > other values that were changed are disallowed etc...) If however that > is not a problem then the record will "end up" being 'Status' = > "Rejected". The interesting part is that the 'Work Log' will still > have both users entries with the time stamps of when they added the > information to the 'Work Log' ! > > So no data is "lost". Some data might be changed in an unexpected way, > but that is, IMHO, an application issue and not a "system" issue. > > It is also worth noting that this system feature can be disabled by > the AR System developers on your ARS server. ( The message is not > displayed to the user, but the system behaves as if the user saw the > message and clicked "Yes". AKA: ar.conf setting > "Changed-By-Another-Check:F".) > > However, after saying all of that about the base systems behaviour..... > > The feature your wanting might be best described as "record locking". > This can be done via ARS applications, but has to be built by your > developers. It is a topic that has been discussed on this list many > times and there are examples of how to do this already. > > Here is a link to a published example from an ARSList member: > > rrrLock - Generic Record Lockinghttp://www.rrr.se/en/ > Click on "Products" on the left then selected "RRR|Lock (free)" > (http://www.rrr.se/en/products/rrrlock.html) > > It should get your developers the general idea if this approach is > really what _has_ to be done. ( Personally, I do not like the design, > but some people just can not live without it. So it has to be built.) > > HTH. > > -- > 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 Feb 18, 2008 4:01 PM, Joslin <[EMAIL PROTECTED]> wrote: > > > > > > > I work for a university that just upgraded from Vantive to Remedy. I > > am by no means a programmer, just the person in charge of training my > > group on the program. I've figured out a quite a bit on my own > > (macros, reminders, etc), but am stumped on this one. We had a lot of > > stuff configured for our team, so we're not using an out-of-the-box > > version. I haven't come across any literature for this, but figured > > if anyone would know if this is possible, it's you guys! > > > Our current concern is this: We previously used Vantive for case > > management. One of the few really nice things about Vantive was that > > if someone else was in a particular case, and I opened that same case, > > Vantive would immediately pop up an alert stating that someone else > > had opened it first. This was very useful, because I would then know > > that any changes I made might not be saved if the other person in the > > case changed it first. > > > In Remedy, however, there is no alert until you do try to save, and > > all of your work is lost because the other person, unbeknownst to you, > > was in the incident making changes. Is there a way to program such an > > alert? If not, how do other users cope with this? I know that for > > alerts like Reminders, you have to program the notification in your > > profile. Is there something similar for incidents already being > > viewed by someone else? > > > I hope this is appropriate use of this group. Thanks in advance for > > the advice! > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > Platinum Sponsor:www.rmsportal.comARSlist: "Where the Answers Are"- Hide > quoted text - > > - Show quoted text - _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
