Interested in a ServiceNow event built for developers? Registration for now[dev]26 is officially open!

Application service mapping SAAS application

Slogesh
Giga Contributor

I am currently starting to work on Application Service Mapping, and we are initially planning to follow a manual mapping approach.

I would appreciate your guidance on understanding the Application Service Mapping process for SaaS applications, particularly from a ServiceNow perspective.

Could you please share any relevant ServiceNow documentation, implementation guides, or training videos that explain the manual Application Service Mapping process?

Additionally, I would like to understand:

The prerequisites and information that need to be collected from the application/SaaS owner.
The CI and dependency details that should be identified before starting the mapping.
The step-by-step process for creating and completing a manual Application Service Map in ServiceNow.
Recommended best practices and considerations specific to SaaS applications.
Any validation or approval steps that should be followed once the map is completed.
This will help us establish a consistent approach and ensure that our SaaS Application Service Maps are aligned with ServiceNow and CSDM best practices.

4 REPLIES 4

Mathew Hillyard
Tera Sage

Hi @Slogesh 

It depends on your definition of a SaaS application, but if you take ServiceNow as an example, you don't actually have access to either the application server or the database server (or the other infrastructure that supports a ServiceNow node, such as the Predictive Intelligence training server, the LLM server(s) or the monitoring infrastructure like Splunk), so there is no point modelling the service that deep. I would generally just create an Application CI manually (or via some form of automation if you plan to take the same approach for all SaaS products). There are no "discoverable" CIs.

 

This is the strict meaning of SaaS - you use an app built on infrastructure you cannot access - but for things like PaaS it could be different. In this situation Service Mapping (the product) has many applicative patterns for different technologies.

 

A general rule is try to map the service as close to reality as you can.

 

I hope this helps!
Mat

Hi Mat,

my pragmatic solution for this is to create one Website per instance as an entry point.

  • Mapping Method: Manual
  • Type: Web Site
  • Insert the URL into the Description field

This approach works well and could potentially also be applied within Event Management, depending on the specific use case. The downside is the manual effort and the need for adjustments whenever changes occur.  

Ideally, ServiceNow would provide a standard HTTPS URL attribute on the object out of the box. It would not need to be mandatory, but having it available by default would simplify this use case considerably.

Best, Simone

Hi @Simone Berge-Ko 

This is an interesting alternative, and whilst not wrong, I would always expect to see an Application CI related to every Application Service - the clue is in the name. A website is not normally considered a part of an Application Service - in service mapping we normally go as far as a Web Server app/host but not the website itself, although there's no actual harm in doing so I would suppose.

 

Mat

 

 

Hi Mat,

Yes, I came to the same conclusion. After weighing the pros and cons, I deliberately opted for the WebSite CI approach. The number of records I have created is relatively small (around 30), so a future migration to cmdb_ci_appl would be entirely feasible with a reasonable amount of effort if needed.

My primary goal was to document the HTTPS entry points, maintain whitelist of AI-enabled websites, and relate them to the corresponding services. For this use case, the WebSite CI seemed like the most pragmatic option.

At the moment, the solution serves its purpose well, provides the desired transparency, and does not have any negative impact on Service Mapping or the overall CMDB structure. If a clearer functional or technical benefit emerges in the future, moving these records into the Application class would be straightforward. Unfortunately, ServiceNow does not define a clear best practice for this particular use case, so there is some room for interpretation. Given the current requirements and the limited number of records, the WebSite CI approach felt like the most practical choice.

Best regards,
Simone