---
sourceDocument: Brazil IT Operations Management
sourceDocumentLink: https://www.servicenow.com/docs/r/it-operations-management

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Create and manage mappings

# Create and manage data mappings {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read  
Map your services to the data from a connected external observability vendor instance, and view it in charts for the service.

## Before you begin

* You can map any of the following service types:
  * Service instance
  * Mapped application service
  * Calculated application service
  * Dynamic CI group
  * Technology management service
  * Tag-based service
  * Offerings
  * Business service
  {#create-and-manage-observability-data-mappings__ul_vdm_lqd_mjc}
* [Connect a Service Observability data source](https://www.servicenow.com/docs/syUGrcKEcoX4V5m8dzQb3w "Connect Service Observability to an external observability system. Service Observability displays metrics in the Service Operations Workspace (SOW) from that observability instance.")

{#create-and-manage-observability-data-mappings__ul_b44_jgj_xdc}

Role required: sn_sow_svcobs.admin

## About this task

Tip:  
If you want to use MetricBase as your data source, follow the procedure described in [Create and manage MetricBase data mappings](https://www.servicenow.com/docs/7xVxgUYr3QqFoTOuaUqQ9g "Map your services to metrics from MetricBase, and view them in charts for the service.") instead.  
When a service CI is mapped to specific observability vendor metric tag key/value pairs, Service Observability displays metrics containing those tags for that service. These metrics are grouped by the following entity types:

* Application: Metrics associated with the selected service
* Compute: Metrics associated with the hosts the service is run on
* Databases: Metrics associated with databases used by the service
* Networking: Metrics associated with network devices used by the service.
{#create-and-manage-observability-data-mappings__ul_nmv_cl4_pfc}

For example, say you have metrics from New Relic that are used to monitor services, databases, and hosts. On those metrics, you have used the tag `service_name`. Say you have also mapped the `checkout` service CI to
the observability metadata key/value pair `service_name = checkout`. Service Observability shows you all the database and host metrics tagged with `service_name = checkout` in the context of the `checkout` service CI.

If some of your metrics on different entities use a different key name or a different key value, you can create exceptions. For example, if your host metrics use `service` instead of
`service_name`, you can create an exception to include those metrics.

Each entity type has its own dashboard and each metric or related CI has its own default chart. You can customize the templates used for the dashboards and charts. See [Customize Service Observability dashboard templates](https://www.servicenow.com/docs/RC4tPjU96UKTMNgODI_RTQ "You can customize the Service Observability dashboards on both the Overview and Observability tabs of the Service Details page. You can change or add metrics and related data to fit your business needs.") for more information.  
Note:  
To understand how Service Observability creates these mappings, see [Observability vendor entity mappings for Service Observability](https://www.servicenow.com/docs/~LdkrQFjD7eUfeGPIMxdSQ "Understand how Service Observability maps service, host, and database entities to your observability vendor resources.").

For a description of the field values, see [Service Observability data mapping form](https://www.servicenow.com/docs/KjHscsqDkAZlX7vuJMtkww "Field descriptions for the Observability data mapping form. Use this form to map activated services in Service Observability to metrics from your observability instance. Each service can be mapped only once, but can contain exceptions to include all related entities.").

## Procedure

1. Navigate to AllService ObservabilityConfigure Data mappings.
2. Select Create your first mapping or Create mapping.
3. On the Observability data mapping page, enter a name for the mapping.
4. Choose the services that should use this mapping.  
   1. Choose Select services.

      The top 30 recommended services display in dialog. These are services that would most benefit from using Service Observability based on business criticality and frequency of alerts, incidents, and SLOs over the past 90 days.

      You can instead manually choose services by choosing
      All Services from the left navigation.  
      Note:  
      Use the filter to narrow down the service list.
   2. Select the services to add to the mapping. You can add services from any combination of service type.
   3. Select Add services to add them to the mapping.
   {#create-and-manage-observability-data-mappings__ol_mzc_tqd_mjc}  
   The Mapping preview pane updates to show the selected service, or the first service in a list of services.
5. Create a rule to determine how Service Observability should map internal services to the observability entities using tag keys and values.
   1. Select the data source for this map.
   2. Enter the tag key that you want to use to map the observability data to the service.  
      The key can be any tag you use on your observability metadata, for example `service`. The entered key must match the tag you use in the observability metadata and is case-sensitive.  
      Note:  
      If you use more than one tag to represent a service, you can create an exception. For example, if most tags use `service` except for database metrics, which use `service_name`, you can create an exception for the database metrics.
   3. Manually enter a tag value or choose one from the drop-down menu.  
      Note:  
      Values are case-sensitive.
      Values can be strings that are from your observability metadata, like a service name, or they can be a variable used to represent multiple instances, for example `$(service)`. When your key represents a service, a drop-down menu shows fields from the corresponding CI that can be used as a variable. If you choose to use a variable, be sure that the values resolve to values sent in the observability data.  
      Note:  
      If you selected more than one service to map, the drop-down displays only the fields that are common to all selected services.

   {#create-and-manage-observability-data-mappings__substeps_wvb_lsz_hgc}  
   You can now test your mapping or add exceptions.
6. **Optional:** If some of your entities use different key names or values, create exceptions to the default policy by configuring them in the Exceptions card.
7. Test the mapping.  
   The Mapping preview panel shows the test results for the first service mapped. Service Observability sends a request through the connection and returns the entities found using the provided mapping. If you created an exception using a different source, the panel shows the results from each source separately. If the results don't seem correct, try reconfiguring the mapping by changing the tag key or value.

   If you have more than one service mapped, use the Service drop-down
   menu to select and test a different service.
8. Select Save mapping.

## Result

On the Observability tab of the Service details page, dashboards and charts show metrics for the entities found from the mapping.

*[\>]: and then