Converting Business Services to the new cmdb_ci_business_service table

[Sean Walters]

Hi All, 

I believe this new business service table was introduced when the DPM plugin is enabled. 

However it has caused a dilemma and was wondering how has others managed this. 

Initially, we had the business service table which was [cmdb_ci_service] 
This table is the parent service table of which technical services, application services would extend from. 

When DPM is installed then a new business service table is introduced to support the service portfolio features which is: 
[cmdb_ci_business_service]

I understand that in Tokyo the original table will be re-labeled to Service and it would mean best practice to convert all the business services that orginally created on this table to its child table. 

We have wrote a script to do this my only concern is there anything that maybe be impacted by changing the class of these records. In the script we would be going through all business services (i.e. service classification is business service) in the cmdb_ci_service  and then changing the class to Business Service. 

We have checked incidents, requests and filters seem to all be okay since the data would exist on both tables.

Has anyone done something similar and were there any impact ?

Thank you. 

[EricDohr · Accepted solution]

The tables Business Service [cmdb_ci_service_business] and Technical Service [cmdb_ci_service_technical] are not installed with DPM, but DPM does utilize those tables. The new tables occured in the Rome SPM release

A few things to keep in mind / help ease concerns

• Business Service [cmdb_ci_service_business] is an extension of Service [cmdb_ci_service] meaning any fields you have created on the parent table will cascade down.  
• Technical Service [cmdb_ci_service_technical] is an extension of Service [cmdb_ci_service] and is also a table you would want to make sure items with the classification Technical Service are migrated so DPM Functions.  
• If you were to have existing functionality such as reports, variables, and other concepts, records on the tables Business Service [cmdb_ci_service_business] and Technical Service [cmdb_ci_service_technical] are still visible when you look at Service [cmdb_ci_service]
• Service Offering [service_offering] has the field Parent that has a reference qualifier in the dictionary sys_class_name=cmdb_ci_service^ORsys_class_name=cmdb_ci_service_business^ORsys_class_name=cmdb_ci_service_technical
• If you were to create a record on Service [cmdb_ci_service] and move it to a new class such as Business Service [cmdb_ci_service_business], it will keep the same SYS_ID

If you are using Service Owner Workspace in parallel to moving to Digital Portfolio Management, when you move those records to the new tables, SOW will not be able to see those records.  From an OCM standpoint you will want to know this.  

Try moving a same record to table and validate any concerns through test cases. Hope this helps!

[Sean Walters]

Thanks Eric. 

This is really useful information. We have moved records from table to table and cannot see any immediate impact just wanted to check if there was anything we may have missed apart from the obvious use cases, i.e. incident records, change etc. 

The Service Owner workspace is a good call out - thank you for that we will look the scenario you mentioned above. 

[MBannis]

Thanks for that explanation.. With that being said, what role in ServiceNow is required to access these new tables, as I have been able to find them but cannot access them due to security constraints even though I have most if not all the CMDB / Discovery related roles assigned to me including Itil_admin.. 

Thanks

Misana