Domain-separate a custom table

  • Release version: Zurich
  • Updated July 31, 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 for custom tables in ServiceNow allows you to segregate data across multiple domains, ensuring appropriate data visibility and security. This process involves configuring asysdomainfield and implementing business rules to control domain assignment and propagation. Domain separation is typically applied to custom tables, not system or core tables unless already domain-separated by the platform.

    Show full answer Show less

    Key Steps

    • Create a sysdomain field: Add a new field named sysdomain with the domainid type. ServiceNow automatically configures this field and the related sysdomainpath. This field is critical for associating records with specific domains.
    • Implement business rules to set the domain:
      • By default, records inherit the domain of the user creating them.
      • Add scripted business rules to assign domains based on logic such as the Company field.
      • Use a two-tier approach: a primary business rule attempts to set the domain based on business logic, and a fallback rule assigns the default domain if the primary rule fails.
      • Order of execution matters; rules run sequentially from lowest to highest Order value.
    • Additional fallback logic: If domain remains unset, a secondary business rule examines fields like taskfor (caller/requestedfor) to set the domain based on the user’s domain or revert to the default domain.
    • Domain cascade handling: When a task’s domain changes, related records (workflows, SLAs, approvals, attachments, emails) must have their domains updated to maintain visibility and data integrity. A dedicated cascade business rule handles this synchronization.

    Why This Matters

    Proper domain separation ensures that data is securely partitioned across business units or customers, preventing unauthorized access. Setting the sysdomain field and corresponding business rules guarantees that records and their related data remain consistent within the correct domain context.

    What You Can Expect

    • Custom tables with domain separation will automatically associate records with the appropriate domain upon creation or update.
    • Domain assignment business rules provide flexibility to customize domain logic based on your organization's structure.
    • Domain cascading maintains data consistency across related records, reducing administrative overhead and preventing data leakage.
    • Understanding domain separation concepts and best practices helps optimize performance and security in your ServiceNow instance.

    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
*/