{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":40754,"path":"platform-security/bp-ds-custom-table.md","title":"Domain-separate a custom table","bundle":null,"doc_type":null,"release":"australia","body":"\n# Domain-separate a custom table\n\nYou may need to create custom tables in separate domains. This topic covers both the procedure and the concept behind domain-separating a custom table.\n\n## 1. Create a sys\\_domain field\n\n**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.\n\nUse these points as a guideline to create a sys\\_domain field.\n\n-   Create a new field as a **domain\\_id** type.\n    -   Column Name: sys\\_domain\n    -   Other attributes: Defined automatically\n-   The Sys\\_domain\\_path is created automatically.\n\nThe 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.\n\n-   Set the column name to `sys_domain` rather than using the label.\n-   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.\n\nA **sys\\_domain** field is created automatically when you create a domain\\_id type field with the name “sys\\_domain.\"\n\n## 2. Add a business rule to set the domain\n\n-   **Without business rules**\n\n    The domain is set to the current domain of the user who creates the record.\n\n-   **With business rules**\n\n    The domain is assigned using scripted logic, typically based on the Company field.\n\n\nIn addition to a `sys_domain field`, custom tables need a business rule similar to **Domain - Set Domain – Task**to 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.\n\nOn 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.\n\nThe first rule that runs, **Domain – Set Domain – Task**, attempts to set the domain of the record based on the record’s Company’s Domain.\n\nIf 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.\n\nFinally, 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.\n\n## 3. Add a business rule if Step 2 failed\n\nIf 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.\n\nFollowing is a sample script for the business rule:\n\n```\n/* essentially\nIf (task_for is set)\n  set the domain to the user's domain\nELSE\n  set the domain to the default domain\n*/\n```\n\n## 4. Domain – cascade domain – task\n\nTasks 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.\n\nThis Cascade rule is commonly triggered when you clear records out of the default domain.\n\nThe related records for a Cascade domain contained in the Script are shown similar to the example:\n\n```\n/*\n* Keep domains in sync w/related records for:\n* workflow context\n* workflow history\n* approver tables and related workflows\n* attachments\n* emails\n*/\n```\n\n**Parent Topic:**[Domain separation recommended practices for service providers](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/platform-security/bp-domain-sep-recommended.md)\n\n**Related topics**  \n\n\n[Domain separation explained]()\n\n[Domain separation hierarchies]()\n\n[Context and domain separation]()\n\n[Segregating and securing data with domain separation]()\n\n[Alternatives to domain separation]()\n\n[Evaluating the need for domain separation]()\n\n[Benefits of domain separation]()\n\n[How a database query works with domain separation]()\n\n[Domain separation levels of support]()\n\n[Service provider reference architecture]()\n\n[Domain separation terms]()\n\n[Customizing domain properties and themes]()\n\n[Managing domain separation for specific uses]()\n\n[Configuring domain separation with the domain picker]()\n\n[Domain separation performance considerations]()\n\n[Setting up domain hierarchies]()\n\n[Checking domain logs for errors and warnings]()\n\n[Importance of the Default domain]()\n\n[Contains queries and domain access]()\n\n[Domain paths query method]()\n\n[Slow queries and SQL debugging]()\n\n[Before Query business rules]()\n\n[Avoiding domain path in scripts]()\n\n[Domain assignments]()\n\n[Domain separation and the Customer Service Management \\(CSM\\) plugin]()\n\n"}}