Enabling Bulk Orders in the Service Catalog for only some items

[Ben LaChance]

I'm currently working on building out several offerings for a Service Catalog.   As we've been moving along the project, it has become clear that we have two clear classes of items/systems access that people are going to be requesting.   The first is individualized one-offs that we have very specifically generated forms for.   The second is bulk requests for generalized access to certain systems or items.   Bulk ordering in the Service Catalog would be fantastic to use for the second, as we often have requests that are identical except for the requested for person for up to 50 different people at a time.   However, we can not enable bulk ordering on EVERYTHING because of the first category of individualized one-off requests.

With this in mind, how could I 'enable' bulk ordering for some items in the service catalog, and not for others?   If 'disabling' bulk ordering means some script somewhere that just removes the bulk order section view from the checkout, if it's on certain items, then that's fine. (Although ideally we would be able to place this script somewhere that we could identify the items it was active on in the script, and not on every individual item we didn't want bulk ordering for, since we have a large number of items.)   Any thoughts would be greatly appreciated.

[Jace Benson]

I did something similar, but not the same.   Pretty much folks wanted to decommission tons of servers, and they didn't want to have to put in tons of requests... So I made a UI Page to handle it originally.   Now that we've moved to Service Portal I made a widget / and page of it.

The logic was pretty much, Ask for the input you could use as what this is against, in my case it was ci's but list collectors stink, and so do glide lists, so we just used a text field, and on first server call, I validate, remove, and show what line items were not matched.   Then I hide that section, and show another hidden div, where I ask specifics for each server, there were 2 other questions on a server by server basis.

I had this originally submitting the requests via that Cart API, but after a timeout error, I just redirected them to a page and generated events, then have a script action handle the processing of each event.   The page would watch for the submissions but then they could leave with out issue.   Hopefully this helps.

[Ben LaChance]

I would really love to do something like this, but unfortunately since some of the requests involve systems access provisioning, for auditing purposes we really want to preserve the ability to report on requested for and individualized task completion for each person a request is generated for in a bulk request.   We had actually considered several solutions similar to the one you laid out prior to looking at bulk requests, but the separate tasks and tracking the person who access was requested for made them basically unworkable.   The situation is complicated by the fact that access to a couple of the systems can come in the form of EITHER a one off OR a bulk request, so reporting becomes a major pain if we don't use the same structure to track each access request.

[Jace Benson]

So, the example I provided doesn't change how the form works its still one/many Req's (as you dictate) and one/many RITM's (as you dictate) and the appropriate workflow tasks.   We've disable the ability to use the actual item but, if we made that item available, folks could request a singular item.

[Ben LaChance]

Oohhh, yeah, I wasn't seeing exactly what you meant the first time.   You wouldn't happen to have a copy of the UI page code that you used originally would you?   I haven't done a ton of work with UI pages, and we're not using the service portal yet unfortunately, so I know just about enough to get into some trouble, and that's about it.   That does seem like it would be something we may be able to use though, for sure.