Domain-separate a custom table

  • Release version: Washingtondc
  • Updated February 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-separate a custom table

    This guide details the process and considerations for domain-separating custom tables within the ServiceNow platform. Domain separation is essential for managing data visibility across different business units or clients effectively.

    Show full answer Show less

    Key Features

    • Create a sysdomain field: Establish a new field of type domainid with the column name sysdomain. This automatically configures necessary attributes.
    • Add business rules: Implement business rules to set the domain for newly created records. The first rule attempts to set the domain based on the record’s Company field, while a secondary rule sets it to the default domain if needed.
    • Cascade domain changes: Use the Domain – Cascade Domain – Task business rule to ensure that related records (workflows, SLAs, etc.) reflect any domain changes for tasks.

    Key Outcomes

    By following these steps, ServiceNow customers can effectively manage data segregation through domain separation. This ensures that records are appropriately assigned to the correct domains, enhancing data security and compliance across multiple business units or clients. Customers can expect improved visibility and access control tailored to their organizational structure.

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