---
sourceDocument: Australia IT Operations Management
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/it-operations-management

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# On-board a Company

# On-board a Company {#ariaid-title1}

Release version: Australia  
Updated March 12, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 9 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) 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 On-board a Company

This guide explains how Service Providers can on-board companies or customers within a domain-separated instance for Cloud Provisioning and Governance in ServiceNow.
Domain separation enables a multi-tenant architecture that ensures secure and efficient management of cloud resources and services for multiple clients within a shared instance.
Show full answer Show less  
Key to this architecture is the use of dedicated MID Servers per domain/company, centralized governance, and strict process standards that maintain data integrity and operational separation.

## Key Components and Setup

* **MID Server Configuration:** Create a MID Server user with the `midserver` role in the global domain. Each company/domain must have one or more dedicated MID Servers for cloud discovery, provisioning, and orchestration, ensuring that configuration items (CIs) are assigned to the correct domain.
* **Resource Blocks:** Define resource blocks only in the global domain to maintain a 1:1 relationship with CIs. Resource blocks act as middleware between catalog items, Cloud API, and CMDB, facilitating provisioning logic. Custom resource blocks can be created if base blocks don't meet requirements.
* **Cloud Scripts and OS Profiles:** Use cloud scripts and templates to automate provisioning tasks. Scripts can be mapped to OS profiles to execute during VM provisioning based on image templates.
* **Resource Profiles and Pools:** Create resource profile definitions in the global domain and map them to child domains. Resource pools are domain-specific queries or scripts used to filter catalog item options, ensuring users see only relevant resources.
* **Governance through Policies, Quotas, Pools, and Permissions:** Set up governance controls primarily in the global domain, including policies that can enforce rules, approvals, or script execution. Quotas limit resource usage to prevent waste. Permissions are assigned at the user group level to control access to features and records within specific domains.

## Policy and Permission Management

Policies are collections of conditions and actions used to enforce governance and can be customized per domain using the company or domain field in rule conditions. Policies defined in the global domain apply to all domains unless overridden by domain-specific policies. Permissions should be assigned to user groups representing domain users, enabling domain-level access control.

## Catalog Items and Templates

* Create cloud catalog items based on templates in the global (Service Provider) domain to share with all domains or create custom catalog items per domain.
* Catalog items support deployment, post-provisioning, and Day-2 operations with domain separation ensuring all resources remain within their respective domains.
* Cloud templates can be created and reused; avoid embedding sensitive information in global templates to prevent exposure across domains.

## Additional Features

* **Quota Definitions:** Define and apply quotas per domain to limit cloud resource usage by users or groups.
* **IP Address Management (IPAM):** Integrate with IPAM tools like Infoblox to manage cloud IPs, networks, and subnets within domain-separated environments.
* **Business Hours Scheduling:** Configure start/stop/deprovision schedules for virtual machines at provisioning or post-provisioning stages. Global schedules apply to all domains, with domain-specific schedules allowed only if no global schedules are active.

## Practical Implications for ServiceNow Customers

By following these guidelines, Service Providers can maintain strong domain separation while efficiently managing cloud resources and governance for multiple clients. This approach ensures data isolation, tailored policies, quota management, and delegated permissions aligned to each company's operational needs.

Setting up MID Servers per domain, using global resource blocks and profiles, and carefully configuring policies and permissions enables scalable, secure, and compliant multi-tenant cloud provisioning and lifecycle management within ServiceNow.  
Review the following considerations to on-board customers or companies in a domain
separated instance, for Cloud Provisioning and Governance services.

## Domain separation for Cloud Provisioning and Governance overview {#cust-onboard-dom-sep-sp__section_zzz_4j3_ckb}

Domain separation for Cloud Provisioning and Governance is designed to give Service
Providers a multi-tenant instance architecture that delivers offerings efficiently and
securely to their clients. Strong universal process standards, data-driven process design,
strict governance, and centralized administration maximize these benefits.

## Customer On-boarding by Service Providers {#cust-onboard-dom-sep-sp__section_syl_ylh_ckb}

* [Create the MID Server user and grant the role](https://www.servicenow.com/docs/access?context=t_SetupMIDServerRole&version=australia&pubname=australia-servicenow-platform&ft:locale=en-US).  
  Domain Separation in Cloud Provisioning and Governance is achieved by installing and configuring one or more dedicated MID Servers for each company/ domain that you are managing in your instance. Specifying a MID Server for each domain/company, ensures that Config Items (CIs) are assigned to the intended domain. Each domain has one or more MID Servers setup for cloud discovery, provisioning, and other orchestration.  
  Note:  
  Create a MID Server in the global domain so that you can explore targets in other domains. For more information, see [Set up domain separation for MID servers](https://www.servicenow.com/docs/access?context=c_MIDServerDomainSeparation&version=australia&pubname=australia-servicenow-platform&ft:locale=en-US)

  The Management, Instrumentation, and Discovery (MID) Server is a
  Java application that runs as a Windows service or UNIX daemon on a server in your local
  network. The MID Server enables communication and the movement
  of data between a ServiceNow® instance and external
  applications, data sources, and services.

  To communicate with the instance, MID Servers need a user ID and
  the appropriate role. Create the user ID for a MID Server and grant the ID the
  mid_server role. To prevent MID Server validation failure, the
  system runs business rules to monitor the settings selected for MID Server users.
* [Setting up the MID Server](https://www.servicenow.com/docs/access?context=mid-server-landing&version=australia&pubname=australia-servicenow-platform&ft:locale=en-US).  
  For more information on setting up the MID Server, see:
  * [Installing the MID Server](https://www.servicenow.com/docs/access?context=mid-server-installation&version=australia&pubname=australia-servicenow-platform&ft:locale=en-US)
  * [Configuring MID Servers](https://www.servicenow.com/docs/access?context=c_MIDServerConfiguration&version=australia&pubname=australia-servicenow-platform&ft:locale=en-US)
  {#cust-onboard-dom-sep-sp__ul_f43_ny1_ckb}
* [Resource Blocks in Cloud Provisioning and Governance](https://www.servicenow.com/docs/Eogz~opjOp3RMK7qtq3Ltg "Resource blocks act as a type of middleware component between catalog items, the Cloud API (CAPI), and the CMDB.")

  Create Resource Blocks in global domain as
  there is a 1:1 relationship between CI and resource block. Do not create resource blocks
  in any of the child or leaf domains. Resource blocks act as a process record, so any
  template of a parent domain is visible and works in the child domain.

  Resource blocks act as a type of middleware component between
  catalog items, the Cloud API (CAPI), and the CMDB.
  *
    * If the blocks in the base system do not provide the cloud resources that you need to provision, you can [create
      a custom resource block](https://www.servicenow.com/docs/ms_aW_84XNuzHj~FcNOSiA "If the blocks in the base system do not provide the cloud resources that you need to provision, you can create a custom resource block.").
    * In the Cloud Provisioning and Governance application, script execution is divided into cloud scripts and cloud script templates. Use scripts in catalog items, resource blocks, OS profiles, and use policy scripts to set request form attributes. Policy scripts cannot override user data. For more information, see [Cloud scripts and cloud
      script templates](https://www.servicenow.com/docs/cbGiZJcT8Y~hje4N~2Uybw "In the Cloud Provisioning and Governance application, script execution is divided into cloud scripts and cloud script templates. Use scripts in blueprints, resource blocks, OS profiles, and use policy scripts to set request form attributes. Policy scripts cannot override user data.").
    * [Map a script to an OS
      profile](https://www.servicenow.com/docs/KiVy9DsUuvrj1_kNxANuiw "To execute scripted actions during VM provisioning, you can map a script to an OS profile. The script runs on VMs that are created based on the image template in the OS profile.")

      To execute scripted actions during VM provisioning, you can map
      a script to an OS profile. The script runs on VMs that are created based on the
      image template in the OS profile.
    {#cust-onboard-dom-sep-sp__ul_elj_jrp_ckb}
  * [Define Resource
    Profile](https://www.servicenow.com/docs/XP6KZvqxgdhLVVeH8zK~nw "Resource profiles are cloud provider-agnostic definitions that specify the allowed attribute values for a resource. Resource profiles enable you to control the choices that the user sees when requesting a cloud resource. As a result, you do not need to define a unique blueprint for each variation of the resource.")

    Create resource profile definitions in the global domain, and
    create mappings to these definitions in the child (leaf) domains. Do not delete
    resource profiles without checking with all impacted companies. You can create
    domain-specific resource pools and pools filters for all supported cloud providers.
    As a Domain admin you can see global, domain and custom resource pools specific to
    sub-domains. A resource pool is a query or script that filters a table. You
    configure a resource pool to limit the values that are available to users when they
    request a catalog item. For domain separated resource pools only records of the
    relevant domain are returned.

    Resource profiles are cloud
    provider-agnostic definitions that specify the allowed attribute values for a resource. Resource profiles enable you to
    control the choices that the user sees when requesting a cloud resource. As a result, you do
    not need to define a unique blueprint for each variation of the resource.
  {#cust-onboard-dom-sep-sp__ul_ost_3dl_dkb}
* Administer and set up Cloud Provisioning and Governance for Quota, Policies, Pools,
  Permissions. Governance refers to the limitations that you can set on available cloud
  resources. As an SP you could manage process separation in Cloud Provisioning and Governance policies, and permissions for each company or domain
  you are managing in your instance. Policies are recommended to be set up in global
  domain only. Process separation at a domain level is achievable for governance and
  policies. For customized policy enforcement, use company field in the policy rule
  condition to target a policy towards the particular domain.

  {#cust-onboard-dom-sep-sp__table_rdf_wyt_bkb__entry__2}

  | Type | Description |
  |-|-|
  | [Quotas](https://www.servicenow.com/docs/gdASMFoYRhNJxFAtJordmw "Quotas are limitations or requirements for groups and users on CIs or cloud resources. Use quotas to prevent wasteful resource usage in your cloud environment.") | Quotas are limitations or requirements for groups and users on CIs or cloud resources. Use quotas to prevent wasteful resource usage in your cloud environment. |
  | [Policies](https://www.servicenow.com/docs/qkxi3~h58Z7RWUDTfiG6Xg "A cloud policy can override a property value set by a user, create an approval task, reserve an IP address, pre-populate or hide form fields, execute custom scripts, call the Cloud API, or start or abort subflows. It gives you system-wide control over approvals, resource operations, blueprint operations, or catalog item settings.") | A cloud policy can override a property value set by a user, create an approval task, reserve an IP address, pre-populate or hide form fields, execute custom scripts, call the Cloud API, or start or abort subflows. It gives you system-wide control over approvals, resource operations, blueprint operations, or catalog item settings. |
  | [Pools](https://www.servicenow.com/docs/bKyR0R3HwryI7O2OH6tEeA "A resource pool is a query or script that filters a table. You configure a resource pool to limit the values that are available to users when they request a catalog item.") | A resource pool is a query or script that filters a table. You configure a resource pool to limit the values that are available to users when they request a catalog item. |
  | [Permissions](https://www.servicenow.com/docs/JaAcRov7muwZCdYO4WA5~g "Permissions are user group-level access rights to features in the Cloud Provisioning and Governance application and to specific records in the instance, such as blueprints or cloud accounts.") | Permissions are user group-level access rights to features in the Cloud Provisioning and Governance application and to specific records in the instance, such as blueprints or cloud accounts. |
  [ ]

  {#cust-onboard-dom-sep-sp__table_rdf_wyt_bkb}

  Permissions are user group-level access rights to features in the Cloud Provisioning and Governance application and to specific records in the instance,
  such as catalog items or cloud accounts. You could also set up basic governance
  policies, quotas, pools, and allow the cloud admin user to further customize them based
  on their needs. Create a user-group representing the domain users and associate
  permission to this user group, to set up permissions at a domain level. For more
  information on managing permissions for Cloud Provisioning and Governance roles, see
  [Manage Cloud Permissions](https://www.servicenow.com/docs/JaAcRov7muwZCdYO4WA5~g "Permissions are user group-level access rights to features in the Cloud Provisioning and Governance application and to specific records in the instance, such as blueprints or cloud accounts.").
* Configure and manage policies and manage lease for provisioned stack. A policy rule is
  a collection of conditions and actions. ​If all conditions evaluate to true, the policy
  engine performs the actions. If any condition evaluates to false, the policy engine does
  not perform the actions.

  Set up policies in global domain only when you want the policies to apply to all
  domains. You can customize Cloud Provisioning and Governance and set policies
  specific to a customer or a domain, if you don't want global policies to apply to a
  domain. Use the domain field in policy rule condition to target policy towards the
  particular domain, to enable customized policy enforcement. When global and domain
  policies co-exist, both policies are executed in the sequence of the order configured
  for each policy. In case the values set in the order columns are same, the sequence in
  which the policy is executed is undetermined. Ensure that policy actions are domain
  separated, that is all action rules are within a single domain, and do not depend on
  rules in other domains.

  For more information, see:
  * [Policy governance in Cloud Provisioning and Governance](https://www.servicenow.com/docs/qkxi3~h58Z7RWUDTfiG6Xg "A cloud policy can override a property value set by a user, create an approval task, reserve an IP address, pre-populate or hide form fields, execute custom scripts, call the Cloud API, or start or abort subflows. It gives you system-wide control over approvals, resource operations, blueprint operations, or catalog item settings.")
  * [Configure a cloud policy
    rule](https://www.servicenow.com/docs/H0kxukiXONu~gg4UmYCZAA "A policy rule is a collection of conditions and actions. ​If all conditions evaluate to true, the policy engine performs the actions. If any condition evaluates to false, the policy engine does not perform the actions.")
  * [Create an action for an 'on
    Lease end' policy](https://www.servicenow.com/docs/O1aRCaISapS_Y55jAO_3LA "A policy that is triggered by the on Lease end trigger can send a notification or perform a Start, Stop, or Deprovision life cycle operation.")
  * [Cloud policy example](https://www.servicenow.com/docs/K2rrvnBM7xpYjNOMTnHQ_Q "A base system cloud policy, Lease End ServiceNow, uses the on Lease end trigger that fires when a virtual resource is near the lease end date. If the conditions in the policy rule are met, the policy engine sends a notification to the owner of the resource and performs operations on the resource.")
  {#cust-onboard-dom-sep-sp__ul_bdt_zth_ckb}
* [Create a cloud catalog item](https://www.servicenow.com/docs/XBTLaTxvaxis_uqHfjDUBw "Create a cloud catalog item for provisioning, based on a template or an existing blueprint, and publish the catalog item to provide a service.")

  Create a cloud catalog item for provisioning, based on a
  template and publish the catalog item to provide a service.

  You can create common or global catalogs items based on templates, at the SP
  domain, making it available for all domains you're managing. You can also create custom
  catalog items for each domain/company based on your requirements. A user with domain
  admin/cloud designer roles, can update or delete cloud scripts and cloud script
  templates belongs to domain and sub-domains. You cannot use common catalogs with
  different pool-filter for each domain. Create a custom catalog for each domain
  instead.

  Deployment, post-provisioning, and Day-2 operations are domain separated.
  For example, if a cloud portal user from a specific company orders a VM, the stack, request, virtual machine, and all components are stored in its respective domain. Subsequent operations for a domain are also handled in the same manner. You can
  generate a catalog item based on a Terraform configuration management template, or use
  Azure Resource Manager and AWS CloudFormation templates.
* [Create Cloud Templates](https://www.servicenow.com/docs/aHComcUN_Knle~5xuwcYZA "Create a cloud template and associate the template with a catalog item. Once you've created a template, you can reuse the template to create additional catalog items for the services you want to provision.")

  Do not add private information such as CIDR values, IP addresses, or credentials to the template content if setting up the catalog item as a global catalog item. This information could be exposed to other cloud admins.

  Create a cloud template and associate the template with a
  catalog item. Once you've created a template, you can reuse the template to create
  additional catalog items for the services you want to provision.
* [Set capacity limits on user requests
  for resources](https://www.servicenow.com/docs/MbCJxVfHDpYj9bWk5nucMQ "Capacity limits place restrictions on the attributes of cloud resources such as the number of virtual machines, virtual CPUs, or aggregate storage. You can set limits on resources separately for each logical datacenter in a cloud account.")

  Capacity limits place restrictions on the attributes of cloud
  resources such as the number of virtual machines, virtual CPUs, or aggregate storage. You
  can set limits on resources separately for each logical datacenter in a cloud account.
* [Create a cloud quota
  definition](https://www.servicenow.com/docs/mpt4wNHXXzpvOD1Ri0iTOw "A cloud quota definition specifies the limitations on a resource block. You can use templates or manually create different types of configurations for each quota definition.")

  You can set up separate quota definitions for each domain you're
  managing in an instance.

  You apply quotas to a resource, such as a virtual server,
  datacenter, or a generic cloud resource, and to users of a particular group. You can set a
  per-user limit, and a total limit for the group for the resource. A cloud quota definition
  specifies the limitations on a resource block. You can use templates or manually create
  different types of configurations for each quota definition.
* [Using the IPAM integration](https://www.servicenow.com/docs/XITFzC0GEJH0AUqWDyFnKQ "Use an IP address management (IPAM) tool like Infoblox to manage cloud IP addresses, networks, and subnets within your cloud catalog offerings. However, it's important to note that this functionality is not supported with our template-based cloud catalogs.")

  IP
  address management (IPAM) in Cloud Provisioning and Governance supports domain
  separation.

  If you use an IP address management (IPAM) tool such as Infoblox, you
  can manage cloud IP addresses, networks, and subnets in your cloud catalog offerings.
* [Business hours scheduling](https://www.servicenow.com/docs/gLtgb1AVBh5GM1giXxr53w "You can set up business hour scheduling on all virtual machines in a stack. Business hour scheduling can be set up on stacks at the time of provisioning or on existing stacks.")

  Set up business hour scheduling on all virtual machines in a stack. Business hour scheduling can be set up on stacks at the time of provisioning or on existing stacks. Schedules can be set for when a stack should be
  started, stopped, and/or deprovisioned by defining parameters such as business hours, holidays, long weekends.

  You map a schedule profile to an instance schedule. The
  schedule profile applies to all newly provisioned resources that use the profile. For
  example, a schedule profile can specify the days of the week and times of day when a stack
  should start and stop.  
  Note:  
  Global Business schedules apply to all domains. You cannot set up domain-specific schedules if an active global schedule exists.
* [Create a schedule profile](https://www.servicenow.com/docs/afA3gHk210~cm3_UFXCdrQ "You map a schedule profile to an instance schedule. The schedule profile applies to all newly-provisioned resources that use the profile. For example, a schedule profile can specify the days of the week and times of day when a stack should start and stop.")

  To set up domain-specific lease schedules ensure that no global lease schedules exist. You can only create a domain-specific lease or schedule when no active global policies exist. While you can have multiple leases or
  schedules in draft state, only one lease or schedule can be active.
{#cust-onboard-dom-sep-sp__ul_l5j_t5j_jkb}

## Next Steps {#cust-onboard-dom-sep-sp__section_f3d_4fk_fkb}

For more information on provisioning cloud resources, and making Cloud Provisioning and Governance life-cycle operations available for each domain that you
are managing in your instance for, see [Domain admin considerations](https://www.servicenow.com/docs/5dcWnEdgU8nMyK7trqLWuQ "Before configuring domain separation for customers, ensure that you review the following considerations ahead of provisioning cloud resources for each domain you are managing in the Cloud Provisioning and Governance application.").