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:
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:
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!
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!
â
