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

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil IT Service Management

ft:clusterId :

    - itsm

bundleId :

    - itsm

workflow :

    - Technology


---

# Change Management integration with ITOM Visibility

# Change Management integration with ITOM Visibility {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Change Management integration with ITOM Visibility

This integration is automatically enabled for organizations subscribed to ITOM Discovery or ITOM Visibility, allowing configuration items (CIs) with IP addresses involved in change requests to be maintained automatically.
Change request fulfillers can also manually initiate discovery processes for CIs.
This integration enhances the accuracy and currency of CI data within change management processes.
Show full answer Show less  

## Enabling Integration

* Install and configure required plugins based on subscriptions:
  * ITOM Discovery: Discovery plugin (com.snc.discovery)
  * ITOM Visibility: Discovery plugin (com.snc.discovery) and Service Mapping plugin (com.snc.service-mapping)

## Integration with ITOM Discovery

When activated, Change Management adds three configurable properties to control discovery triggering in the Change Properties module:

* **Discovery Trigger Mode:** Defines whether discovery for affected CIs is triggered automatically, manually, both, or off.
* **Manual Trigger States:** Lists change request states where manual discovery initiation is allowed, making the "Initiate Discovery" link available.
* **Automatic Trigger States:** Lists change request states that automatically trigger discovery upon state transition.

Note: For multi-language environments, state values must be set to internal values.

Additional fields added to affected CIs include:

* **Discovery State:** Indicates discovery status (In Progress, Completed Successfully, Completed with Warning/Error, Cancelled) with clickable links to discovery logs.
* **Discovery Last Updated:** Timestamp of the last discovery execution.

The "Initiate Discovery" link appears in related links when manual or both triggers are configured and the change request is in the specified states. Discovery state and timestamps update dynamically upon discovery execution.

## Integration with ITOM Visibility

This integration allows viewing changes within the context of application services through service maps, showing changes at both service and individual CI levels. When the ServiceNow AI Platform is configured for change validation, changes are evaluated and marked as approved or not.

Change indicators on service instance maps use balloon icons to represent:

* Light gray: Unapproved change without impact on service behavior.
* Dark gray: Unapproved change affecting service behavior.
* Green: Approved change when AI validation is enabled.
* Double balloon: Multiple changes occurring close in time.

## Benefits for ServiceNow Customers

* Automates maintenance of CI data linked to change requests to improve accuracy.
* Enables manual or automatic discovery triggering tailored to organizational processes.
* Provides visibility of changes within application service maps for better impact analysis.
* Incorporates AI-based validation to ensure changes are evaluated and approved consistently.  
If your organization is subscribed to ITOM
Discovery or ITOM Visibility, integration with these ITOM products is automatically enabled. With this integration, any configuration
item (CI) with an IP address that is part of a change request process can be maintained
automatically. Change request fulfillers can also manually request the discovery process for a
CI.

## Enabling integration {#change-mgmt-integ-wth-Discovery__section_epy_wcf_d4b}

Depending on subscriptions purchased by your organization, you must install and configure the following plugins:

* For ITOM Discovery - the Discovery plugin (com.snc.discovery)
* For ITOM Visibility - the Discovery plugin (com.snc.discovery) and Service Mapping plugin (com.snc.service-mapping)
{#change-mgmt-integ-wth-Discovery__ul_tyv_kcf_d4b}

## Integration with ITOM
Discovery {#change-mgmt-integ-wth-Discovery__section_gds_xcf_d4b}

When Discovery is activated, Change Management exposes three new properties within the Change Properties module (Change ManagementAdministrationChange Properties):{#change-mgmt-integ-wth-Discovery__table_jh5_w4s_jdb__entry__2}

| Property | Description |
|-|-|
| Configures how discovery is triggered for Affected CIs (automatically, manually or off) | Determines whether to trigger discovery for the affected CIs automatically, manually, both, or not at all. Type: Choice list Values: Off, Both, Automatic, Manual Default value: Off Note: If the property below is set to Both, and you trigger discovery manually, then the automatic discovery will not be triggered for that change request. |
| List of Change Request states (comma-separated) where discovery can be triggered manually | Defines the change request state values to allow discovery to be manually initiated. For these defined state values, the Initiate Discovery related link is available. Type: String Default value: Implement, Review Note: If there are multiple languages used on the instance, then this property needs to be set to the internal state value for Review. |
| List of Change Request states (comma-separated) where discovery triggers automatically. E.g. when the Change Request's state changes to Review | Defines the change request state values for which discovery is automatically triggered. Discovery initiates when transitioning to the state values listed. Type: String Default values: Review Note: If there are multiple languages used on the instance, then this property needs to be set to the internal state value for Review. |
[Table 1. Change Management properties for Discovery]

{#change-mgmt-integ-wth-Discovery__table_jh5_w4s_jdb}  
Note:  
For the last two properties in the above table, if there are multiple languages used on the instance, then the property needs to be set to the internal value, which is 0, for Review.  
In addition to the new properties, the Discovery State and the Discovery last updated fields get added to the Affected CI related list. Discovery State provides one of five status values and a corresponding icon to reflect that status:

* In Progress
* Completed Successfully
* Completed w/Warning
* Completed w/Error
* Cancelled
{#change-mgmt-integ-wth-Discovery__ul_fkf_ggv_g2b}

The Discovery State value is presented as a link to the corresponding Discovery log file. The
Discovery last updated field contains a date and time stamp indicating
the last time Discovery was executed.  
If you have opted to manually initiate the Discovery module, or opted for both manual and automatic initiation, then the Initiate Discovery related link appears in the Related Links section when the state of the change request matches one of the defined states in the property. When Discovery is triggered, the values in the Discovery State and the Discovery last updated fields change.Figure 1. Change management integration with discovery

## Integration with ITOM Visibility {#change-mgmt-integ-wth-Discovery__section_g1w_bdf_d4b}

You can view the changes in the context of application services. Service maps available in Service Mapping show changes to an application service as a whole and to the
individual configuration items (CIs) comprising the service.

If the ServiceNow AI Platform is configured to validate changes, all changes are evaluated and rendered as valid or not. If a change is valid, its change record on the service instance map is marked as approved. For more
information about configuring the platform for change validation, see [Managing proposed changes](https://www.servicenow.com/docs/access?context=c_ProposedChanges&version=brazil&pubname=brazil-servicenow-platform&ft:locale=en-US).  
The type of change mark depends on the nature of changes that it represents:

Light gray balloon (![Light grey balloon icon]())
:   Unapproved change that does not influence the service instance behavior. For example, a change in a network path or adding a node to a cluster.

Dark gray balloon (![Dark gray balloon icon]())
:   Unapproved change that changes the service instance behavior.

Green balloon (![Green balloon icon]())
:   An approved change in deployments where the ServiceNow AI Platform is configured to validate changes.

Double balloon (![Green balloon icon]())
:   Multiple separate changes that happened a short time from each other.
**Related topics**   

* [Discovery](https://www.servicenow.com/docs/access?context=r-discovery&version=brazil&pubname=brazil-it-operations-management&ft:locale=en-US)
* [View the change history of application services](https://www.servicenow.com/docs/access?context=t_ViewCIChanges&version=brazil&pubname=brazil-it-operations-management&ft:locale=en-US)
* [View the change history of application services in Agent Workspace](https://www.servicenow.com/docs/access?context=workspace-view-history-app-service&version=brazil&pubname=brazil-it-operations-management&ft:locale=en-US)

*[\>]: and then