CSDM 5 Service Offering Definition 'rules'

[CynthiaF3123657]

Hello,

We are currently in the process implementing CSDM globally across organizations with decentralized services and have quite challenging routing use cases.  As we are defining our services I'm running across the use case where we have over 100 applications that multiple locations/administrators do access fulfillment for the same application based on the requestor's site.  

We have a single service catalog item for 'Application Access Requests' that points to our Service Offering table.  I would be able to achieve nirvana if I formatted the Service Offerings using the format example below and exposed them to our catalog item, but we are being advised that this is not in alignment with CSDM 5 because we're using 'access request' label in the name.    

Example:  

ServiceNow Access Request - Seattle

ServiceNow Access Request - NYC

ServiceNow Access Request - Dallas

We could even add a layer of filtering for the end user to initially pick the business service so the picklist would be more refined.

I'd love to get feedback as it seems when I read the CSDM 5 the Service Offering is really meant to be a variant of the business services and if those are our service variants then I do not see why it cannot be used that way.  Also, I'm not sure CSDM 5 was necessarily designed to solve organizational challenges and so we should be able to make it work for us in the way we need without massive reorgs.

Thank you!

[Mathew Hillyard]

Hi @CynthiaF3123657 

An access request is a catalog item. A service offering is a particular flavour of service available to one or more sets of subscribers. They're two completely separate objects within CSDM, but they can be related to one another. However a single Catalog Item for all (possibly thousands) of applications might be easy for users to navigate to, but not particularly useful when it comes to the supporting data. Each access request will have different questions required, data to be captured, approvals (and levels of approvals), tasks and integrations, and the danger is you end up with a behemoth catalog item and flow that becomes very hard to understand, manage, maintain and change.

With AI Search it should be easy for users to find the right access to any system - and with GenAI (Conversational Catalog Items), users don't even need to search for the right one anymore.

I'd recommend you consider dedicated catalog items to access each application. Yes, it is a ton of work, but I've yet to come across an organisation that was successful with the one catalog item to rule them all approach!

One of the benefits with the separate catalog item approach is controlling access and understanding your user base for each Offering.

Example with your request above for Seattle:

• Catalog Item: ServiceNow Access Request - Seattle.
  • Create a User Criteria record for the Seattle location (if there isn't one already and if you're using locations and location hierarchy properly as per CSDM).
  • Add this record to the "Available for" related list to filter access to Seattle users.
  • Add the Service Offerings related list to the Catalog Item form if not already there.
  • Add your (single) Service Offering for the desired app to the related list of Service Offerings
• Service Offering
  • Add the related list of subscriber users.
  • Build logic that each time a user requests a Catalog Item where your Service Offering is linked, add that user to the Subscriber Users related list on the Service Offering (this is strictly speaking not the original purpose of the several related list beginning with  "Subscriber", e.g. Subscribed by Company, Subscribed by Department - they were originally intended to limit access to Catalog Items, but this has been replaced with User Criteria). This is customisation in a strict sense but the business benefit greatly outweighs the technical debt.

You can now:

• View which Catalog Items grant access to a Service Offering per location.
• View where a Service Offering can be accessed across the globe by looking at the Catalog Items related to a Service Offering.
• Get a complete list of users who have been granted access to a Service Offering - meaning you can send targeted comms for relevant notifications instead of org-wide mails, although I appreciate if you're sending those emails outside of ServiceNow you can probably do the same from Active Directory groups.

User Criteria is super-useful to filter access to Catalog Items by various foundational data items - Users, Groups, Roles, Companies, Locations Departments, and you can even script a custom filter.

I hope this helps!

Mat

[CynthiaF3123657]

Thanks for the feedback Mat.   To clarify, our Service Offering form has a custom field on it for Requests.  Our single Access Request catalog item leverages the 600+ list of Service Offerings, fetches manager approval, and routes based on the assignment group in the Request field.  This works pretty well for us unless a single application has multiple routings based on location.   Only about 80 of the applications have this complex routing requirement.  This is where I want to create unique offerings as defined above, but were told that is not in alignment with CSDM 'rules'.  

[Mathew Hillyard]

Hi @CynthiaF3123657 

Your approach sounds similar to other customers I worked with. Some had upwards of 3,000 access requests. They went down the same path you have. It's a simple user experience and seems to work well until you try to add flexibility to route certain offerings a different way, or adjust the way approvals work across the board for a subset of offerings, or try to get meaningful data on who uses what, and then bit by bit the whole design falls apart. I've seen multiple orgs tear their service catalog down and start again with individual requests.

The service catalog was designed to have unique Catalog Items per thing being requested - that's why user criteria and other functions appear on the form. You bundle up Catalog Items into Order Guides where a bunch of items are often ordered together (e.g. a new user being onboarded), and configurable first-page questions define the rules that control which catalog items are shown when running the guide.

I can only imagine how you handle different levels of access for those 600 offerings (e.g. std user, power user, developer, admin) - when you also consider the possible questions for each access request, the single catalog item must be huge! By the way, the assignment group is an OOTB on the Service offering record (or use the Teams related lists if you require conditional support based on logic) and it's this field that should be used when assigning the requested item.

It sounds like you're hiding the complexity of routing in some kind of engine (code?) where this logic should actually be within one or more Flows triggered to run based on which Flow is chosen in each catalog item. It must surely be very hard to maintain, extend and change?

As for the user experience - users wouldn't have to do anything more than they do today.

Turn on AI Search then when a user types in SAP or Workday access and they'll get the right catalog item immediately as a card at the top of the search results. - no more clicks than finding the single access request, with the added benefit that they'll see related service catalog data such as KB articles. Even better, use Conversational Catalog Items and they won't need to access the service catalog at all 🙂

If you cannot change the design then you may have to add a location question to the access catalog then route logic based on that perhaps?

I hope this helps!

Mat