Bulk access requests - best practice?

[galavodasal]

Hi all,

We're currently looking for a solution for bulk access requests. It should be noted that our catalog items contain a "Customer Info" field, basically a requested_for field. We also have a Business Rule in place that takes the user within this "Customer Info" field and makes the Request.Requested_for that user.

Currently, you can open an App Access form, enter a user and select access and then click "Add to Cart". From there, it would be nice if the manager could type in a new user in the "Customer Info" field, and click "Add to Cart again". Rinse, repeat.  

The problem is, the Requested For for each RITM ends up being the same user. I believe this is due to the fact that the Requested For field is actually a dot walk from the Request form, and since there's only one REQ but several RITMs, only the last RITM's "Customer Info" user is applied as the Request.Requested For.

Of course, this poses a problem when users look up tickets. Manager Bob will submit a ticket for Joe, Larry and Chuck, but the RITM's Requested For will say "Joe" for all three open items. This means Manager Bob has to open up each RITM in order to see who the request was actually for (I know he can hover over the info box to see a quick shot of the form).

What we're looking for is a way to submit several RITM's at once and have the Request.Requested For be respective to the user within the "Customer Info" field of the RITM.

Also, I tried the Clone Request feature but had similar results. If I turn off the previously mentioned Business Rule, Cloning Requests somewhat works. It works in the sense that the Request.Requested_for is the user(s) entered while Cloning, but the form itself is still the same, meaning the "Customer Info" user is still the same in each Clone Request. This makes the Clone Request feature useless, unless someone has a solution.

As far as the need for the Business Rule: our IT department typically submits requests for our users. If we didn't configure the Business Rule, the Request.Requested For would end up being the IT technician that filled out the request, and not the Customer. If anyone has any other solutions on that, our ears our open. This was configured during implementation.

Sorry if that was confusing!

Thanks,
Alex

[kristenankeny]

We have a similar situation. We added a new "Requested For" field to the base Task table and use this rather that the out-of-box Requested For field.

[galavodasal]

We ended up basically getting rid of REQs since they're not very useful in our environment. We added a new u_requested_for field to the sc_req_item table and then updated the necessary Business Rules to set that field based on the user entered in the catalog item.