Domain support and schedules

  • Release version: Yokohama
  • Updated January 30, 2025
  • 2 minutes to read

    • 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.