# Byte #13: Requested For as a Variable

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.

1. Create a variable set that you’ll use on every single item. Call it something like “common_requested_for”  
2. Create a variable within that variable set called “requested_for”. Make it a reference to the User table.  
3. Add that variable set to every catalog item you create. Set the order to be 0 or 100, so that it shows up first.  
4. 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

1. 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.
2. 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  
1. 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.).