In the Service Catalog, it’s almost *always* necessary to ask who the request is actually for, after all, someone might be submitting a request on behalf of someone else.
The Problem
By default, in the Service Catalog, the only place you’re asked who a particular request is being submitted for is on the second page of the “two-step” catalog ordering method (pictured below). Very few people use this two-step method however, and I would recommend against it if at all possible. That leaves us with a dilemma. How do we enable employees to submit requests for their superiors and coworkers? Better yet, how do we enable the Service Desk to submit requests for users who call in?
The Solution
In short, we need to somehow add a Requested For variable to every catalog item, and then somehow copy that value up into the Request.
Create a variable set that you’ll use on every single item. Call it something like “common_requested_for”
Create a variable within that variable set called “requested_for”. Make it a reference to the User table.
Add that variable set to every catalog item you create. Set the order to be 0 or 100, so that it shows up first.
Create a business rule on the Requested Item table. Trigger on Insert, and use the advanced script field to run: current.request.requested_for = current.variables.requested_for;
Downsides
If you use the Catalog Item Designer, there’s no simple way to use variable sets. You can still create a requested_for variable on every item though. In fact I’d recommend making it a preconfigured Question Type.
The Requested For on the request will be somewhat random if there are multiple items in a single request order, and the items are for different individuals.
Recommended Improvements
Create a field called “Task For” on the task table, and populate the Request’s Task For and the Requested Item’s Task For from this variable. (And also populate it from caller_id on Incident, etc.).
