Hey Thad, Been there done that... I can tell you from my experience that you should avoid it if you can. We have a single AIF that a requestor can add multiple users to while also requesting multiple bits of access.
SRM, like any application that allows users to request services should be about the customer experience, and I can tell you now that adding in this type of functionality will make your form too hard to fill in and understand for the average user requesting access, particularly if you go down the same path that we did and make the access selection a drop-down menu which then gets added to a table on the form. I would go back to the customer and really drill down a lot deeper into the requirements you mentioned, questioning the business value and reasoning behind each one. Questions like "How many of your customers are likely to need a batch user request option?". Is the development time needed to produce this "nice to have" functionality worth it? In terms of approaching the problem, I would look at creating a separate service for batch requests which gives the customer a link to an excel spreadsheet template that they need to fill out with the appropriate info. Get them to attach this spreadsheet to the batch service and then investigate a method of importing that data into a loader form which you could then manipulate and drive into SRM from there. Regards, Ben From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Thad Esser Sent: Friday, 12 August 2011 10:24 AM To: [email protected] Subject: SRM 2.2 - Multiple Requestees, Multiple Services ** Hi, ARS 7.1 SRM 2.2 ITSM 7.0.3 I am being given a scenario having to do with SRM that I'm hoping someone has faced and can provide advice. We are working on bringing our current system access requests into SRM from an outdated in-house application. The customer is asking for a way that a single person (say, a manager) could request the same service (a system access request) for multiple people. The "request on behalf of" functionality requires them to first select the person, then fill out the SR, and then do it again for each person. What they would like is to be able to fill out the SR once, select all of the people, then submit it. They consider this "one" request and would like to track it as a single entity. They would also like any of the people on the request to be able to track the status of the request. They are being ambiguous on whether one approval would suffice, or if there should be an approval for each user. I'm pushing them to accept that each person/access combo is a separate request, but then they want a "common identifier" to tie them all together. Additionally, they want to be able to select multiple SR's and submit them all at once. The out of the box Cart feature pretty much takes care of this need. Although, since one of their scenarios is "3 pieces of access for 5 people as one request", the Cart solution doesn't help when there are multiple requestees. Anyway, I'm being pushed down a path of building out an AIF to deal with all of this, but I don't relish the idea of trying to incorporate the individual SRD questions into the AIF, plus the maintainability of it. Seems like they want me to completely rebuild SRM. So... does anyone have any thoughts on this? Suggestions of out of the box features I could use (SRM 2.2) to satisfy their need? ITIL Best Practices that I can shield myself with? Approaches that will help them see the light? Favorite brands of rum? Thanks, Thad _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ ________________________________ This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of its related entities "Suncorp". Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au. The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
