Create and support multiple domains in the background jobs framework
Background jobs in vulnerability response products are designed to run for long periods of time to perform multiple processes on your records. The background job processors are shipped with the base system that run via the system user and create records in the global domain.
Before you begin
Role required: admin
Procedure
-
Navigate to All > Domain Admin > Domains.
-
Create a domain.
For more information on how to create a domain, see Create a domain.
For every domain created, create a user and assign the user to the domain. Suppose this user as a run_as placeholder for the domain. It’s the equivalent of VR.System user in the global domain. This user needs access to vulnerability data.
-
Change the run_as of the scheduled jobs Scheduled Background Job Manager, and Close the parent background job.
If you have multiple domains created, duplicate this job and change run_as user accordingly. You may also want to keep a copy of the preceding jobs with the run_as user of the global domain in an inactive mode.
Ten processor jobs (for example, Background job processor 10) are shipped with the base system. Change the run as of these jobs to the domain-separated user. If multiple domains are present, then two jobs per domain are sufficient, but these jobs can also be duplicated if necessary. Keep two processor jobs with run_as user in the global domain.
Starting from v20.0 of Vulnerability Response, the following script changes are shipped with the base system.
-
Modify the script include BackgroundJobManager, and add the following line as shown in the following image.
JavaScriptgr.addEncodedQuery("scheduled_job.run_as.sys_domain=" + jobGr.sys_domain + "");[Omitted image "ds-background-job.jpg"] Alt text: Comparison of the updated script include BackgroundJobManager version with the selected version
Note: Trigger the on-demand reapply of any rules from the correct domain.
Parent Topic:Create domain-separated imports for an integration
---
title: Create and support multiple domains in the background jobs framework
description: Background jobs in vulnerability response products are designed to run for long periods of time to perform multiple processes on your records. The background job processors are shipped with the base system that run via the system user and create records in the global domain.
locale: en-US
canonical_url: https://www.servicenow.com/docs/r/australia/security-management/vulnerability-response/create-support-multiple-domains.html
release: australia
product: Vulnerability Response
classification: vulnerability-response
topic_type: task
last_updated: "2026-09-10"
reading_time_minutes: 1
breadcrumb: [Create domain-separated imports for an integration, Advanced Vulnerability Response configuration tasks, Vulnerability Response implementation, Vulnerability Response, Unified Security Exposure Management, Security Operations]
---
# Create and support multiple domains in the background jobs framework
Background jobs in vulnerability response products are designed to run for long periods of time to perform multiple processes on your records. The background job processors are shipped with the base system that run via the system user and create records in the global domain.
## Before you begin
Role required: admin
## Procedure
1. Navigate to **All** > **Domain Admin** > **Domains**.
2. Create a domain.
For more information on how to create a domain, see [Create a domain](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-security/t_CreateADomain.md).
For every domain created, create a user and assign the user to the domain. Suppose this user as a run\_as placeholder for the domain. It’s the equivalent of VR.System user in the global domain. This user needs access to vulnerability data.
3. Change the run\_as of the scheduled jobs **Scheduled Background Job Manager**, and **Close the parent background job**.
If you have multiple domains created, duplicate this job and change run\_as user accordingly. You may also want to keep a copy of the preceding jobs with the run\_as user of the global domain in an inactive mode.
Ten processor jobs \(for example, **Background job processor 10**\) are shipped with the base system. Change the run as of these jobs to the domain-separated user. If multiple domains are present, then two jobs per domain are sufficient, but these jobs can also be duplicated if necessary. Keep two processor jobs with run\_as user in the global domain.
Starting from v20.0 of Vulnerability Response, the following script changes are shipped with the base system.
4. Modify the script include **BackgroundJobManager**, and add the following line as shown in the following image.
```
gr.addEncodedQuery("scheduled_job.run_as.sys_domain=" + jobGr.sys_domain + "");
```
\[Omitted image "ds-background-job.jpg"\] Alt text: Comparison of the updated script include BackgroundJobManager version with the selected version
**Note:** Trigger the on-demand reapply of any rules from the correct domain.
**Parent Topic:**[Create domain-separated imports for an integration](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/vulnerability-response/create-domain-separated-imports.md)
| title | Create and support multiple domains in the background jobs framework |
| description | Background jobs in vulnerability response products are designed to run for long periods of time to perform multiple processes on your records. The background job processors are shipped with the base system that run via the system user and create records in the global domain. |
| locale | en-US |
| canonical_url | https://www.servicenow.com/docs/r/australia/security-management/vulnerability-response/create-support-multiple-domains.html |
| release | australia |
| product | Vulnerability Response |
| classification | vulnerability-response |
| topic_type | task |
| last_updated | 2026-09-10 |
| reading_time_minutes | 1 |
| breadcrumb | Create domain-separated imports for an integrationAdvanced Vulnerability Response configuration tasksVulnerability Response implementationVulnerability ResponseUnified Security Exposure ManagementSecurity Operations |