Three tiered Catalog Item structure - Critical viewpoints

[Uncle Rob]

When I first started my ServiceNow journey, one of the hardest concepts to wrap my head around was the 3 record layers of an executed Catalog Item: Request Item, Catalog Task, and Request.

I've only had the privilege of working for two ServiceNow customers, but in each case the user community found these three layers as confusing as I originally did.

PROBLEM 1 - DO PEOPLE REALLY CONSUME CATALOG LIKE AN AMAZON SHOPPING CART?

It seems so reasonable when people tell you the Request should contain all the things a person orders from the catalog "like a shopping cart", but after dozens... possibly hundreds of conversations with end users I'm left wondering if this is how people naturally think of it.   Do people go to the catalog to order a bunch of stuff... or do they go to it when they need a specific thing, only to get the specific thing?   After 5 years telling people its the former, I now have to say its the latter.

What's your experience?

PROBLEM 2 - WHO DO THE RECORDS MATTER TO?

Clearly the request number is handy for the consumer.   The RITM's are handy on occasion, but customers almost always perceive their transactions as being a single thing.   Clearly catalog tasks are the most beneficial to the executing teams, and not something the customer needs visibility to.   So who worries about the Request Items?   Or are they meant only to be an automatic middle layer with no visibility to anyone?   If that's the case, then why are they tasks instead of some Stage holding non-task middle tier?

PROBLEM 3 - CATALOG ITEMS DON'T PLAY NICE WITH TASK EXTENSIONS
Assume I drink the ServiceNow marketing Koolaid (which I do... Olympic swimming pools at a time).   I now have a process which integrates multiple facets of the business; IT, HR, Procurement, and Payroll.   Now lets say procurement and payroll each have a task extension table of their own.   Now you want to add those components of work to the workflow triggered by a Catalog Item.   Everything looks great on that wireframe but once you execute... "hey, where's that payroll task".   Well my friend, the payroll task is not linked to the Request Item.   So now you'll never know which consumed services are generating all the Payroll work.   Sure, you could fill the Request Item into the Parent field... but parent is a reference to TASK, not sc_req_item, so you can only ever dot-walk or leverage fields from Task.   Have you experienced this?   How did you work around it?

[tim_harris]

Licensing would not be an issue as all of the people using this are already licensed for createnow.

I have already abstracted the notifications. The requestor only knows about the RITM and the fulfillers know about both the task and the RITM. However, 95% of the time the requests are basic and only require one ticket. The fulfillers all just want one ticket to work and reference with the requestor. Also, as far as reporting they get confused with the whole 3 tier structure.

Do you still have reservations?

[Uncle Rob]

Well, having everyone CreateNow licensed certain solves one literal cubic &$*% ton of frustration, that's for sure.

Didn't know you had already abstracted out the REQ layer, and you do have a point that abstracting them out of Catalog doesn't remove their presence from reports.   I suspect that will still be at least a little confusing with a custom request type.   Going to give this some more serious thought, as maybe my own biases need adjusting.

[tim_harris]

I'll let you know what I land on. I'm still weighing my options and trying to decide what works best.

You can still share with me how you abstracted out the request layer. It might be better than what I did. 🙂

[JC S_]

Any updates on this?