Application service mapping SAAS application
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-27-2026 12:14 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-29-2026 01:16 PM - edited 08-29-2026 01:16 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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.
Best, Simone
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
a week ago
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
