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

Sam Webb
ServiceNow Employee

Overview

If you're using Tag-Based Service Mapping, you're likely familiar with the fact that candidates are created by the Service Family. This, though, proves a challenge if your organisation has manually created Service records already - leading some organisations to have a parent/child service pair, where the parent was manually created and the child is the tag-based candidate.

 

This is sub-optimal for a few reasons, notably:

  • It is more work to maintain extra records, which nobody wants. We're busy enough already!
  • It makes it harder to tag the correct Service onto Changes, Alerts, Incidents - potentially adding time / effort to your impact assessments or issue resolution. Not the vibe in 2026.
  • It makes it harder to view the components of a Service because one is somehow two?

 

Avoiding the Issue

A brief note - this is nothing revelatory - as it's simply part of the product - but it's something I recently came across and nobody I'd spoken to about it had heard of it either!

 

Once you've created your Service Instance - the manual one - simply navigate to it in the 'new' view. In the middle "Populate the Service" tab select the option tag-based, and select your options as appropriate:

Screenshot 2026-06-02 at 12.27.10.png

You will notice that you can either use an existing candidate, or use a list of tags to calculate it there and then (this would allow you to forgo the definition of tag categories/families, but wouldn't scale - so better for smaller use-cases).

 

Once you've selected the candidate, the UI will change to something like this:

Screenshot 2026-06-02 at 13.30.10.png

Simply click through the rest of the Service population options and you'll end up with the result we were looking for - a manually created Service, populated (in a single layer) with a tag-based candidate. Voila!

Screenshot 2026-06-02 at 13.31.30.png

Note: this map isn't very exciting as I only configured a single CI with the app/env tag to show the mechanism. When you do this using better data, you'll see a lot more - and then you can add in traversal rules too. But that is for another day!

 

Comments
Charles Keown
Tera Contributor

Thanks for sharing this.  Extremely helpful.

Nisha30
Mega Sage

Thanks @Sam Webb  this was helpful.

However trying to use the first Option = 'Use a list of Tags'  using only single Key Value pair but not allowing to create Instance says:

 

A problem occurred during service creation.

 

Thanks

Sam Webb
ServiceNow Employee

@Nisha30 oh! Are there any other logs or messages you could share? How many CIs are in your service, is there anything on cmdb_key_value for that key/value pair?

 

Thanks,
Sam

anusha_narapura
Giga Guru

Hi @Sam Webb  - can we use the option Populate Service → Tags → Use a list of tags for set of service instances and use Populate Service → Tags → Use a candidate from a tag-based service family for another set of service instances. This is to avoid creation of tag-based families every time i have a new application service. We used values in the tag-families to limit the number of service candidates.

Sam Webb
ServiceNow Employee

@anusha_narapura sort of... let me explain:

1. You declare a Service Family for a POLICY, not a SERVICE. That is combinations like Application / Environment, or Customer etc. Any Service with those will be picked up in that family.

2. Any existing Service can then be populated from that family (which is the "candidate" option). 

3. Any existing Service you try to populate using individual tag lists will need to NOT already be in a family (else they'd be mapped by point 2). You need to make sure the tag lists you use here are unique else you'll get the following error:

Screenshot 2026-10-05 at 09.47.13.png

Hope that helps!

Sam

Version history
Last update:
‎06-02-2026 05:35 AM
Updated by:
Contributors