Relationship Hierarchy between Business App and File System/Storage File Share/AWS S3 Endpoint

YashKumarV
Tera Contributor

yesterday

Hi Community,

I’m trying to understand whether ServiceNow OOTB CMDB relationships allow us to derive a hierarchy between Business Applications and File System / Storage File Share / AWS S3 Endpoint records, either directly or indirectly, without creating any custom relationships.

 

Context / Current State

We are strictly limited to OOTB CI classes and OOTB relationship types.
No custom relationships or manual modeling are allowed.

We currently have the following OOTB relationships in place:

  1. File System hierarchy

 

 
Logical Data Center → File System → Key-Value

  1. Storage hierarchy

 

 
Storage Server → Storage File Share → Key-Value

 

The key-value records are already associated with:

  • cmdb_ci_file_system

  • cmdb_ci_storage_file_share

End Goal

We need to understand:

  • Whether there is any OOTB-supported relationship hierarchy from:

    • cmdb_ci_business_app

  • To:

    • cmdb_ci_file_system

    • cmdb_ci_storage_file_share

    • cmdb_ci_aws_s3_endpoint

What we are trying to find

  1. Are there any direct OOTB relationships between:

    • Business Application ↔ File System

    • Business Application ↔ Storage File Share

  2. If not direct, are there any indirect OOTB hierarchies (for example via Storage Server, Logical Data Center, etc.) that ServiceNow supports out of the box?

Constraints

  • OOTB only (Discovery / Service Mapping / CMDB default behavior)

  • No custom CI classes

  • No custom relationship types

  • Looking for defensible CMDB hierarchy, not logical assumptions

Question

What are all the possible OOTB relationship hierarchies (if any) that allow Business Applications or Services to be related to File Systems or Storage File Shares?

Any guidance, official documentation references, or real-world patterns would be greatly appreciated.

0 Helpfuls
  • 54 Views
1 REPLY 1

Tony Branton
ServiceNow Employee

2 hours ago

I recommend reviewing CSDM 5 to get an understanding of the context that Business Applications are associated with and infrastructure-type CI classes.  A Business Application (typically defined by Enterprise Architects) is a logical definition for an IT application that supports a business capability.  Service Instances have a direct relationship to Business Applications since they are instantiations of a Business Application.

Infrastructure-type CIs can be associated with Service Instances by being mapped to Service Instances using top-down service mapping, tag-based service mapping or manual mapping.

Dynamic CI Groups can also be used to define a collection of infrastructure-type CIs that can then be associated with Technology Management Services and Technology Management Service Offerings.

Avoid relating infrastructure-style CIs directly to Business Applications.  Relating them to Service Instances or using Dynamic CI Groups will ensure applications like Event Management will be able to use the resulting maps to calculate impact and support root case analysis - things you won't get using Business Applications.

0 Helpfuls