---
sourceDocument: Australia Workflow Data Fabric
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/integrate-applications

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Workflow Data Fabric

ft:clusterId :

    - crint

bundleId :

    - crint

workflow :

    - Creator


---

# Domain separation and Stream Connect

# Domain separation and Stream Connect {#ariaid-title1}

Release version: Australia  
Updated March 12, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 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 Domain separation and Stream Connect

Domain separation in Stream Connect allows ServiceNow customers to logically segregate data, processes, and administrative tasks into distinct domains.
This separation controls user access and visibility to data, supporting multi-tenant environments where different customers or departments operate within the same ServiceNow instance.
Stream Connect fully supports domain separation, ensuring that application properties, business logic, and data tables are appropriately domain-aware.
Show full answer Show less  

## Key Features

* **Support Levels:** Stream Connect provides standard support for domain separation, including domain-aware application properties and tenant-specific business logic configurations.
* **Message Replication:** Key tables involved in message replication, such as Message Replications, Channel Replications, and Kafka Topic Replications, are domain separated. Domain assignment is managed through fields like *sysdomain* and *domainmaster*, ensuring data integrity per domain.
* **Topic Namespaces:** Kafka topics are linked to namespaces, which in turn are associated with ServiceNow domains. This linkage controls which domains can access specific Kafka topics, enforcing domain visibility and ACLs to restrict user interactions appropriately.
* **Producers and Consumers:** Both producers and consumers in Stream Connect respect domain separation. Producers can only send data to topics visible within their domain. Consumer runtime data tables, such as Kafka Streams and Kafka Subscriptions, are domain separated. Domain users create and manage Kafka streams and subscriptions strictly within their domains.
* **Schema Management:** Tables related to schemas and schema registries are domain separated to maintain isolated schema definitions and registries across domains.

## Practical Impact for ServiceNow Customers

By leveraging domain separation in Stream Connect, customers can confidently manage multi-tenant environments with strict data isolation and control. Administrators can enforce domain-specific rules, such as requiring comments on record closures for one tenant but not another, ensuring compliance with organizational policies. Kafka topic access and stream processing are tightly controlled per domain, preventing unauthorized data sharing and simplifying governance. Schema management being domain aware further supports isolated data models per domain, enhancing data integrity and operational clarity.

Overall, domain separation in Stream Connect enables a secure, scalable, and manageable architecture for customers operating multiple tenants or segregated business units within a single ServiceNow instance.  
Domain separation is supported for Stream Connect. 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.

## Support level: Standard {#domain-separation-stream-connect__section_y1q_s5q_tvb}

* Includes all aspects of Basic level support.
* Application properties are domain-aware as needed.
* Business logic: The service provider (SP) creates or modifies processes per customer. The use cases reflect proper use of the application by multiple SP customers in a single instance.
* The instance owner must configure the minimum viable product (MVP) business logic and data parameters per tenant as expected for the specific application.
{#domain-separation-stream-connect__ul_tfh_drj_xkb}

Sample use case: An admin must be able to make comments required when a record closes for
one tenant, but not for another.{#domain-separation-stream-connect__p_ssc_nfg_h1c}

For more information on support levels, see [Application support for domain
separation](https://www.servicenow.com/docs/access?context=domain-separated-apps&version=australia&pubname=australia-platform-security&ft:locale=en-US).{#domain-separation-stream-connect__p_tsc_nfg_h1c}

## Message replication {#domain-separation-stream-connect__section_z4y_glf_d1c}

Records in the following Stream Connect Message Replication tables are domain separated.

* Message Replications \[sys_sc_message_replication\]
* Channel Replications \[sys_sc_channel_replication\]
* Message Replication Statistics \[sys_sc_channel_replication_metric\]
* Kafka Topic Replications \[sys_kafka_topic_replication\]
{#domain-separation-stream-connect__ul_gy1_4lf_d1c}

The domain for a message replication record is specified in the record's sys_domain field.

For channel replication and replication metrics records, the domain is determined by the domain_master attribute. The domain_master attribute uses a reference field's domain to determine
the domain for the current record. A channel replication record gets its domain from the referenced message replication record. A replication metrics record gets its domain from the referenced channel replication record.

A Kafka topic replication record has the same domain as its associated channel replication record because the Channel Replications table is a parent of the Kafka Topic Replications table.

## Topic namespaces {#domain-separation-stream-connect__section_tcs_y5q_tvb}

You can use topic namespaces to configure which domains can access a Kafka topic on a domain-separated instance. In ServiceNow, Kafka topics are linked to a namespace. Namespaces can be linked to ServiceNow domains. When a namespace is assigned to a specific domain, all the topics created with that namespace are also assigned to the namespace's domain. Users can only see and interact with the
topics they have access to, based on domain visibility and access control lists (ACLs).

For more information, see [Managing namespaces and topics in Hermes](https://www.servicenow.com/docs/access?context=managing-namespaces-topics-hermes&version=australia&pubname=australia-servicenow-platform&ft:locale=en-US).

## Producers and consumers {#domain-separation-stream-connect__section_bmj_dbf_pvb}

Stream Connect producers and consumers are also domain separated. For producers, you can
produce data only to topics that are visible to the domain.  
For consumers, all the tables used to keep runtime data are domain separated. These tables include the following.

* Kafka Streams \[sys_kafka_stream\]
* Kafka Subscriptions \[sys_kafka_subscription\]
* Kafka Subscription Partition Groups \[sys_kafka_partition_group\]
* Kafka Consumer Statistics \[sys_kafka_consumer_statistics\]
* Kafka Unprocessed Messages \[sys_kafka_unprocessed_messages\]
{#domain-separation-stream-connect__ul_vgr_vrk_rvb}

Domain users can create domain-specific Kafka streams with the topics that are visible to the
domain. When activating a Kafka stream, the subscription and partition groups are created within
the same domain. At runtime, the domain of the partition group is set by the consumer thread so
that all the data is imported to the correct domain. For more information on producers,
consumers, and Kafka streams, see [Using Stream Connect for Apache Kafka](https://www.servicenow.com/docs/W7iAA1mjIeSX5U5jcqzaiw "Connect your Apache Kafka environment to your ServiceNow instance with Stream Connect for Apache Kafka.").

## Schema management {#domain-separation-stream-connect__section_mtk_qls_3bc}

Tables for schemas and schema registries are domain separated. These include the following.

* Stream Connect Schemas \[stream_connect_schema\]
* Standalone Stream Connect Schema \[standalone_stream_connect_schema\]
* Confluent Stream Connect Schema \[confluent_stream_connect_schema\]
* Stream Connect Schema Registry \[stream_connect_schema_registry\]
* Confluent Stream Connect Schema \[confluent_stream_connect_schema\]
* Standalone Stream Connect Schema \[standalone_stream_connect_schema\]
{#domain-separation-stream-connect__ul_jnr_sls_3bc}