Domain-separate a custom table

  • Release version: Yokohama
  • Updated January 30, 2025
  • 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-separate a custom table

    Domain separation in ServiceNow allows you to create custom tables that are segregated by domain, ensuring data isolation and security across different organizational units. This process involves adding a specific domain field to your custom table and implementing business rules to manage domain assignment and maintain domain integrity for related records.

    Show full answer Show less

    Key Steps to Domain-separate a Custom Table

    • Create a sysdomain Field: Add a new field of type domainid named sysdomain to your custom table. This field is reserved and automatically configured by the platform, including the creation of a corresponding sysdomainpath field.
    • Implement Business Rules to Set Domain:
      • Without business rules, the domain defaults to the current user's domain.
      • With business rules, domain assignment is scripted, typically based on the related Company field.
      • Use rules similar to Domain - Set Domain – Task to assign the domain and Domain – Default – Task to assign a default domain when the first rule fails.
      • Review the order of business rules carefully to ensure proper priority and execution flow.
    • Fallback Business Rule: If initial domain assignment fails, add a secondary business rule that uses the taskfor field (based on caller or requestedfor) to assign the domain based on the user’s domain or defaults to the default domain.
    • Domain Cascade Rule: Implement a cascade business rule to update the domain on all related records (e.g., workflows, SLAs, approvals, attachments, emails) whenever the domain of a task record changes. This ensures all related data remains accessible within the correct domain context.

    Why This Matters

    Domain separation is critical for customers managing data across multiple business units or customers within one ServiceNow instance. Proper domain separation ensures data security, compliance, and efficient data management by enforcing domain boundaries on custom tables and their related records.

    Additional Considerations

    • Do not domain-separate base system tables or tables already domain-separated by the platform’s Domain Separation plugin.
    • Carefully manage and test business rule order and logic to ensure accurate domain assignment.
    • Use the cascade domain business rule to maintain domain consistency across related records.
    • Monitor domain logs and performance considerations related to domain separation.

    You may need to create custom tables in separate domains. This topic covers both the procedure and the concept behind domain-separating a custom table.

    1. Create a sys_domain field

    Note:
    If a system table or a table has not been domain-separated by the Domain Separation plugin, it's best not to domain-separate it.
    Use these points as a guideline to create a sys_domain field.
    • Create a new field as a domain_id type.
      • Column Name: sys_domain
      • Other attributes: Defined automatically
    • The Sys_domain_path is created automatically.

    The column name sys_domain is reserved in the ServiceNow AI Platform, which means that the system recognizes it and automatically applies the appropriate field type and attributes for you. This automatic configuration also creates a corresponding sys_domain_path field.

    • Set the column name to sys_domain rather than using the label.
    • Domain separation is not appropriate for every table. In general, if a table is part of the base instance and that table does not have a sys_domain field, you should leave it that way.

    A sys_domain field is created automatically when you create a domain_id type field with the name “sys_domain."

    2. Add a business rule to set the domain

    Without business rules
    The domain is set to the current domain of the user who creates the record.
    With business rules
    The domain is assigned using scripted logic, typically based on the Company field.

    In addition to a sys_domain field, custom tables need a business rule similar to Domain - Set Domain – Taskto set the value of the domain field. In addition, you will need Domain – Default – Task, which moves records without a domain to the default domain if the first rule fails to assign a domain.

    On the task table, review the business rules for Domain. Pay particular attention to the Order field. The priority of execution is given by the Order field from low to high.

    The first rule that runs, Domain – Set Domain – Task, attempts to set the domain of the record based on the record’s Company’s Domain.

    If the first rule fails to find an appropriate domain, the second rule, Domain – Default – Task, executes. This rule sets the domain of the record to the default domain.

    Finally, if the domain of a task record changes, the Domain – Cascade Domain – Task business rule changes the domain on all records related to the task, such as workflows, metrics, SLAs, and attachments.

    3. Add a business rule if Step 2 failed

    If the initial business rule fails to set a domain and the domain is still empty or global, a second business rule runs. This rule examines the task_for field that is based on the caller or requested_for field. This rule is checking to see if you can set the domain of the record based on the user’s domain. If not, the business rule sets the domain to the default domain.

    Following is a sample script for the business rule:

    /* essentially
If (task_for is set)
  set the domain to the user's domain
ELSE
  set the domain to the default domain
*/

    4. Domain – cascade domain – task

    Tasks can have many related tables that work together for business objectives. These related records include workflow, SLA, approvals, attachments, and email. If the domain of a task changes, the related records domain must change, too, so they remain visible to users in the new domain.

    This Cascade rule is commonly triggered when you clear records out of the default domain.

    The related records for a Cascade domain contained in the Script are shown similar to the example:

    /*
* Keep domains in sync w/related records for:
* workflow context
* workflow history
* approver tables and related workflows
* attachments
* emails
*/