The Service Catalog order-on-behalf process allows a service request initiator to order a service on behalf of another person, the intended customer. A drawback of this approach is that the intended customer must have ordering permissions for the service. This contradicts some corporate policies where, for example, IT or administrative personnel should be able to order services for other people, but people not in the IT or administrative roles should not be able to order these services for themselves.

Without service items and service item-based dictionaries, a workaround for this situation is possible but hardly ideal. An initiator could choose the person for whom the service was intended (using a person-based dictionary), but there was no way for that person to be able to track “his” requisitions. This situation is remedied by the use service items and service item-based dictionaries. An initiator can order a service (and provision a service item) and designate a chosen person as the customer. The customer would then be able to monitor the request in the form of a service item that would appear in his Service Items page.

The procedure for implementing this functionality is fairly straightforward:

1. Design the service item.
2. Create the service item-based dictionary, being sure to include in the dictionary the CustomerID and OrganizationalUnitID. Optionally include a user-defined Status field, which can be updated as the delivery plan progresses.
3. Include the SIBD in an active form component.
4. Create a person-based dictionary to allow the initiator to choose the customer for the service item. Include this dictionary either in the same active form component as the SIBD or another form component—as long as both dictionaries are included in the service.
5. In the active form component containing the person-based dictionary write two rules as shown below, to copy information on the chosen person to the service item-based dictionary.

Figure 1. Rule Dictionary

An administrator is now able to order the service for various customers, and the customers can see the service item in the Service Items page or My Items portlet (provided they have been granted the My Services 360-Degree Consumer or Professional role.) If the service item has associated services for which the owners of the SIs have ordering permission, they are able to order those services directly from the Service Items page.

A drawback of this approach is that the requisition would not be searchable by “Customer”, within Service Catalog’s online modules, including Reporting and Advanced Reporting. In Advanced Reporting, the Service Item’s Customer replacement dictionary (in the example above, SICustomer) would need to be reportable.

You should generally not have to write a SQL query using the service items, history and subscriptions table. Most of this information is provided to users via the My Items portlet and page. However, it is possible to write a data retrieval rule retrieving information from these tables. For example, perhaps you do not want a user to request a service which provisions a service item if he already has one.

In order to write SQL-based data retrieval rules, you need to know a little bit about the table structure.

• As specified above, the name of the table corresponding to a service item is the item’s name prefixed by “Si”. So, an SI with the display name State of the Art Laptop, with a table name of StateOfTheArtLaptop has a corresponding table in the database named SiStateOfTheArtLaptop.
• How is that table related to ServiceItemSubscription? The easiest way to join it is on ServiceItemTypeName. So, if you want to get the subscription information for a State of the Art Laptop named joe-nov13-2013, this query works:

select * from SiServiceItemSubscription 
 where ServiceItemTypeName = 'State of the Art Laptop' 
   and DisplayName = 'joe-nov13-2013'

Or, you could get a list of all State of the Art Laptops by executing this query:

select*from siserviceitemsubscription sis
join siStateoftheArtLaptop al
on al.PrimaryID = sis.ServiceItemIDpredefined
where sis.serviceitemtypename ='State of the Art Laptop'

• And then how do I get from there to the ServiceItemHistory records? The key is the PrimaryID in the Service Item Subscription equals the OwnerID in the Service Item History. So:

select sih.*, sis.*from SiServiceItemHistory sih
join siServiceItemSubscription sis
on sih.OwnerID = sis.PrimaryID 
where sis.ServiceItemTypeName ='State of the Art Laptop'
and sis.DisplayName ='joe-nov13-2013’

Export/import is provided primarily for backward compatibility with previous versions of Service Catalog. It provides a way to copy or “clone” an existing service by downloading the service definition to the local workstation; modifying the service name; and importing the revised service definition. Cloning a service is best accomplished by Copying a Service.

Service Designer includes the ability to copy a service definition. Copying a service copies the complete service definition, including any associations with keywords and categories as well as the associations to included active form components.