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.

[Barry Kant]

I concur, 
Subscription should preferable be managed automatically. Eg via AD groups. 
That makes it also dynamic. 
EG:
I have a lucid license, and therefore in a lucid AD groups, so I can see a Lucid offering. There is a standard script include to checks your subscriptions as an user.

BR,
Barry

[Aaron_Braun]

For use case this is the step before already having said license. Basically we want to have a user be able to choose an offering because they need it (e.g. EMEA Financial Data Warehouse) and that then results in them being added to the respective dynamic groups associated to those services and service offering subscriptions.

That's my issue. Letting them self-service themselves to certain offerings without having to go through some side door extra table fiasco just to select effectively the same data point.

[Mathew Hillyard]

Hi @Barry Kant 

A sold product is not the same as a service offering though, is it? When I request something I might know the service offering name or may not, but as a consumer I don’t care, and nor should I as the service catalog acts as the engagement layer. A service offering record contains a lot of information that isn’t appropriate for end users to see - hence the catalog item layer.

Of course, when we start to advertise the performance of the services we deliver to end users (e.g. the System Status widget) then things become tricky, but I’ve rarely seen this widget on modern service portals as we actually we care about Offerings, not services. 

If there is a gap then it should be fixed at the employee Center level and not by opening up access to the CMDB.

But I do agree that either approach has its problems - this is more down to the historical development of the platform and access to the CM, which is just a fact of life 🙂

BR
Mat

[Barry Kant]

Hi Mat, 

I can only agree with most.
In CSM there is a data segregated layer on the CMDB, so users can make use of it. 
For internal users that is missing in my opinion. 
A Service Catalog is the engagement layer, but it will make sense that I can raise an incident against my service or asset assigned to me. I aim to use subscriptions for the first and assigned assets are obvious.The rest I should not see. But I am in favor of smart intake over a description field in general. 
There are opportunities to improve. Maybe the CSM concept for internal consumption is the way forward (conceptually), but that will raise a lot of other discussions.
BR
Barry

[MaxMixali]

ServiceNow – How to let end users select Services/Offerings without giving cmdb_ci_service read access

Context
-------
Per KB2056057, table **cmdb_ci_service** is not readable by users lacking one of these roles:
- dependency_views, sam_core_user, app_service_user, sn_cmdb_user, itil

Result: standard users (e.g., snc_internal) cannot open a reference to Business Service / Service Offering on Record Producers or Catalog Items. You still need a way for them to *choose a service/offering* and request subscription or access.

Key point
---------
End users should **not** need direct read access to the CMDB to request a service. Instead, surface a curated list through Employee Center and/or a “directory” layer and handle the CMDB write on the server during fulfillment.

Recommended patterns (pick 1–2)
-------------------------------
A) Employee Center Topics + Requestable Offerings (No CMDB read required) ✅
1) Model services/offerings in Service Portfolio / Service Builder as usual.
2) Mark relevant **Service Offerings** as *requestable* and associate a **catalog item** that represents the subscription/access request.
3) In **Employee Center**, create **Topics** for the business services and map:
- Support Resources → the associated Catalog Items (“Request access”, “Subscribe”, etc.).
4) Users browse Topic tiles (no CMDB read) and click the request item. Your fulfillment flow creates/updates the subscription against the service/offering.

Pros: No CMDB exposure; OOB EC UX; simple for users.
Cons: Requires setting up Topics/Content and mapping request items per offering.

B) “Service Directory” mirror table (denormalized, read-open) ✅
Create a small public table (e.g., **u_service_directory**) with ONLY what users must see (name, description, logo, offering list, hidden field with the CMDB sys_id). Populate it from CMDB on a schedule (scheduled job running as system):
- Insert/update/remove entries based on the CMDB source.
- Lock the table to **read for snc_internal**, but **no write**.

In your Record Producer / Catalog Item:
- Use a **Lookup Select Box** or **Reference** to **u_service_directory** (not cmdb_ci_service).
- Store the selected row’s **hidden sys_id of the offering/service** in a variable/hidden field.
- On submit, server-side (Flow Designer / Script step) uses that sys_id to perform the CMDB write (subscribe the user, notify owner, etc.).

Pros: Zero CMDB read for end users; fast search; you control labels and audience.
Cons: Requires a scheduled sync job and governance to keep in sync.

C) Scripted Data Resource / Scripted REST with technical user (UI Builder) ✅
1) Create a **Scripted REST API** that returns a filtered list of services/offerings. Execute as a **technical account** with the minimal CMDB read role (e.g., sn_cmdb_user) and **web_service_access_only**.
2) In Employee Center (UI Builder), create a **Data Resource** calling that API and bind it to a picker component.
3) On request submit, the server flow uses the returned **sys_id** to complete the action (create subscription, generate task to owner, etc.).

Pros: No CMDB read for end users; dynamic; no data duplication.
Cons: Requires IntegrationHub/UI Builder familiarity and secure API design.

D) Incident Tasks or “Request on behalf of” flows (when L1 helps) ➕
If selection must happen during assisted support, keep the Incident with L1 and spawn a **task** to the service owner. The L1 agent can see CMDB (itil/sn_cmdb_user) while end users don’t.

What NOT to do
--------------
• Don’t grant broad roles like **itil** or **sn_cmdb_user** to all employees just to expose cmdb_ci_service.
• Don’t reference cmdb_ci_service / service_offering directly on end‑user forms—ACLs will block and you’ll create a security hole if you loosen them.

Subscription request pattern (works with A/B/C)
-----------------------------------------------
1) Build a Catalog Item: “Request subscription to Service Offering”.
2) Variables:
- Service / Offering selector (from Topic → mapped item, or u_service_directory, or REST-fed picker).
- Justification / expected usage.
3) Flow Designer:
- If approval is required → route to **Service Owner** of the offering (derive via CMDB relationships).
- On approval → **create/update subscription** in Service Portfolio (Service Builder) and set the user as a consumer/subscriber.
- Notify requester + owner; add user to relevant groups where applicable.
4) Reporting:
- Report subscription count per offering from Service Portfolio (no need for end-user CMDB access).

How to narrow selectable offerings (if you must show a selector)
----------------------------------------------------------------
- Filter by audience (department, company) at the mirror table or API.
- Hide retired/non-requestable offerings.
- In EC Topics, use **audiences** to limit visibility of tiles/cards to eligible users.

FAQ
---
Q: Can I relax ACLs on cmdb_ci_service so snc_internal can read?
A: Not recommended; it exposes sensitive portfolio data and dependency maps. Use one of the patterns above.

Q: Which table stores “subscriptions”?
A: Use the **Service Portfolio / Service Builder – Subscriptions** feature (accessed via the Service Workspace). Your fulfillment flow should create/update the subscription record(s) via server-side logic. (Table names can vary by release; rely on the OOB modules and relationships rather than hardcoding.)

Q: How do end users see relevant request items for a service?
A: Via **Employee Center Topics** → Support Resources → linked Catalog Items for that service/offering (Pattern A). No CMDB read needed.

Bottom line
-----------
You don’t need to let end users read **cmdb_ci_service** to request or subscribe to services. Use **Employee Center Topic mappings** and/or a **directory layer** (mirror table or API) to present choices, and do the CMDB updates on the **server during fulfillment** under a privileged context.