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_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
