Domain support and schedules

  • Release version: Washingtondc
  • Updated February 1, 2024
  • 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 in ServiceNow allows for the organization of data, processes, and administrative tasks into distinct domains. This functionality is crucial for managing access and visibility of data among users. To enable domain separation for schedules, the Domain Support [com.glide.domain] plugin must be activated. Proper configuration ensures that data is categorized appropriately for service provider needs.

    Show full answer Show less

    Key Features

    • Domain Separation: It applies to various aspects including user interface, reporting, and data aggregation.
    • Instance Setup: The application owner must configure the instance to operate across multiple tenants effectively.
    • Script Utility: A sys.script utility is available to implement base system domain support for schedules, adding necessary columns and attributes to relevant tables.

    Key Outcomes

    By utilizing domain separation, ServiceNow customers can enhance data management and ensure service providers and their customers have appropriate visibility into relevant information. The implementation of the provided script utility aids in maintaining data integrity across parent and child records, ensuring seamless operation within the defined domains.

    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.