Domain support and schedules

  • Release version: Zurich
  • Updated July 31, 2025
  • 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 support and schedules

    Domain separation is supported in schedules within ServiceNow, enabling customers to segregate data, processes, and administrative tasks into logical groupings called domains. This separation controls user access and visibility to data. To enable domain separation for schedules, activate theDomain Support [com.glide.domain]plugin.

    Show full answer Show less

    The Schedule-related tables—Schedule [cmnschedule], Schedule Page [cmnschedulepage], and Timeline Page [cmntimelinepage]—have defined domains. Child tables derive their domain from parent tables using the domainmaster attribute, ensuring domain consistency across related records.

    Key Features

    • Domain Separation at Run Time: Includes separation in UI, cache keys, reporting, rollups, and aggregations to maintain data isolation.
    • Configurable Domain Master Attribute: Child tables use the domainmaster attribute to inherit the domain from parent records, maintaining domain integrity.
    • Custom Domain Support Implementations: Domain separation does not automatically apply to custom implementations during upgrades to avoid overwriting existing configurations.
    • Utility Script for Domain Support: A script (fixscheduledomainsupport.js) is available under Background > Scripts - Background to add domain support to schedule tables. This script adds the Domain column to parent tables and the domainmaster attribute to child tables.
    • Script Validation: If the script detects domain mismatches between parent and child records, it stops and logs a warning, preventing inconsistent domain data.

    Practical Application for ServiceNow Customers

    By enabling domain separation for schedules, customers—especially service providers managing multiple tenants—can ensure that data and schedule information remain isolated and accessible only to authorized users within each domain. For example, in a multi-tenant chat service scenario, customers can only see responses from their respective service provider domain.

    Customers should use the provided utility script to migrate any existing custom domain support implementations to the base system support safely. The script enforces domain consistency between parent and child schedule records and prevents configuration conflicts.

    Next Steps

    • Activate the Domain Support plugin to enable domain separation for schedules.
    • Use the fixscheduledomainsupport.js script to implement or migrate to base domain support for schedule tables.
    • Verify domain consistency between schedule parent and child records before running the script to avoid warnings or incomplete migration.
    • Refer to related concepts such as holidays, parent and child schedules, and default schedules to fully leverage scheduling capabilities within domain-separated environments.

    Domain separation is supported in schedules. 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. Activate the Domain Support [com.glide.domain] plugin to enable the domain separation functionality for schedules.

    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.

    Overview

    The records in the Schedule [cmn_schedule], Schedule Page [cmn_schedule_page], and Timeline Page [cmn_timeline_page] tables have a defined domain.
    • The child tables use the domain_master attribute to derive the domain from the parent table.
    • You can find the domain_master attribute on the dictionary record for the respective table.
    The following diagram illustrates the scope of domain separation in different schedule tables:
    Figure 1. Domain support for schedules
    domain support for schedules

    Custom domain support implementations

    Domain separation support does not automatically occur when you migrate to a new release containing a custom implementation of domain support for tables such as Schedule Entry [cmn_schedule_span]. This action avoids changing any specific configurations that you may have in place.

    To implement the base system domain support for schedules, a sys.script utility is provided. To run this utility, navigate to Background > Scripts – Background. The script is listed under the com.glide.schedules plugin as fix_schedule_domain_support.js.
    • The utility attempts to add the Domain [sys_domain] column to the Schedule [cmn_schedule], Schedule Page [cmn_schedule_page], and Timeline page [cmn_timeline_page] tables.
    • It then attempts to add the domain_master attribute to the Schedule Entry [cmn_schedule_span], Other Schedule [cmn_other_schedule], Timeline Sub Item [cmn_timeline_sub_item], and Timeline Page Span Style [cmn_timeline_page_style] tables.
    • If the script finds existing records between a child and parent record that have differing domain, the script does not introduce the domain_master attribute to the child table.
    For example, consider the relationship of the Schedule [cmn_schedule] (parent) and Schedule Entry [cmn_schedule_span] (child) tables. If the Domain [sys_domain] column is available on both tables in the upgrading instance, the utility must migrate to the base system implementation of domain support for schedules.
    • If the script detects records where the child Schedule Entry [cmn_schedule_span] domain differs from its parent Schedule [cmn_schedule] domain, it stops executing and logs a warning message.
    • If the script does not find differing records, it deactivates and limits read access to the Domain [sys_domain] and Domain Path [sys_domain_path] columns on the Schedule Entry [cmn_schedule_span] table.
    • Finally, the script adds the domain_master=schedule attribute to the dictionary file for the Schedule Entry [cmn_schedule_span] table.
    Note:
    The domain_master attribute ensures that the child and parent record domains remain the same as the domain for the child that is derived from the specified reference field.