Skip to Main Content
Cloud Management and AIOps

This is an IBM Automation portal for Cloud Management and AIOps products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Under review
Created by Guest
Created on Mar 18, 2024

Servicenow-Observer to provide ability to discover relationships tables separately from resource discovery

At present when discovering resources from servicenow we specify the tables to collect data from and have to be explicit with the parent and child classes because whilst resources can be discovered from the parent class and it traverses the children, the final stage where relationships are discovered only discovers the relationship from the parent table to another parent table and doesn't discover anything within the discovered child tables.


ie  say we discover these classes :




discovering these classes is necessary because when the observation moves to discovering the relationships in /api/now/table/cmdb_rel_ci then unless each class is specified it doesn't perform a parent/child discovery of the resource and find the upstream and downstream relationships.  


If we go with the parent class, then it will discover the children, but never tests the children's resources for relationships within /api/now/table/cmdb_rel_ci  so you end up with no relationships drawn for the children.


This has the effect of increasing discovery time and can take 5+ hours as it has to go over the same data and discover children it has already discovered.


So by adding in the ability to have a list of classes to discover for resources and separately a list of classes to discover for relationships it means I can have a cut down list of classes for the first part of the observation and when this is complete it will use the relationship discovery classes to find the remaining relationships and this can then include the child tables.



Idea priority High