I understand where you're coming from, however I think I can also see where BMC is coming from. The problem is that an SRD can involve a complex set of tasks that may involve several different record types. For example, if you create an SRD to onboard an employee, there will be multiple different back-end requests, some of which may include multiple tasks to different groups. In a case like that, if the user reopens the Service Request, which back-end request should be reopened? Where do you start? Do you start at the beginning and work your way through again? Do you start with the last back-end request on the SRD? What if the problem with the request's fulfillment is somewhere in between. Given that, I can see why they wouldn't want to design it to reopen the backend request, because there may not be any reliable way to know which record to reopen. You could potentially say that if there's only one back-end request involved that it should open that, but determining that fact may not be as straight forward as you would think due to how the system is architected.
Given that, I can see why they would only want to open a new Work Order. At least that way you are signaling to someone that there was a problem with the request's fulfillment, and they can determine where the problem is and which back-end request may need to be reopened. Lyle -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of SCOTT PHILBEN Sent: Friday, April 03, 2009 11:45 AM To: arslist@ARSLIST.ORG Subject: Re: SRM and Reopening Inicdents -- SOLVED Looks like I found the answer on BMC's website: Problem 20005347 Please refer to the updated Service Request Management 2.2.00 Release Notes page 16. These release notes were refreshed on the support web site, so be sure to have the most recent copy. Defect SW00261294 When working on the back-end requests created from a service request, you cannot reopen these requests (for example, an incident or a change) after they have been closed. Users can reopen a service request, but SRM has no process to handle situations when users reopen records from the back-end applications that are tied to the service request. This also means that when the Service Request is reopened, it creates a Work Order and does not reopen the Incident Huh? This is just shoddy work. If you give the user the ability to Reopen something, that ability should include all of the somethings that were previously opened. Having some stupid workaround involving Work Orders is not acceptable. Now I have to spend my time figuring out how to do it the right way. On Friday, April 03, 2009, at 12:04PM, "Savant, don...@dts" <donald.sav...@dts.ca.gov> wrote: >Yes, we ran into this issue and debated it with BMC but it is working 'as >designed'. The only thing we could do with it is route the Work Order to the >Service Desk and have them update the back office entry accordingly. > >-----Original Message----- >From: Action Request System discussion list(ARSList) >[mailto:arsl...@arslist.org] On Behalf Of SCOTT PHILBEN >Sent: Friday, April 03, 2009 8:02 AM >To: arslist@ARSLIST.ORG >Subject: SRM and Reopening Inicdents > >All: > >I have SRM 2.2 patch 002 and I have an existing Request which created an >Incident. When the Support Person Resolves the Incident, a Survey request is >created for the User. When the User fills in the Survey and selects the >"Reopen the Service Request" option shouldn't the system reopen the Service >Request as well as the related Incident? > >Right now it does not appear to. And reading the Admin guide for SRM I see >this: > >If a service request is reopened, SRM does not reopen the original back-office >requests that were part of the request fulfillment process. Instead, SRM >creates a >new work order. > >What? I am not even using Work Orders! I want the Incident to be reopened! >Does this sound right? Has anyone else tried this? > >Please let me know... > > >-scott philben > >_______________________________________________________________________________ >UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" > >_______________________________________________________________________________ >UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
