Tag-Based Service Mapping Approach

[abhijee]

Hello Team,

I am currently working on tag-based Service Mapping. In our CMDB, each CI has multiple tags stored in the cmdb_key_value table. The available tags include environment, description, app_id, project, and several others.

I have a basic question regarding the tagging strategy:

• Do we need to create tag categories for every available tag, or
• Should we define only a selective set of tags under tag categories?

Additionally, I would like guidance on:

• How to decide which tags are most appropriate for Service Mapping
• How to identify the best service candidates while defining services in the service family

Please advise on the recommended approach and best practices.

Thank you in advance.

[vaishali231]

Hey @abhijee 

For tag-based Service Mapping, the recommended approach is not to create tag categories for every tag available in the cmdb_key_value table. Instead, focus on a selective set of tags that provide meaningful service identification and can reliably group infrastructure components into a business or application service.

1. Should all tags be created as Tag Categories?

Generally, no.

Creating tag categories for every available tag (such as description, comments, temporary metadata, etc.) can introduce unnecessary complexity and may result in poor service candidate generation.

Instead, create tag categories only for tags that:

1. Are consistently populated across CIs
2. Have standardized values
3. Represent business or application ownership
4. Help distinguish one service from another
5. Are governed and maintained over time

Typical examples include:

1. app_id
2. application
3. service
4. environment
5. business_unit
6. owner (depending on organizational standards)

Tags such as description are usually not ideal because they are often free-text values and may vary significantly between records.

2. How to Decide Which Tags Are Best for Service Mapping?

A useful evaluation checklist is:

1. Is the tag present on most relevant infrastructure CIs?
2. Does the tag uniquely identify an application or service?
3. Are the values standardized and controlled?
4. Can operations teams trust the accuracy of the tag?
5. Will the tag remain stable over time?

The best tags typically have:

1. High coverage
2. High accuracy
3. Clear business meaning
4. Strong application ownership alignment

For example:

Good Candidates

1. app_id
2. application
3. service
4. environment

Usually Poor Candidates

1. description
2. notes
3. comments
4. created_by
5. last_updated_by

3. How to Identify the Best Service Candidates?

Before defining services within a Service Family, perform a tag quality assessment.

Look for applications where:

1. Infrastructure components share a common application identifier
2. Ownership is clearly defined
3. Production resources are consistently tagged
4. Relationships between servers, databases, and cloud resources are well understood

A common process is:

1. Identify a business application.
2. Verify that associated infrastructure shares common tags (for example, the same app_id).
3. Review the discovered CIs for consistency.
4. Create a Service Family using the selected tag category.
5. Validate the generated service candidates before promoting them to production services.

4. Recommended Best Practices

1. Start with a small number of high-quality tag categories.
2. Prioritize application-centric tags over infrastructure-centric tags.
3. Use combinations of tags when necessary (for example, app_id + environment).
4. Establish tag governance before large-scale implementation.
5. Regularly review tag coverage and data quality.
6. Align the tagging strategy with CSDM and your service portfolio structure.
7. Avoid creating tag categories solely because a tag exists in the CMDB.

Example

If your organization has the following tags:

1. app_id = FIN001
2. environment = PROD
3. project = FinanceModernization
4. description = Finance Application Server

A strong tagging strategy would use app_id as the primary service identification tag and optionally use environment as a secondary qualifier. The description tag would generally not be used for Service Mapping because it is descriptive rather than service-defining.

In most implementations, organizations begin with only a few well-governed tags such as app_id, application, service, and environment. This usually results in cleaner service candidates, easier maintenance, and more accurate Service Mapping outcomes.

************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb

[abhijee]

Hello @vaishali231 

Thank you for your reply.

I have one quick question. If we ignore the Description tag, will the system also ignore the associated CI? Currently, three CIs are associated with the Description tag. If we exclude this tag, my understanding is that those CI components will not appear on the service map.

Am I correct in my understanding? If not, could you please clarify?

Thank you.

[vaishali231]

Hey @abhijee 

Not necessarily.

Whether those CIs appear in the service map depends on how the service candidate is being identified and which tag categories are being used as the inclusion criteria.

For example:

   If the service candidate is built using the Description tag category and those three CIs are identified only through that tag, then excluding the Description tag category may prevent those CIs from being associated with the service.

However, if those same CIs also contain other qualifying tags (such as app_id, application, or environment) that are part of the service definition, they can still be included in the service map even when the Description tag is ignored.

The key question is not whether the CI has a Description tag, but whether the CI matches at least one of the tag criteria used to build the service candidate.

Before removing the Description tag category, I would recommend checking:

1. What tags are currently present on the three CIs?
2. Are those CIs associated with the service through any other tag categories?
3. When previewing the service candidate, do those CIs still appear after removing the Description tag category?

If the Description tag is the only common attribute linking those CIs to the service candidate, then your understanding is correct—they would likely no longer be included. If other qualifying tags exist, they should continue to be discovered and mapped as part of the service.

Can you share an example of the tags assigned to one of those CIs and the tag categories currently configured for the Service Family? That would help determine exactly how Service Mapping will behave in your scenario.

**********************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb

[abhijee]

Hello @vaishali231 ,

If a CI is in a Retired state and has a tag associated with it, will it still appear on the service map, or will the system automatically ignore retired CIs during service mapping?

Could you please guide me on this?

Thank you.