Service ACLs: Why are child tables (Business, technical services) not visible for logged in users, but "normal" Service (cmdb_ci_services)?

SebastianKunzke
Kilo Sage
Kilo Sage

Hi experts,

We have the case, that we want to use the new table "Business service" instead of the parent table (cmdb_ci_service). This is suggested based on CSDM and also based on the release notes from ServiceNow, that this table replace the general service table. 

However we now face the issue, that our user can not select the business service inside of a record producer. Does somebody know, why ServiceNow introduced separate ACLs for the child tables of the cmdb_ci_service table? And why they should not be visible to any logged in user?

Screenshot from my example: cmdb_ci_service_business. The open ACL is not valid for the child tables introduced in 2020/2021. And only for them. 

find_real_file.png

When you do not know the answer by sure, feel free to share your idea about what could be the reason.

Thanks and best regards

Sebastian

1 ACCEPTED SOLUTION

Vivi Brasil
Kilo Sage

Hello Sebastian Kunzke,

This could not be the best answer, but as far as I know, since some changes from New York release, with the Service Portfolio Management, there are different Roles to read the Configuration Items and the Services.

For the Services, even when we were using the base Services table [cmdb_ci_service], with the Service Classification to classify the Business Services and the Technical Services, the OOB ACL in the cmdb_ci_service required the Role "service_viewer".

There are some old posts here, and some Now Support KB Articles, just in case they could help for reference:

In the first KB Article above, there is the following information:

  • "service_offering" table have a new read ACL, which allows read for records in "cmdb_ci_service" for users with the role "service_viewer" and "catalog_admin", due to which the users without "cmdb_read" role could not access the table records from Service Catalog.

--
So, OOB the End Users (ESS users) would need the Role "service_viewer" to be able to read the Business Services records from a Variable in the Service Catalog Item / Record Producer, or you would need to create a new ACL (not OOB), to extend the read access to users without any Role.
But I would suggest to confirm it raising a case in the Now Support, to figure out what could be the best approach for your scenario, or checking with your ServiceNow Account Rep (as it envolves Roles, it could be better to check with them, although the "service_viewer" is only considered a Requester Role - without any subscription involved).

--
Here we have an instance upgraded from Paris to Rome, and since Paris we have used the Technical Services table.
However, how the Business Services table is new starting by Rome, we are still using the Service Classification in the cmdb_ci_service to classify the Business Services (which becomes more and more obsolete by having specific tables, according to the answer from Barry Kant in this post). We have plans to migrate to the new Business Service table, using the recommendations from in this another post from David Skowronek: CSDM: How to get there?).

During the upgrade, we could see some new ACLs created, but our scenario could be a little different from yours, depending on the instance being a fresh instance or an upgraded instance, and from which release family.

The screenshot below will just illustrate the new ACLs we noticed during the upgrade to Rome:

--
find_real_file.png

 

Here there are some of the ACLs created with the new Business Service table [cmdb_ci_service_business], during the upgrade to Rome, this OOB ACL is in regards to the "read" operation, and it requires the "service_viewer" Role:

--
find_real_file.png

---

I hope it could help you in some way.
Best regards,
Vivi Brasil

View solution in original post

5 REPLIES 5

Vivi Brasil
Kilo Sage

Hello Sebastian Kunzke,

This could not be the best answer, but as far as I know, since some changes from New York release, with the Service Portfolio Management, there are different Roles to read the Configuration Items and the Services.

For the Services, even when we were using the base Services table [cmdb_ci_service], with the Service Classification to classify the Business Services and the Technical Services, the OOB ACL in the cmdb_ci_service required the Role "service_viewer".

There are some old posts here, and some Now Support KB Articles, just in case they could help for reference:

In the first KB Article above, there is the following information:

  • "service_offering" table have a new read ACL, which allows read for records in "cmdb_ci_service" for users with the role "service_viewer" and "catalog_admin", due to which the users without "cmdb_read" role could not access the table records from Service Catalog.

--
So, OOB the End Users (ESS users) would need the Role "service_viewer" to be able to read the Business Services records from a Variable in the Service Catalog Item / Record Producer, or you would need to create a new ACL (not OOB), to extend the read access to users without any Role.
But I would suggest to confirm it raising a case in the Now Support, to figure out what could be the best approach for your scenario, or checking with your ServiceNow Account Rep (as it envolves Roles, it could be better to check with them, although the "service_viewer" is only considered a Requester Role - without any subscription involved).

--
Here we have an instance upgraded from Paris to Rome, and since Paris we have used the Technical Services table.
However, how the Business Services table is new starting by Rome, we are still using the Service Classification in the cmdb_ci_service to classify the Business Services (which becomes more and more obsolete by having specific tables, according to the answer from Barry Kant in this post). We have plans to migrate to the new Business Service table, using the recommendations from in this another post from David Skowronek: CSDM: How to get there?).

During the upgrade, we could see some new ACLs created, but our scenario could be a little different from yours, depending on the instance being a fresh instance or an upgraded instance, and from which release family.

The screenshot below will just illustrate the new ACLs we noticed during the upgrade to Rome:

--
find_real_file.png

 

Here there are some of the ACLs created with the new Business Service table [cmdb_ci_service_business], during the upgrade to Rome, this OOB ACL is in regards to the "read" operation, and it requires the "service_viewer" Role:

--
find_real_file.png

---

I hope it could help you in some way.
Best regards,
Vivi Brasil

hi all,

 

the way I see the consumption need is this:

Portal:

En End User (snc_internal) is subscribed to service_offering record. The Business Service is inherited from the Service Offering (parent). Either fill this by system, or they should be able to read the Services as well.

Back end (incident)

Agents (sn_incident_write) are (ootb) expected to fill Service before Service Offerings (why not Service Offerings first --> subscriptions). So they need to have a contained role service_viewer.

Enjoy the day,

Barry

Thank you for collecting all the information. We faced the issue on several instances. Some were new ones (San Diego) and other ones were updated from older releases.

The conclusion will be, that in new projects we need to discuss in the future, if an end user needs read access to the CMDB. This is a bit odd at first, but seems to be logical, when we look into all the new modules ServiceNow introduce. The new use cases require more of OOTB data security, due to different user roles.

Stig Brandt
Tera Guru

Hi, thanks Vivi, for this very good explanation, I have raised the questions to ServiceNow about getting a more user friendly view presented for the users in the service catalog, and came to the same conclusion about they need the service_viewer/cmdb_read role, to be able to see the data, I think ServiceNow, need to come up with some solution wrt to view/access and interact with business services from the catalog.

br

Stig