---
sourceDocument: Yokohama IT Operations Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/yokohama/it-operations-management

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Configure Event Management domain separation

# Configure Event Management domain
separation {#ariaid-title1}

* Release version: Yokohama
* 
* Updated January 30, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 1 minute to read

You can configure Event Management for domain separation to create logically defined domains that
limit unauthorized access to data. When domains are separated in Event Management, users can only see and manage alerts and events in their own (tenant) domain.

## Before you begin

Role required: evt_mgmt_admin and evt_mgmt_integration

## About this task

Activate the Domain Support -- Domain Extension Installer plugin and configure the MID Server for Event Management.

The following
Event Management features
have limited domain separation support.
{#t_EMConfigureDomainSeparation__table_owh_2j3_f5__entry__2}

| Feature | Support |
|-|-|
| Event -- alert flow | Supported. Separation is based on the domain user that sent events. User access is required for the credentials of the sending API events or in the configuration of the MID Server reporting events. In a multi-domain environment, each MID Server can serve only one domain according to the integration user that it uses. In the configuration of the connector instance, make sure that the MID Server uses the same domain as the Connector instance.. To configure pull connectors to support custom domain separation, see [Personalize domains for pull connector events to use in event creation](https://servicenow-prod.fluidtopics.net/klCp5FpyBBkIiKsGadcL4g "Configure pull connectors to personalize domain separation of events so you can use them to create events in domains other than the user's currently logged-in or MID Server domain."). |
| Impact calculation | Supported. Segregation is based on the manner in which CIs are segregated. |
| Application services | Partially supported. Segregation is based on the manner in which CIs are segregated. |
| Dynamic CI groups | Partially supported. Segregation is based on the manner in which CIs are segregated. Note: The discovery process does not segregate CIs by domain. |
| Remediation | Supported. While editing alert management rules, users can only apply relevant workflows. For more information on domain separation in the Flow Designer, see [Domain separation and Flow Designer.](https://www.servicenow.com/docs/access?context=flow-designer-domain-separation&version=yokohama&pubname=yokohama-build-workflows&ft:locale=en-US) |
| Alert Aggregation | Supported. In domain-separated environments, alert groups are created only for alerts in the same domain. |
[Table 1. Features with limited domain separation support]

{#t_EMConfigureDomainSeparation__table_owh_2j3_f5}

## Procedure

1. If it is not already active, activate the Domain Support -- Domain Extension Installer plugin.
2. Configure the connector instance to be in the same domain as the MID Server.