Yes, I am referring to SRM:Request. My bad. I have already added AppRequestID to fields in View on SRM:Request. And actually, I did get it to display on the SRM console but it's ugly.
In 7.5 we added the AppRequestID to the Requests table on the SRM console & hid the REQ column. Didn't change any workflow; just the presentation. That was pretty easy. Doesn't appear so simple in 8.1. On Thu, Jun 12, 2014 at 10:38 AM, Carl Wilson <[email protected]> wrote: > ** > > Hi, > > I guess you are referring to "SRM:Request" as opposed to > "SRM:ServiceRequest" which is not an OOB SRM form. > > > > To display anything other the related RequestID from the "SRM:Request" > form would entail a large customisation as this form does not store the > underlying application fulfilment ID. The workflow queries this form to > return the Service Request ID by default. > > > > The fulfilment request ID is stored on the "SRM:AppInstanceBridge", so you > would need to add workflow to query this form using the appropriate > identifier e.g. "SR Req Number" and bring this back to the "SRM:Request" > form where it could be used to display. > > The other consideration is if you have multiple fulfilment there will be > more than one record returned in a search from the "SRM:AppInstanceBridge" > and you would therefore require additional qualification rules to identify > the current "Open" request (you could use the "App Request Status Code"). > > > > The other option would be to query each application in turn by the Service > Request ID to identify which application was used in the fulfilment > (inefficient). > > http://www.missingpiecessoftware.com/ > ------------------------------ > > > > Kind Regards, > > > > *Carl Wilson* > > > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Boyd, Rebecca > *Sent:* 12 June 2014 14:24 > *To:* [email protected] > *Subject:* Re: Displaying the App Request ID on the Service Request > Console > > > > ** > > It sounds like we have to decide one way or another: REQ # vs INC/CRQ #. > > > > Then we'll have to do some tinkering & possibly re-education. > > > > So back to my original question: > > > > Let’s say I want to display the actual HPD or CRQ number instead of the > REQ number on the Service Request Console, the "App Request ID" field on > SRM:ServiceRequests. > > It looks like Active Link SRS:SRK:Initialize_ServiceCall sets this field > when the console is opened. > > TemplateMyRequests_Request ID = $DEFAULT$ > > Even if we don't modify this, I am truly curious as to how this works. > > > > On Wed, Jun 11, 2014 at 11:20 PM, Tauf Chowdhury <[email protected]> > wrote: > > ** > > Rebecca, > > You'll have to find a happy or not so happy medium here. You've already > done the first step of creating the request on submit from the fulfillment > apps. On creation, whether it be from SRM or the other modules, I like to > only send the notification for the SRM request. This means turning off the > notifications for the creation emails of the other requests. > > Then, you're left with the "life cycle" emails of the fulfillment requests > which send out their own notifications. For this, I've left alone the INC > and CRQ numbers and accepted that these will be included. However, I > modified the notifications to have the following label, "REQ# (if > applicable)" > > Then, of course, I modified the filter for the notifications to include > the req #. > > What this does is arm the customer with all the information instead of > parts of the request process and cut down on the initial onslaught of > notifications during creation. > > Sent from my iPhone > > > On Jun 11, 2014, at 5:17 PM, "Boyd, Rebecca" <[email protected]> wrote: > > ** > > "Create Request on Submit*" is already set to Yes. Requests are being > created. > > > > My question is more along the lines of 1)What kind of a tracking # to > supply to customers and 2) Using email to communicate with customers. I > want the tracking #s in the email notifications to be consistent with the > tracking # they see in SRM. That includes using the "Email System" function > which defaults to the INC or CRQ #. > > > > > > > > On Wed, Jun 11, 2014 at 4:41 PM, Marcelo Martinez <[email protected]> > wrote: > > Sorry for my prev post. I tried to send a pic with the post > > Check out your incident rules and change rules > App Admin Console>Custom Configuration> Incident Mgmt> Advanced > Options>Rules > Same for Change Rules. > Set these to “yes” if you wish for them to get the REQ # instead of the > INC/CHG #. This will create a request for every INC/CHG and they will be > able to track their REQs in SRM. > Note: you may have to modify the outgoing email and exclude fields/data > you don’t use (or use). > > Also, your IT people should be able to search for REQ# from within the INC > ticket or CHG ticket. Look under “Additional Search” tab. > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > > > > > > -- > Rebecca Boyd > Application Administrator > Wake Forest University > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > > > -- > Rebecca Boyd > Application Administrator > Wake Forest University > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _ARSlist: "Where the Answers Are" and have been for 20 years_ -- Rebecca Boyd Application Administrator Wake Forest University _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
