Service Offering Visibility and Subscriptions

[Aaron_Braun]

Per SN KB2056057 (not authentication walled) the cmdb_ci_service table is not visible to users without the following roles:

• dependency_views
• sam_core_user
• app_service_user
• sn_cmdb_user
• ITIL

This create a chicken and egg situation that now standard users with snc_internal are not able to see any business services for selection on things like an Incident Record producer. How are we supposed to present services and their subsequent offerings for things like record producers or catalog items so they can potentially select and request subscription to them?

User case - Service shows it's offerings that a user may want or need access to via subscription.

They can't see related catalog items for the service or offering if they are not subscribed and currently the only way it looks like someone can be subscribed is if the service owner manually goes in to Service Builder and updates their record with their information. Which a request can't be made to notify the Service Owner that this is desired.

[Aaron_Braun]

That to me is absolutely ridiculous amount of hoops to jump through to be able to serve up something that I should just be able to point to a filtered list on the existing data. Especially because this requires me to also eat up a table allowance just to mirror data. 

[Mathew Hillyard]

Hi @Aaron_Braun 

It sounds like what you are trying to achieve is similar to Now Assist’s conversational catalog items feature. You ask VA you want to get access to some software, it asks you what you want - you can either browse or give it an answer. It then walks you through the item without you ever seeing a catalog item and creates the req item and presents it back to the user. Yes you need all the catalog items to be created but you have the same outcome - a single unified interface where users can request anything without having to search for it. All without the complexities of building a single software catalog item for every piece of software, each with potentially different support and fulfilment requirements. Even AI Search will present the most suitable catalog item in a card at the top of the search results (“recommended”). 

I know that SN won’t charge you ITIL licenses if end users can access service offerings, so if the above is really unacceptable then just create a table read ACL for Service Offering for operational records for snc_internal and then field level ACLs for only those fields users should be able to see and keep the rest locked up tight.

I will say that in ten years and many service catalog implementations this limitation has never come up. I’ve seen customers try to build a single catalog item for all software and it became an unmanageable mess. Requirements changed over time and changing the process for one item became impossible. I’ve even helped customers go back to individual catalog items for each request. But the great thing about the platform is that it can support different approaches.

I hope this helps!

Mat

[Aaron_Braun]

This is also assuming everything is software related. If that is the case then we have software models. In this use case this is association with a "persona" or more of a pure service offering. In your example though there would need to be a catalog item per offering. Instead we don't want the 1000+ individual catalog items. We want a single catalog item with a drop-down of all the options and we can't present that without duplicating all the service offerings in something that is visible.

The KB clearly states they disabled read access for snc_internal users which is my rub.

It's pretty ridiculous for the model to be 1:1 relationship no catalog items. That's an unnecessary amount of overhead to maintain as an organization.

[MaxMixali]

Per SN KB2056057, the `cmdb_ci_service` table is restricted to certain roles (dependency_views, sam_core_user, app_service_user, sn_cmdb_user, itil).
This causes visibility issues for standard users (e.g., snc_internal) who need to see Business Services for self-service purposes like record producers or catalog requests.

---
### 🧩 Root Cause
The restriction is designed to protect operational CMDB data. However, users need visibility into Business Services and Offerings to request subscriptions or access.

---
### ✅ Recommended Approaches

#### **1. Use Service Offerings (`service_offering` table)**
End users should select **Service Offerings**, not Business Services.
- Reference the `service_offering` table in your record producer or catalog item.
- Example reference qualifier:
```javascript
active=true^business_service.active=true
```
- Users can see offerings without needing CMDB access.

---
#### **2. Create a Custom 'Service Directory' Table**
For user-friendly visibility:
- Create table `u_service_catalog_directory`.
- Include fields: Name, Description, Linked Catalog Item, Subscription Status.
- Populate it via scheduled job or Flow Designer from Business Services.
- Give all users read access and display this in Service Portal.

---
#### **3. Controlled Role Extension**
If acceptable, create a limited visibility role:
- Role: `u_service_viewer`
- Grant read access to `cmdb_ci_service` and `service_offering`.
- Assign this role only to internal users who need it.
> ⚠️ Use cautiously—avoid exposing sensitive CMDB data.

---
### 💡 Automate Service Subscription Requests
To fix the “chicken and egg” issue:
- Build a Catalog Item like “Request Access to Service”.
- Allow users to select a `service_offering`.
- Use Flow Designer to notify Service Owner, create subscription, or auto-approve access.

---
### 🧠 Best Practice Summary

| Objective | Recommended Solution |
|------------|----------------------|
| Allow users to request access | Catalog Item referencing `service_offering` |
| Display list of available services | Custom “Service Directory” table |
| Avoid exposing CMDB | Replicate public data instead of changing ACLs |
| Automate subscription | Flow Designer + Notifications |

---
### ✅ Summary
- Don’t expose `cmdb_ci_service` directly.
- Use `service_offering` for self-service interactions.
- If broader visibility is needed, use a custom directory table.
- Automate subscription workflows for seamless experience.

This follows CSDM best practices while maintaining CMDB security and user usability.

[Mathew Hillyard]

@MaxMixali 
Have you discovered ChatGPT or something? Your very long posts make each thread you post in very hard to read. It would be much preferred to keep posts more brief - it’s in the spirit of most forums too. It would also make any useful advice you give easier to find. Starting a topic or blog is a different matter.