Service Catalog Workflows - Best Practice Discussion

[jshatney]

Service Catalog Workflows - Best Practice Discussion
11/21/2013

What are the best practices for Service Catalog Workflow development? The questions that I would like to explore are the following:

How many workflows is too many? Obviously, less workflows means less administrative overhead. Should there be a 1 to 1 correspondence with workflows to catalog items? Since each item has slightly different information that needs to be presented to the fulfillment group(s), how can we build a standard workflow that handles multiple items?

How do people utilize the "fulfillment group" field on the Catalog Item record in a workflow. How are people utilizing the related lists of "Approval User" and "Approval Group" in the Catalog Item record?

Using a standard workflow to cover multiple items, you run into issues with Delivery Dates and Associated SLAs. Has anyone come up with a way to overcome this issue?

I would love to see any configurations, customizations, or ideas that people have had when planning out their Service Catalog Item workflows.

[Stig Brandt2]

The answer below is based on a couple of service catalog implementations, all with internal fulfillment groups, external suppliers to fulfill the requested item.

Should there be a 1 to 1 correspondence with workflows to catalog items?

• I normally try to make one workflow supporting specific ITEM types, ex. one for technical service catalog items, another for services delivered from a business unit (non it, ex. marketing material), another for services (ex. consulting services or new business application projects) delivered by external vendors etc.
  
• This makes no sense, but due to restrictions in ServiceNow, specially regarding delivery time, you need to script/change to set delivery date
  
  Since each item has slightly different information that needs to be presented to the fulfillment group(s), how can we build a standard workflow that handles multiple items?
  
• I create tasks in the workflow with instructions to fulfilment groups, if that is not enough, I have used the knowledge module to create instructions and then add these to the task, based on the ordered item.
  
  How do people utilize the "fulfillment group" field on the Catalog Item record in a workflow.
  
• I use this field to set an overall responsible for delivering the item, I also normally have extended the item table to contain more than one fulfillment group, specific in our solution to business units and for external suppliers
  How are people utilizing the related lists of "Approval User" and "Approval Group" in the Catalog Item record?
  
• In the workflow, I have a generic approval rule, looking if there are values in these related lists, and if there is, the item needs approval, this to make it easier for our customers, instead of changing or adding a new workflow
  
  Using a standard workflow to cover multiple items, you run into issues with Delivery Dates and Associated SLAs. Has anyone come up with a way to overcome this issue?
  
• You are not able to use the same workflow with different delivery dates, I raised a ticket with ServiceNow, and they told me to create a workflow for each item, which we didn't do. Instead we use the deliver time on the item and have changed the cart and calculation to support that, we also are going to implement a calendar support with holidays and freezing period. But this is a lot of customizations — but no way around it due to customer demands.
  

[jshatney]

To give answers to my own questions and hopefully spur this discussion on:

Q: How many workflows is too many?
A: I've seen hundreds and hundreds in production instances. When I spoke to ServiceNow about it, they asked me why so many workflows. I responded that each one was slightly different and there was no good way to store slight adjustments based on catalog item (without painful, excessive scripting). I know the answer should be use as few workflows as possible for easier administration, but each item/sla is different and results in lots of workflows.

Q: Since each item has slightly different information that needs to be presented to the fulfillment group(s), how can we build a standard workflow that handles multiple items?
A: I've done some customizations to try and overcome this issue. The scenario I've seen is as follows:

Company A has 100 catalog items. They fit neatly into the same workflow pattern, but each one is slightly different. They have either 1 or 2 levels of approval and 1 or 2 fulfillment tasks. 90% of all their items fit this pattern. However, each item has slightly different approvals (may be manager approval and a group approval, may be individual approval and VIP approval) and different directions for the fulfillment tasks. Overall each item fit into 1 of 5 overall SLA buckets. (1day, 2day, 3day, etc).

Solution: On the Catalog Item form itself, I added customized sections that contain all of the workflow information. The workflow then references the item and pulls the approvals and task information directly from the catalog item. I created a total of 5 workflows (one for each SLA).

This allowed the client to gather all the information they needed for the catalog item and then import it all and they instantly had a fully functioning Service Catalog of 100 items, each with unique workflows (in theory), separate SLAs, but ONLY 5 actual workflows to a maintain.

Obviously, now there is a bunch of extra data hardcoded in the catalog item definition, but this also makes it easier for the client to update their items.

Any item that didn't fit the standard, we had to create a custom workflow.

Q: How do people utilize the "fulfillment group" field on the Catalog Item record in a workflow. How are people utilizing the related lists of "Approval User" and "Approval Group" in the Catalog Item record?
A: These related lists only work if there is 1 fulfillment group or 1 approval user/group. They seem handy enough for 1 task workflows, but not much else. You also are not able to use items like current.request.request_for.manager to populate approvals here.

Q: Using a standard workflow to cover multiple items, you run into issues with Delivery Dates and Associated SLAs. Has anyone come up with a way to overcome this issue?
A: I have been able to script the delivery date, but it still shows incorrectly in the item itself before checkout. I have not been able to figure out how to dynamically assign an SLA to a standard workflow.

I'd still love to hear any additional ideas or suggestions for BEST Practices for Service Catalog item workflow building!

Thanks

[tmwrapelee]

Service Catalog is brand new for us.
(1) I'm curious as to how you have utilized the Service Request workflow for all RITM's. We would rather not have multiple approval tasks for every RITM. However, we do not wish to use the SR workflow for ALL of our RITMs. Do you have more than one Service Request workflows for specific RITMs or Order Guides?
(2) The same issue has occurred for delivery/installation. For some orders, we would rather have one fulfillment task for several RITMs rather than one per RITM.
(3) Also, how have you presented the cart information in your delivery/installation tasks? (i.e. quantity, price, unit price, etc.) I would love to add them to the fulfillment catalog task. I was able to add the requested_item.price and requested_item.quantity, but not the unit price. Also, is it possible to utilize the ss Order Status view of My Requests (sc_request.list.do).
(4) How did you change the cart to identify a new delivery date? Does this apply then to all RITMs?

Thank you in advance for your advice in this matter.
Regards,
Theresa Wrape-Lee

[alangross]

Eventhough this is quite a old thread I think this is a very interesting topic.

I'm currently exploring the detailed functionality regarding catalog and request fulfillment.

And I just asked myself exactly this question - should I be truly creating 1 workflow per catalog item? Right now I came to the conclusion that this might be truly the concept in case there are variables on the catalog item which are relevant to be seen by the fulfillment teams on the catalog tasks.

At least out of the box the variables are not shown on the catalog task if not explicitly mapped to the corresponding task within the workflow editor. Which leads to the situation that a workflow can only be shared with multiple items in case they use exactly the same variables. From my perspective not a very smart concept.

The variables are the piece which normally are different on each item e.g. Enduser Hardware Items -> 

- a monitor will asks for the size

- a keyboard asks for the layout

.. despite that the workflow might be the same.

I'm quite suprised as well that it seems to be impossible out of the box to show variables on tasks without using workflows e.g. if using a execution plan. Obviously the parameters (variables) of an item are relevant for the request fulfillers. It's clear that this can be customized (e.g. copy variables from requested item to task using business rules) but this could be solved better by ServiceNow OOB.

Question to the ones following the concept of sharing workflows for multiple items of same kind - How do you manage to show the variables on tasks without to configure it within the workflow?

Regards,

Alan

-- Update - I meanwhile figured out, that there is a flag called "global" that allows to show a variable by default on all tasks within the workflow (it is OOB not shown, asking myself why-- is it deprecated maybe?)