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

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# On-board a Company

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

* Release version: Yokohama
* 
* Updated January 30, 2025
* 
* ![](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 efficiently and securely on-board customers or companies using domain separation in a ServiceNow instance for Cloud Provisioning and Governance services.
Domain separation enables a multi-tenant architecture, ensuring that each company's resources, configurations, and policies remain isolated and controlled within their respective domains.
Show full answer Show less  

## Key Features

* **MID Server Setup:** Each domain/company requires dedicated MID Servers to manage cloud discovery, provisioning, and orchestration. MID Servers act as communication agents between ServiceNow and external systems. A MID Server user with the `midserver` role must be created in the global domain to explore targets across domains.
* **Resource Blocks and Profiles:** Resource blocks are created in the global domain only, linking Configuration Items (CIs) with cloud resources and acting as middleware between catalog items, Cloud API, and CMDB. Resource profiles define allowed attribute values and are cloud provider-agnostic. Mappings to resource profiles are created in child domains, enabling domain-specific resource pools and filters.
* **Governance with Quotas, Policies, Pools, and Permissions:**
  * **Quotas** limit resource usage by groups or users to avoid waste.
  * **Policies** enforce rules such as approval workflows, IP reservations, or form field modifications, and can be global or domain-specific.
  * **Pools** filter available resource values for catalog requests, scoped to domains.
  * **Permissions** control user group access to Cloud Provisioning and Governance features and records, configured per domain.
* **Cloud Catalog Items and Templates:** Service Providers can create global catalog items based on templates for all domains or custom catalog items per domain. Templates support provisioning using tools like Terraform, Azure Resource Manager, and AWS CloudFormation. Sensitive data should not be included in global templates to avoid exposure.
* **Capacity Limits and IP Address Management:** Capacity limits restrict cloud resource attributes per domain, including virtual machines, CPUs, and storage. Integration with IP Address Management (IPAM) tools such as Infoblox supports domain-separated management of IP addresses, networks, and subnets.
* **Business Hours Scheduling:** Enables scheduling of start, stop, and deprovisioning actions for VM stacks based on business hours, holidays, and weekends. Global schedules apply to all domains, whereas domain-specific schedules require no active global schedules.

## Key Outcomes

* Efficient on-boarding of companies with strict domain separation ensuring secure and isolated management of cloud resources and processes.
* Centralized administration of MID Servers, resource blocks, profiles, quotas, policies, and permissions that respect domain boundaries.
* Flexible governance capabilities allowing Service Providers to enforce quotas and policies globally or on a per-domain basis to meet customer-specific requirements.
* Ability to provision and manage cloud resources via catalog items and templates tailored by domain, supporting automation and lifecycle management.
* Enhanced operational control through scheduling and IP address management integrated with domain separation.

## Next Steps

To fully leverage domain separation in Cloud Provisioning and Governance, review domain admin considerations for provisioning cloud resources and managing lifecycle operations for each domain you manage in your instance.  
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=yokohama&pubname=yokohama-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=yokohama&pubname=yokohama-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=yokohama&pubname=yokohama-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=yokohama&pubname=yokohama-servicenow-platform&ft:locale=en-US)
  * [Configuring MID Servers](https://www.servicenow.com/docs/access?context=c_MIDServerConfiguration&version=yokohama&pubname=yokohama-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/XoNUja3xVSrRnVmApi3aMg "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/W2eqqSra8f5s8R53F7SORQ "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/IZjjZnudGUfk4RkwG6Kxcg "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/4POWJV~EFnutiqp~ACkSQQ "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/LQwMiW4rqe7qkTx1gQJg8Q "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/Mw_SR6PafZ2OPO8IdH62xA "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/kFotTZHmT2hwZmZmDkDQew "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 workflows. A cloud policy 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 workflows. A cloud policy gives you system-wide control over approvals, resource operations, blueprint operations, or catalog item settings. |
  | [Pools](https://www.servicenow.com/docs/jLvreWC1QfVwFrtmB2Bb7A "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/LJekVrAhX0hzNm9S_PkomA "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/LJekVrAhX0hzNm9S_PkomA "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/kFotTZHmT2hwZmZmDkDQew "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 workflows. A cloud policy 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/qic_pvAYLBJcRcfDVquKmA "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/8uAnuR2mofXYtgmnI14uMw "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/17x58AvZjSaaht_yDQS9~g "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/9dmKTNB1xw5SwZqH1FPh2A "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, the
  request, virtual machine, and all components in the stack are stored in its respective
  domain. Subsequent operations for a domain are also handled in same manner. You can
  generate a catalog item based on Terraform configuration management template, or use
  Azure Resource Manager and AWS CloudFormation templates.
* [Create Cloud Templates](https://www.servicenow.com/docs/gIdpgEQRixhZ92fK3LyyiA "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 sensitive and private information such as CIDR values, IP addresses, credentials,
  etc, to the template content, if setting up the catalog item as a global catalog item.
  The sensitive 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/_1Xlmf0gJ8W2l3HnVV8PDg "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/6fH7Gba8iNYachdemt9ULw "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/yzRK7~aCrIZQTgfpLHrWBg "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/3jurPZXNvSiItAB6_bWYRw "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/X8c4RGhGbo~uh5p8LiecTw "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/9D669qBvm3pNGZ8v0Tf3sA "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.").