how to implement a non-standard Service Request in the Service Catalog

[#1]

Hi all,

Our customer would like to implement 2 types of non-standard Service Requests. They are generic and have generic fields.

A couple of suggestions I have had already is to create a new table that extends Task ... or even create a new table that extends sc_request ... and build workflows similar to Change.

My preferred option is to build a Catalog Item with generic fields (more future proof etc.).

My challenge is where do I model the assignment, the approvals and the status (or phase?) ... should it be in the Request or in the Request Item? Assuming there will only ever be 1 Request Item per Request .... what is the best way to model this?

Lets say that the Request State gets driven by the Request Item phase .... that's fine. On which level should the assignement occur? ... and which level do the approvals rules work on?

any suggestions / best practise advice?

Etienne
Keystone

[Chris York]

We are in the process of moving our entire Catalog (400+ items) over to a Request Item centric view. We found the concept of a Request with Request Item difficult to work with since 95% of the Requests that came in were always a single Request Item.

What we did was put a Variable Set on every item that contained a "Requested For" variable. We then had a business rule that set the u_requested_for field on the sc_req_item table to the value in the Variable.

All approvals are now done either at the Item level or inline with the Execution Plan.

We basically ignore the Request. No user has any visibility into the Request and the Request is always immediately approved.

All email notifications are generated from the Request Item.

So far in our testing, this is working tremendously better than before.

-Chris

[#3]

Hi Cyork,

did you block the ability to order more than one Catalog Item? ... can I ask how you did that?

Etienne