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?

[david_legrand]

PROBLEM 1 : I think the "amazon like" cart is a good theoretical idea that I never totally successfully used in the reality. Is it because of me or is it because the concept of "amazon cart" isn't fully developed (several prices according some rules, the visibility over the items from the cart...), that I don't know

PROBLEM 2 : Quite the same issue than you, but the discussion usually finished by "we just need 1 item by request" and as the most important part of the workflow is on the item, for my implementations, we sacrificed the request several times.

PROBLEM 3 : My problem here is we have only one kind of cart. Or the carts for "home improvements" stuff, for gardening, for the day to day "food" shopping, for "clothes shopping" or at the airport aren't the same at all...

When I started to study (on a demo) "HR incidents and requests" I wanted to explore the different possible paths.

I tried the official plugin and said "ok, that is a way", then I started to think "they are incidents and SR". But while I was implementing my demo, I had this strange feeling that something was wrong because I was leading to a big mess by messing together IT / HR incidents and requests (with their specific particularities...)

So today, I'm not 100% clear yet but I think more and more using the record producer only OR to use the item part only as the "approval workflow" and pushing the delivery on the specific record (and not using Catalog Task unless for very generic stuff)

PROBLEM 4 : The non standard request, the standard Changes (record producer), the non standard request who are in fact an analyze who could be transformed into standard items.

As well here, sometimes I'll take opposite choices according the customer and the project and sometimes I'm totally lost to define clearly what is the absolute best solution between ITIL best practices, the requester experience, the fulfiller experience, the manager experience and the project constraints... I do think we can add this issue in the things ServiceNow (or other customers) could speak by experience.

But globally, we have all these questions because we are quite free with ServiceNow to use different paths, personally I prefer saying "f*****, which option is the best one in this case", than "I can't do that, it's not in the OOB"

[Nick105]

I'm currently in the same boat and so while in the midst of typing this I am going through some brain gymnastics in order to simplify the process.

I do get the idea of what it all means-

Request = The shopping cart

Item = Individual purchases stored in the shopping cart

Task = Operations to be performed in order for the purchase of the item to be completed.

Makes sense, but now for the trivial mind bend, how do our staff manage these in the easiest way possible.

From what I can tell it is being left up to the customer to decide as OOB it all currently goes on the road to nowhere.

So after some exhausting jumping of hoops and mind shuttle runs, I have come up with the following -

'Request' is not needed, the information contained doesn't seem at all useful for the action-er, it will simply take up unnecessary space in ones queue. So i'll either keep that non-addressed or make a queue for where it can hide until an automated closure takes place.

So onto 'Item', I believe it is important for the assignee to not only know their role in the request but also what exactly it is contributing too. It cannot be left out but at the same time I do not want to overload our staff with more jobs than is required.

So that brings us to 'Task'. Task is the breakdown of the action required and does contain the most importance of important information, due to Item also being desired I could arrange for it to follow the most recent 'Task' around like a bad smell but I believe that will only serve to confuse and bloat queues.

So while not yet in practice I am leaning towards the method of automating from the bottom up. 'Item' can be viewed through task and if required a 'Process Flow' may also be used to clear up who needs to operate on what first.

Closing of all tasks can generate a closure of Item which in turn closes the request.

Anyone know of a better way or see holes in my design be sure to comment.

-Nick

[tim_harris]

Once again I am crossing paths with rfedoruk.

I am running up against this very issue. In a perfect logical world this makes sense. In the real world everyone gets confused with the three tier approach and they only want one ticket per request. Have any of y'all worked around this? What solutions did you come up with for simple one ticket requests? I'm thinking of creating a separate adhoc requests table that uses variables and just using a record producer to drop everything in there.

[Uncle Rob]

Leaving for the day, but I'd love to help you on this.

Do NOT, under any circumstances, create a new table to resolve this.   You'd be stepping on a license landmine.

In short, you can abstract out the Request layer completely (its easier than ever to do).   Use the RITM as a customer facing abstract for "what they want", then let workflow send however many subtasks are appropriate to all the teams.   That layer can be effectively invisible to the user.   With some crafty notification definition... everyone can have their cake and eat it to.

You can hit me up at my username at wolfpackcs dot com and I'll send you some of my work tonight, or I'll be back tomorrow to check in on the thread.