Service Catalog - Request Approval vs Requested Item Approval

[thisismichaelb]

Still jumping into Service Catalog.   Not sure I understand the difference between the Request Approval and a Requested Item Approval.

Is the Request record/workflow where you will always capture the approval?   Or can you also capture the approval in the Requested Item record/workflow?

Also, every single Request record appears to go through the same "Service Catalog Request" workflow.   Since a Request record doesn't really have any defining characteristics (ie config item/request item/etc) - what condition would you build to trigger a different Request workflow?   Or you just build one "master" Service Catalog Request workflow?

The wiki is no help (where does it even define requests and what they are?) and I'm not sure this question was asked here yet.

[thisismichaelb]

After thinking about it for a bit, is a "Request" just another approval in the workflow?   Like, I'll have a "Request Approval", but then on the Requested Item workflow, I'll also have any "Requested Item Approvals" I may need.

I guess it's just confusing seeing so many "Approval" stages...

[Slava Savitsky]

Hi Michael,

Request record represents the shopping cart and can contain one or more Requested Items. Each Requested Item has its own workflow, and the Request itself has one too. You can have approvals and/or tasks at both levels although you do not have to. You can choose not to include any activities at all in the Request worflow, in which case workflows of the Requested Items will start at once. For each activity, think of whether it is common to all items in the request or specific to each item and choose the most appropriate place.

For example, if every request needs to be approved by the requestor's manager, you may want to place it on Request level, so that the manager does not have to spend too much time approving each item individually. On the other hand, this way the manager does not have the flexibility to approve only certain items in the request and reject the others.

As for your question about multiple Request workflows, you can have a universal workflow or you can have several different ones for different situations (for example, one workflow per office or department). It is up to you and is only driven by your business requirements.

[thisismichaelb]

I guess I didn't think about starting the Request record workflow based on a condition for the "Opened By's" department/location/etc.   Clever.

Thanks for the input!

[randrews]

that depends on your internal process... for us it is   a 2 layer approach and neither is always required...

lets take the example of a new hire ticket...

the request has to be approved by the manager saying YES i approve this persons request as a whole...

inside the request are numerous items some of which will require no further approval <the lan id> some require approval by someone in their chain of command <tablet> and some require approval by certain groups <access to specific applications>

while the manager CAN use line item rejection to reject an individual item the responsibility to approve those is NOT the managers but the required approver... in our case for example the CIO has to approve a tablet.. but shouldn't have anything to do with the application access... and the app manager can approve the app but shouldn't be approving them getting a LAN ID...

so in short the request approval is used for someone authorizing yes this person does work here and the request itself is valid... as well as it is my employee i am ok with them having these items...

the item approval is <when required> an auditable trail of someone with authority to grant access to the item or cost.