Domain separation application properties

  • 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 application properties

    The Domain Separation plugin introduces two new tables—System Application Property(sysapplicationproperty) andSystem Application Property Value(sysapplicationpropertyvalue)—to provide service providers with enhanced flexibility in customizing applications that use domain separation. These tables address the limitation of the existing non-domain-separated System Properties table (sysproperties), enabling different configurations per domain without needing custom code.

    Show full answer Show less

    Key Features

    • Domain-specific customization: Developers can define properties that vary across domains, enabling applications to behave differently based on domain context.
    • Override mechanism: When retrieving property values, the system first checks the Application Property table; if no domain-specific value exists, it falls back to the base System Properties table.
    • Scoped application support: Properties are uniquely identified with scope prefixes, allowing differentiated values per application scope and domain.
    • Property types and configuration: The sysapplicationproperty table supports various data types (string, boolean, integer, time zone, color, etc.) and includes metadata such as usage notes and role-based read/write access control.
    • Domain and scope columns: In the sysapplicationpropertyvalue table, properties can be set specifically for each domain and scope, facilitating granular control.
    • New APIs: The GlideApplicationProperty API provides scriptable methods to interact with domain-separated application properties in both global and scoped apps.

    Practical Impact for ServiceNow Customers

    Service providers can now configure applications more easily for multiple customers (domains) with varied requirements without modifying code for each domain-specific behavior. For example, a setting like “First day of the week” can have Sunday in the parent domain and Monday in a child domain, managed entirely through these new tables.

    This approach streamlines multi-domain application management, reduces development overhead, and ensures consistent application behavior tailored per domain and scope.

    Next Steps

    • Activate the Domain Extension Installer (com.glide.domain.mspextensions.installer) plugin if the new tables are not available.
    • Leverage the new tables to define and override application properties per domain and scope.
    • Use the provided GlideApplicationProperty APIs to programmatically manage these properties within scoped or global applications.
    • Refer to domain separation best practices and use domain selection menus to optimize configuration.

    The Domain Separation plugin has two new tables to give service providers more flexibility in customizing their applications that use domain separation. These tables are the System Application Property table [sys_application_property] and the System Application Property Value table [sys_application_property_value].

    New tables offer more options

    With service provider (SP) applications, certain actions can vary depending on the domain. However, the ServiceNow® base system System Properties [sys_properties] table is not domain-separated, so it doesn't satisfy the requirements for applications that use domain separation.

    Each SP customer may want to customize their applications differently. Previously, features that could be customized were defined as only one global value. Application developers need a more flexible table. Now you can modify your application without having to create code every time you want to add or change the functionality.

    How overrides work in the new tables

    Developers typically use the ServiceNow System Property [sys_properties] table to create various functions in applications. If you wanted to develop an application to behave differently in different domains, you'd have to customize it yourself.

    In the Paris release, the new Application Property [sys_application_property] table simplifies that customization. Instead of going directly to the System Property table for a value, the application property table goes to the System Application table first. This new table now stores the logic that you require to configure your application. If it finds a property in the new table, it uses that content. If there is no information in that table, it moves on to the base system properties table.

    When you configure support for domain separation, you can add domain logic to this new Application Properties table. This table can contain properties that don't exist in the System Properties table. Or you can add properties to the configuration table that can override any property that you select in the System Properties table.

    For example, let's say that you want to configure an application with a First day of the week feature. Sometimes, you might want the first day of the week to be Sunday. In other cases, you might want the first day of the week to be Monday. In the base system table, there might be only one Day 1 option, which is Sunday. With the new table, you can store another property, making Day 1, Sunday, and a child domain, Monday.

    This figure shows how the system draws properties from the Application Property table before going to the System Property [sys_properties] table.New table goes to sys_application_property table before going to sys_properties table.

    How scoped apps work in the new table

    The new Application Properties table is supported from scoped applications. The application property name, similar to the system property name, is unique, which means that it is prefixed with the scope name if it is not global. The scope of an application impacts your configuration. The scope may determine which Day 1 is defined as Sunday and which as Monday. You can use the same property but customize it so that Day 1, Sunday is the parent domain and Day 1, Monday is the child domain. In the new table, there is both a domain column and a scope column, so you can set these properties for each.

    You can use the Expand Domain Scope view in the sys_application_property_value table to show all overrides, as shown in the following image.

    Expanded application properties table
    Note:

    If those tables are not available, make sure that you have activated the Domain Extension Installer (com.glide.domain.msp_extensions.installer) plugin.

    New application property tables

    The new System Application Property [sys_application_property] table contains these fields:

    • name
    • description
    • type (choice of string, true|false, integer, time zone, color, and so on)
    • default_value
    • property (reference to sys_properties)
    • usage_notes
    • read_roles
    • write_roles
    • unique key: (name)
    The new System Application Property Value [sys_application_property_value] table contains these fields:
    • sys_application_property (ref to sys_application_property)
    • sys_domain
    • sys_overrides
    • value
    • unique key: (sys_application_property, sys_domain)

    New APIs

    The new APIs are also supported in scoped apps. Domain-separated application properties have distinct APIs. The GlideApplicationProperty API has two new scriptable methods, available in both global and scoped applications. See GlideApplicationProperty - Scoped, Global to learn more about these new APIs.