Domain separation and Safe Workplace suite

  • Release version: Xanadu
  • Updated August 1, 2024
  • 3 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 Safe Workplace suite

    The Safe Workplace suite applications in ServiceNow support domain separation primarily at the Basic level, except for the Safe Workplace Dashboard. Domain separation allows you to logically segregate data, processes, and administrative tasks into distinct domains, enabling control over user access and visibility for each domain. This separation is critical for organizations that need to partition data and operations securely across tenants or business units.

    Show full answer Show less

    Domain Separation Support Levels

    • Basic: Domain-separated data with logic for proper data routing, caching, and aggregations; global configuration is operational for multiple tenants.
    • Standard: Domain-aware application properties and optional domain-separated business logic configurable by the instance owner.
    • Enhanced: Data-driven processes allow tenant-driven business logic configuration through the UI.

    How Domain Separation Works in Safe Workplace Applications

    Several Safe Workplace applications—including Contact Tracing, Health and Safety Testing, Emergency Outreach, and Emergency Exposure Management—use domain separation by relying on the snimtcoredomain table. This core domain table is essential for scheduled jobs that run separately for each domain, ensuring data and processes are correctly partitioned.

    Admins must enable the Domain separation plugin before working with these applications and their tables, most of which have a sysdomain field to support data partitioning.

    The snimtcoreproperty table extends the system properties to include domain-specific overrides. Properties with sensitive fields (such as password2) display as blank in domain-separated views for security reasons.

    Scheduled Jobs and Domain Iteration

    Scheduled jobs are configured to run per domain by default, with the Domain Iterator option enabled and the Domain Source Table set to Safe Workplace Domains. This setup prevents data processing conflicts and ensures jobs execute within the correct domain context.

    Note that parent-child domain hierarchies are not supported to avoid duplicate job execution. You can configure either a parent or a child domain, but not both simultaneously.

    Working with Domain-Separated Properties

    After installing the Domain separation plugin, domain-separated properties do not appear by default. You need to create overrides for specific domains manually. When adding a new property override, use prefixes to filter properties related to each Safe Workplace application (e.g., snimtcore for Employee Readiness Core, snimtdiagnosis for Emergency Exposure Management).

    Once created, these overrides are visible in the properties list, allowing administrators to manage domain-specific configurations effectively.

    Practical Impact for ServiceNow Customers

    • Enables secure data partitioning and process isolation across multiple tenants or business units using Safe Workplace applications.
    • Provides control over domain-specific configuration and scheduled job execution to prevent data overlap and maintain compliance.
    • Facilitates granular property overrides for each domain, enhancing flexibility in managing application behavior per tenant.
    • Requires enabling the Domain separation plugin and understanding property override management for effective implementation.

    The Safe Workplace suite applications support domain separation at the Basic level with the exception of Safe Workplace Dashboard.

    With domain separation, you can separate data, processes, and administrative tasks into logical groupings called domains. You can then control aspects in each domain, including what users can see or whether they can access the data.

    Domain separation support

    ServiceNow applications that support domain separation might support the separation of data and data routing only, have advanced business logic separation, or support customer-level administration of the application. ServiceNow applications are defined with incremental support levels from the perspective of actual use cases and the people who use them.
    • Basic
      • Data is domain-separated.
      • Logic exists to ensure proper data routing, caching, rollups, and aggregations.
      • Global configuration is operational for multiple tenants
    • Standard
      • Application properties are domain-aware as needed.
      • Business logic can be domain-separated by the instance owner per tenant.
    • Enhanced: Data-driven process enables failsafe configuration by tenants through the UI to drive business logic.

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

    How domain separation works in Safe Workplace applications

    The following applications use the Safe Workplace domain table:
    • Contact Tracing
    • Health and Safety Testing
    • Emergency Outreach (Daily Contact Logs, Privacy Consent, and Privacy Consent (common))
    • Emergency Exposure Management

    Admins must install the Domain separation pluginbefore working with these application tables. Most of those tables contain a sys_domain field so they are able to be domain-separated if they have data that needs to be partitioned by domain.

    • Core domain table: Included in the Safe Workplace plugin is an sn_imt_core_domain table. Domains in this table are iterated when scheduled jobs run.
    • Property table: The sn_imt_core_property table extends the sys_properties table and adds a sys_domain field. Adding that field allows sys_properties values to be overridden for a domain.
    Note:
    Values are handled differently for password2​ fields than for other property types. Therefore, the value displays as blank in the domain-separated properties list view.

    The following tables do not have the sys_domain field:

    • app-imt-checkin
      • sn_imt_checkin_outreach_sysauto_script (extends sysauto_script)
      • sn_imt_checkin_response_criteria
      • sn_imt_checkin_response_option_for_health
      • sn_imt_checkin_response_option_survey
      • sn_imt_checkin_response_script
    • app-imt-diagnosis: task_compliance_result
    • app-imt-tracing
      • sn_imt_tracing_wifi_access_register_job
      • sn_imt_tracing_wifi_access_register_stage
    • app-imt-core: sn_imt_core_sysauto_script (extends sysauto_script)

    Scheduled jobs in applications with this level of domain separation run separately for each domain in the table. Scheduled jobs use the core table as the domain source table, and the Domain Iterator check box is automatically enabled by default when domain separation is installed. When the Domain Iterator option is enabled, the job can run in multiple domains.

    The Domain Source Table value is also set to Safe Workplace Domains by default. If you don't see the tables, verify that the Domain Iterator and Safe Workplace Domains settings are selected, and refresh the instance.
    Figure 1. Domain iterator option selected in the Employee Readiness Core Scheduled Script Execution form
    Domain iterator option selected in the Employee Readiness Core Scheduled Script Execution form.

    Parent-child domains

    Domains that also contain a sub-domain or “child” domain are not supported in these applications. Running a job in a parent domain that has a child would mean running the job twice and thus processing the data more than once. You could add a parent domain or add just the child domain but not both.

    Working with domain-separated properties in the Safe Workplace Suite

    When the Domain separation plugin is installed and you navigate to the Properties page in any of the four Safe Workplace domain-separated applications, their properties do not display by default. You must override properties for a domain before they appear in the list.
    Figure 2. Domain-separated properties list with no properties displaying
    Domain-separated properties list with no properties displaying.
    To display the properties, click New on the Properties page. In the form that creates a new domain-separated property, search in the reference field for the property you would like to override. Enter a specific prefix to narrow your search:
    • sn_imt_core for Employee Readiness Core
    • sn_imt_diagnosis for Emergency Exposure Management
    • sn_imt_health_testing for Health and Safety Testing
    • sn_imt_tracing for Contact Tracing
    Figure 3. Entering a prefix in the Property field to narrow the search
    Entering a prefix in the Property field to narrow the search.
    The properties display with a full description of the overrides.
    Figure 4. System Properties list showing the property overrides
    System Properties list showing the property overrides.
    After you create your domain-separated property override, the form displays the domain-separated properties.
    Figure 5. List showing the domain-separated properties
    List showing the domain-separated properties.

    You can navigate back to the record form by selecting a property name in the list.

    Property functions

    Learn more about how these properties function in the following topics: