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.

[Mathew Hillyard]

Hi @Aaron_Braun 

If you think about it, it would seem odd that snc_internal should be able to see anything in the CMDB, it's the most basic level of instance access and doesn't even contain cmdb_read (except for assigned CIs). I'd turn it around and say snc_internal should not have access to read the service table in the first place.

You request access through catalog items. You can relate the service offering to the catalog item to track and maintain who requests what and if you want to add them to the subscribed by user related list on the service offering (e.g. for targeted comms or understand an offering's user base). The Catalog Item should be a familiar name, analogous to the service offering name, but the end user should never need to know (and nor should they care) what the service or service offering name is - that's what the service catalog is for.

The itil role is a whole other story - SN needs to move away from it (in fact that have with all the individual ITSM roles) but it's so embedded across the platform it may not be possible - plus it's still used for ITSM licensing, I believe.

I hope this helps!

Mat

[Aaron_Braun]

Therein lies my challenge. My end user community doesn't need to know what they are asking for is classed as a service offering. Yet I can't use the service offering records as a lookup select box to present to them on said catalog items. Now I have to create a separate choice list that then maps to the service offerings to update subscriber counts.

The ITIL role is a crutch role and the environment is getting a lot better now that SN has exposed this flawed design with the use of explicit roles. I will personally note they have gotten much better over the last couple releases but it is still exposing itself in situations like this as being a lingering nuisance from original designs.

[Barry Kant]

Hi Aaron, Mathew, 

If you use Service (offering) Subscriptions, then I would expect that one (end-user) can select them (so they need to see them) this is how it works in CSM as well: I can create a case against a Sold Product and/or my Install Base Item as a consumer.
In ITSM this is not possible (ootb). 
I would not necessarily need to see the Services, but Subscribed Service Offerings is good enough. 
Also to communicate back (from support org to users) about disrupted services on the portal:
Your subscribed offering has some degradation etc. This potentially deflects new incidents.

ITSM and CMDB is not designed like this, but if you use Subscriptions then for me it would make sense to open the door a little bit.

BR,
Barry

[Aaron_Braun]

Even as subscribers they can't see the service offerings on a catalog item if you want to present in a drop-down select box for instance. It makes it extremely difficult if you want to make dynamic lists that allow users to self-register as subscribers to a service offering while executing other actions as a result of that subscription. Because in current design I have to build a choice list that then routes to the service offering (they can't see) to add them as a subscriber on the back end.