Domain separation and Microsoft Azure Sentinel integration

  • Release version: Yokohama
  • Updated March 12, 2026
  • 2 minutes to read
    • Summarize
    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 Domain separation and Microsoft Azure Sentinel integration

    The Microsoft Azure Sentinel integration supports domain separation, a feature that allows ServiceNow customers to logically segregate data, processes, and administrative tasks across multiple domains. This separation ensures that users only access data relevant to their domain, enhancing security and operational clarity for multi-tenant environments, such as service providers managing multiple customers.

    Show full answer Show less

    Important: Microsoft has extended the deprecation of the Azure Sentinel experience in the Azure portal from March 2026 to March 2027. Customers using Azure Sentinel integration with Security Incident Response (SIR) are strongly advised to migrate to the new Defender portal integration promptly. The Defender integration provides a built-in migration utility to convert Sentinel profiles seamlessly, maintaining incident continuity post-migration.

    Key Features

    • Domain Separation at Runtime: Supports separation across user interface, cache keys, reporting, rollups, and aggregations, ensuring data isolation per domain.
    • Multi-Tenant Support: Enables instance owners to configure the application for multiple tenants, allowing scenarios like a service provider responding to individual tenant customers with visible communication.
    • Role-Based Access: Requires creation of users with the snsi.admin role within each domain to manage Azure Sentinel profile settings securely.
    • Scheduled Job Replication: Scheduled jobs related to Azure Sentinel (such as fetching alerts, syncing comments, updating statuses, processing data, and cleanup) must be replicated per domain and configured to run as the domain-specific admin user to maintain domain separation integrity.

    Practical Steps for Implementation

    • Create domain-specific users with the snsi.admin role using the domain picker during user creation; avoid creating users in the parent domain and later changing domains.
    • Disable existing Azure Sentinel scheduled jobs.
    • Replicate all Azure Sentinel scheduled jobs for each domain and configure each job to run under the respective domain admin user.
    • Apply these configurations to ensure data and process separation across domains while maintaining proper synchronization and incident management within Azure Sentinel integration.

    Why It Matters

    Domain separation is critical for ServiceNow customers operating in multi-tenant or service provider contexts to maintain data privacy and operational autonomy between tenants. By implementing domain separation in Azure Sentinel integration, customers ensure compliance with organizational boundaries and improve management efficiency.

    Additionally, proactively migrating to the Defender portal integration protects your investment in incident response workflows by leveraging Microsoft's latest platform updates and migration tools.

    Domain separation is supported for this application. Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can control several aspects of this separation, including which users can see and access data.

    Important:

    Microsoft has extended the deprecation of the Azure Sentinel experience in the Azure portal from March 2026 to March 2027.

    If you are currently using the Azure Sentinel integration with Security Incident Response (SIR), we strongly recommend migrating to the new Defender portal integration as soon as possible. The Defender integration includes a built-in migration utility that automatically converts your existing Sentinel profiles into Defender profiles, while ensuring continuity of incidents created through Sentinel after the transition. For more information, see Microsoft Sentinel to Defender Migration Guide.

    Support level: Basic

    • Business logic: Ensure that data goes into the proper domain for the application’s service provider use cases.
    • The application supports domain separation at run time. The domain separation includes separation from the user interface, cache keys, reporting, rollups, and aggregations.
    • The owner of the instance must set up the application to function across multiple tenants.

    Sample use case: When a service provider (SP) uses chat to respond to a tenant-customer’s message, the customer must be able to see the SP's response.

    For more information on support levels, see Application support for domain separation.

    How domain separation works in the Microsoft Azure Sentinel integration

    Follow these steps to achieve domain separation:
    • Create a user with the sn_si.admin role in the respective domain.
      Note:
      When you create the profile, use the domain picker to select a domain. Do not create the user in the parent domain and later change the domain of the profile. You should have a user for each domain for your profile with the sn_si.admin role. Use this user to create or modify settings in the profile.
    • Disable existing scheduled jobs.
    • Replicate the following scheduled jobs for every domain:
      • Azure Sentinel Fetching Alerts & Entities
      • Azure Sentinel Comments Sync
      • Azure Sentinel Status Update
      • Azure Sentinel Profile Process
      • Azure Sentinel Process Raw Data
      • Azure Sentinel Data Cleanup
      • Azure Sentinel Historic Comment Pull
    • Change the Run as from the system user to the user with the sn_si.admin role in the respective domain and then run the scheduled job.

    The following example shows how to replicate the Azure Sentinel comments and Status update job and run the job as a system user.

    Replicate Azure Sentinel comments and Status update job and run as system user.