What CI type should be used for SaaS\Cloud applications where you have no visibility?

[mark_oldroyd]

I was wondering if there was a correct CI type to use when referencing infrastructure for application services that are SaaS\Cloud applications where you have no visibility into the actual infrastructure.

For example, I would have an application service for my Service Now Prod but what infrastructure CI type would it depend on or be hosted on to represent the Service Now cloud?

[mark_oldroyd]

Hi Stuart,

You're right that I need to look at the Product Model aspect, which I haven't done yet.

Especially given it looks like the next version of CSDM is leaning toward the whole Digital Product idea potentially amalgamating Business Application and Business\Technical Service.

Thanks,

Mark

[Robert80 · Accepted solution]

If I understand correctly, you are asking for a way to reference the cloud infrastructure without knowing the specific CIs within that environment. Strictly speaking, you should create an application service to represent the solution and stop there but I think you'd like to see a dependency so that you could, for example, identify the impact of a scheduled outage by your provider.

I don't think cmdb_ci_environment is quite the way to go because it's designed for concepts like "Production", "Development", "QA", etc. Rather, you could create a service offering that represents the underlying 'environment' and, using service builder, navigate to the "Operations" tab of your SaaS offering and add the other offering as an "Offering I depend on".

Alternatively, you could create a CI using the 'Cloud Host' class to represent your hosting environment and use the Runs On relationship between the Application (part of your application service) and that Cloud Host.

[mark_oldroyd]

Hi Robert,

Yes you understood perfectly. Indeed the impact of an outage is one reason it might be useful. I was also thinking in terms of anyone new\unfamiliar with our systems could at least see visually if they were looking at a map.

I'll certainly be looking to use Models and offerings too, but as some information for those is held in records it won't always translate to a purely pictorial perspective.

Cloud Host looks a good suggestion, thank you.

Thanks,

Mark

[jaguthrie]

Did this method work for you?  I am running into the same situation where we have a larger process supported by both On-prem applications and SaaS.  Trying to find a good way to represent and present information regarding SaaS applications the same as On-prem apps are.  Just having a blank map makes someone think that the information is missing and not 'that is how that particular CI is managed by ServiceNow'.

[Sanjay112]

If you don't have visibility into the underlying infrastructure, I'd keep the CI at the service level rather than trying to represent resources you can't actually manage. In most SaaS and public cloud environments, you're consuming a service, not the servers, databases, or network components behind it. Modeling the application, its integrations, and the business service it supports usually provides a much more accurate representation.

The real value comes from documenting the dependencies you can observe and influence. That includes APIs, authentication services, data flows, SLAs, and connections to other business systems. It's a practical approach that avoids filling the CMDB with assumptions while still giving operations teams meaningful visibility. Working with the team at Technource has reinforced that mindset for me. On SaaS and cloud-native projects, the focus has always been on accurately modeling service relationships and integration points instead of trying to represent infrastructure that's managed entirely by the cloud provider.