• 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. This includes domain 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.

Use case: When a service provider (SP) uses chat to respond to a tenant-customer’s message, the client must be able to see the SP's response.

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:

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.