--- sourceDocument: Yokohama IT Operations Management sourceDocumentLink: https://servicenow-prod.fluidtopics.net/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 --- # Domain admin considerations # Domain admin considerations {#ariaid-title1} * Release version: Yokohama * * Updated January 30, 2025 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 8 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 Domain Admin Considerations This guidance outlines critical considerations for Service Providers managing domain separation within the Cloud Provisioning and Governance (CPG) application. It focuses on the responsibilities and best practices for domain administrators, ensuring secure, efficient management and provisioning of cloud resources across multiple customer domains. Show full answer Show less ## Domain Administrator Responsibilities * Set up service and cloud accounts in the Cloud Admin Portal, mapping service accounts to appropriate cloud accounts per domain. * Create pre-provisioning operations to configure cloud resources before users provision or perform lifecycle operations. * Maintain strict governance by restricting the domain admin role exclusively to Service Provider (SP) users---not customer Cloud Admin users---to prevent unauthorized cross-domain access and data leakage. * Perform discovery and administration actions using users with `rootadmin` or `cloudadmin` roles, selecting the correct domain context via the domain picker. ## Cloud Account and Service Account Management * Ensure each domain has unique management keys and credentials; avoid sharing these across domains. * Service accounts securely store credentials for cloud providers; cloud accounts logically represent managed cloud infrastructure and can include multiple service accounts. * Follow Day 1 setup guides specific to each cloud provider (AWS, Azure, Google Cloud, VMware) to correctly configure accounts. ## Cloud API (CAPI) and Cloud Scripts * CAPI operates globally (not domain-separated); therefore, scripts must not contain hard-coded sensitive information. * Cloud scripts and templates facilitate automation and resource management but must be carefully managed to maintain security across domains. ## Discovery and Event Management * SPs control top-level domains and retain administrative control without delegated administration to child domains. * Discovery should be run from leaf domains by impersonating domain admins to maintain domain-specific visibility. * Event Management visibility aligns with the service account domain; users only see events linked to their domain's accounts. * Set up event integrations with cloud providers (AWS Config, Azure Alert, Google Cloud Logging, VMware Events) to auto-update the CMDB and monitor health. ## Configuration Management and Catalog Sharing * Integrate with continuous delivery tools like Ansible and Terraform by creating configuration management providers and discovering their resources. * For Terraform catalogs shared across domains, perform module listing in the global domain and use a global MID Server with only Terraform capability to avoid cross-domain issues. ## Automation and Workflow Integration * Use ServiceNow AI Platform rules and workflows to automate Day 2 operations, including communication with cloud APIs and resource management. * Ensure workflows execute in the correct domain context by invoking impersonation scripts that set user context based on service account or order user. ## Budgeting, Tagging, and Billing * Domain-separated budgets allow assignment to groups or users, sending notifications when thresholds are reached. * Tags are used for resource categorization and billing but are not domain-separated; visibility depends on associated CI or billing record domains. * Billing data is domain-specific and configurable to generate reports per domain; scheduled jobs use MID Servers to retrieve and update billing information. ## Next Steps and Best Practices * When creating custom operations or workflows related to resource blocks, always set the proper domain context to ensure security and correct resource targeting. * Review related documentation on lifecycle operations, discovery patterns, and Day 2 setup to fully leverage domain separation capabilities. 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. ## Domain administrator activities in a Service Provider's organization {#domain-admin-workflow__section_hxm_jsp_ckb} The following section lists activities that a domain's administrator performs for the company that a Service Provider manages. Set up service accounts and cloud accounts using the Cloud Admin Portal. Create pre-provisioning operations that you can configure for cloud resources before your users provision them or perform life-cycle operations. Strong universal process standards, data-driven process design, strict governance, and centralized administration maximize the benefits of domain separation in Cloud Provisioning and Governance in a single instance. The domain admin role must strictly be restricted to users in the Service Provider's organization, and not be assigned to the Cloud Admin users from the customer's organization. This restriction enables the SP to ensure that a customer does not get full access to other domain's data. Since data is often shared across multiple clients, as domain admins, don't expose or provide permissions that could result in data leakage. ## Provisioning Cloud resources {#domain-admin-workflow__section_qfq_mg3_ckb} * Ensure that you map relevant service accounts to cloud accounts in each domain. For instance, discovering a primary subscription from Azure cloud creates one or more child service accounts and are created in the same domain. This means that all service accounts in a master subscription from Azure cloud must belong to a single company and domain alone. Log in using a user with a root_admin or cloud_admin role, while setting up cloud and service accounts and running discovery for any domain. Use the domain picker while performing actions such as discovery or cloud and service account creation and mapping. Note: * Cloud Provisioning and Governance does not support the expand and collapse domain scope capability. * For more information on what a user can and cannot access, see [Domain Scope](https://www.servicenow.com/docs/access?context=c_DomainScope&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US) {#domain-admin-workflow__ul_z3c_pcg_lkb} A service account is a secure record on your instance that stores the credential and access information for your provider account. Discovery uses the information to access your provider account to get data on each resource in each specified datacenter. A cloud account is the logical representation in Cloud Provisioning and Governance of all or part of your managed cloud infrastructure. A cloud account can include multiple service accounts --- even service accounts from different providers. For each service account, you specify which datacenters to include in the cloud account. Ensure that management keys and service account credentials are unique to each domain and are not shared. To set up cloud accounts and service accounts for multiple cloud providers, perform Day 1 Setup actions: * [Day 1 setup guide for Amazon Web Services on Cloud Provisioning and Governance](https://servicenow-prod.fluidtopics.net/N2QAr8zFdvuG1oTVl8rfKg "To set up Cloud Provisioning and Governance for the very first time, you perform the procedures in this \"Day 1\" setup guide. Be sure to perform the procedures in order. After you have performed Day 1 setup, you can perform optional Day 2 setup and configuration procedures as needed and in any order. Detailed instructions for each procedure follow this overview.") * [Day 1 setup guide for Azure on Cloud Provisioning and Governance](https://servicenow-prod.fluidtopics.net/pVs9HJhG2bT1qQxdxGilPQ "To set up Cloud Provisioning and Governance for the very first time, you perform the procedures in this \"Day 1\" setup guide. Be sure to perform the procedures in order. After you have performed Day 1 setup, you can perform optional Day 2 setup and configuration procedures as needed and in any order. Detailed instructions for each procedure follow this overview.") * [Day 1 setup guide for Google Cloud Connector on Cloud Provisioning and Governance](https://servicenow-prod.fluidtopics.net/nI9IZ72k2PeusVUKELhf2w "To set up the ServiceNow Google Cloud Connector application for the very first time, you perform the procedures in this \"Day 1\" setup guide. Be sure to perform the procedures in order. After you have performed Day 1 setup, you can perform optional Day 2 setup and configuration procedures as needed and in any order. Detailed instructions for each procedure follow this overview.") * [Day 1 setup guide for VMware on Cloud Provisioning and Governance](https://servicenow-prod.fluidtopics.net/EnWtQGJyjCbGm7LZfdeWfw "To set up Cloud Provisioning and Governance for the very first time, you perform the procedures in this \"Day 1\" setup guide. Be sure to perform the procedures in order. After you have performed Day 1 setup, you can perform optional Day 2 setup and configuration procedures as needed and in any order. Detailed instructions for each procedure follow this overview.") {#domain-admin-workflow__ul_obq_kbp_ckb} * [Cloud API (CAPI)](https://servicenow-prod.fluidtopics.net/Pn~gp0iGHqa2lM2vdcdeSg "The Cloud API (CAPI) enables you to integrate Cloud Provisioning and Governance with cloud providers using REST APIs.") and [Cloud scripts and cloud script templates](https://servicenow-prod.fluidtopics.net/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.") CAPI is not domain separated as, domain separation support in Cloud Provisioning and Governance. Since CAPI is set up at a global domain and shared across leaf domains, ensure that scripts do not contain hard-coded sensitive information such as account details, credentials, or names even in comments or annotations. CAPI enables you to integrate Cloud Provisioning and Governance with cloud providers using REST APIs. Cloud scripts are simple java scripts that use platform features. In the Cloud Provisioning and Governance application, script execution is divided into cloud scripts and cloud script templates. Use scripts in templates, resource blocks, OS profiles, and use policy scripts to set request form attributes. Policy scripts cannot override user data. Cloud script templates are actual executables which are passed to target a virtual machine for execution. Create a cloud template first and then associate it with a cloud script. * [Cloud Discovery](https://servicenow-prod.fluidtopics.net/iXC8jdgXIVXh9T_QHi7P_g "ITOM Visibility cloud discovery solutions enable you to collect detailed information about your cloud-based infrastructure and your resources in major cloud service providers: Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), IBM Cloud Platform, Oracle Cloud Infrastructure (OCI), and Alibaba Cloud.") Service Providers (SPs) use domain separation to segregate data for each customer. Users in a given domain have visibility only to the data in their own domains or in child domains. SPs typically control the top-level domain, which gives them visibility to data associated with all domains. Though domain separation support for Discovery is considered Level 2, there is no delegated administration to the child domains in Cloud Provisioning and Governance. The SPs must retain administrative control. As a SP, always run discovery from a leaf domain by logging in as or impersonating a domain administrator to discover your cloud resources. Cloud Discovery provides a wizard that allows you to create and run cloud schedules in a single interface. When you create a schedule with the Discovery Manager, you select the accounts to discover, the credentials for accessing these accounts, and the MID Servers to scan the resources. You can then view the results in the Discovery Home page and track any errors that might have occurred. For more information see, * [Discovery Manager](https://servicenow-prod.fluidtopics.net/mvUB4lhtHGGrh93mggIcpw#discovery-manager "Create schedules for discovering cloud resources based on the cloud discovery method you choose; that is, service accounts or IP ranges.") * [Running discoveries in your network](https://servicenow-prod.fluidtopics.net/z1YAnBcRkarsV70KmkIhPw "You can run discoveries from schedules or scripts to create configuration items, define subnets, or to find resources in AWS and Azure clouds.") * [Microsoft Azure Cloud Discovery](https://servicenow-prod.fluidtopics.net/iMXKXsU7K2dnNRjDU4ObTg "If your cloud resources are in an Azure cloud, you must create a user identity called a service principal that grants permissions to the MID Server to access selected resources.") * [VMware Cloud Discovery](https://servicenow-prod.fluidtopics.net/A9win3bz0rwBnjYAZxjuXg "Applications that access VMware cloud resources need access to VMware credentials.") * [Google Cloud Platform Discovery](https://servicenow-prod.fluidtopics.net/1WoPYkwVs~JqTsag4W5hdA "Discovery finds Google Cloud Platform and its components. Discovering some of these resources may require updating to the latest version of the Discovery and Service Mapping Patterns application from the ServiceNow Store.") * [IBM Cloud Discovery](https://servicenow-prod.fluidtopics.net/oaXn9b1UuCAAE46P_5_h7w "If your cloud resources are in an IBM cloud, create credentials that can access your IBM account.") {#domain-admin-workflow__ul_flx_p2k_dkb} {#domain-admin-workflow__ul_r25_wdk_dkb} * Set up and configure event management to receive external events and generates alerts based on event and alert management rules. The visibility of events depends on the associated service account's domain. Only users belonging that domain can see the event details for processed events. Events that are not associated to a service account are visible to all domains. Monitor the health of business services and infrastructure using a single management console and respond appropriately to any issues that come up. Event Management provides intelligent event and alert analysis to ensure continuity of your business service performance. Event Management receives and processes events via the MID Server. For more information, see * [Exploring Event Management](https://servicenow-prod.fluidtopics.net/gtzgNfX32CchK53IgUaVSw "Explore Event Management to understand its overview, process flow, user roles, and benefits for comprehensive IT issue monitoring and resolution.") * [Event Management Setup](https://servicenow-prod.fluidtopics.net/9GiLZrfpwqDih0r8N5Le6g "After activating Event Management, set it up to receive and process events, and generate and analyze alerts.") * [Configure AWS Config event notifications](https://servicenow-prod.fluidtopics.net/VvALSUxnGShmIWNqsCcyOQ "Configure the Amazon Web Services (AWS) Config service to send event notifications to the ServiceNow instance for any changes in the lifecycle state of a resource.") * [Configure the Microsoft Azure Alert service to auto-update the CMDB](https://servicenow-prod.fluidtopics.net/lHXJClXQGbinwpoNOhYIqw#azure-alert-service-cloud-mgt "Configure the Microsoft Azure Alert service to auto-update the Configuration Management Database (CMDB) without waiting for the next scheduled Cloud Discovery to run.") * [Configure the Google Cloud Logging service to auto-update the CMDB](https://servicenow-prod.fluidtopics.net/MaVDYaoPNWQMPtPGWD6m2g "You can activate the Google Cloud Logging (formerly Stackdriver Logging) service to auto-update Configuration Management Database (CMDB) configuration items (CI) data whenever Google Cloud Connector or your Google account makes a life-cycle state or configuration change to a Google Cloud Platform (GCP) resource. As a result, the CI data in the CMDB is updated without having to wait for Discovery to run.") * [Configure the VMware Events service to auto-update the CMDB](https://servicenow-prod.fluidtopics.net/SYeBsv1S5bO2uh3DIdsLfA "Configure events from the cloud environment to make the necessary updates to your CMDB without additional scanning. The VMware Events service can auto-update CI data in the CMDB whenever Cloud Provisioning and Governance makes a life-cycle state or configuration change to a VMware resource. As a result, the CI data in the CMDB is updated without having to wait for Discovery to run.") {#domain-admin-workflow__ul_rml_sjl_hkb} {#domain-admin-workflow__ul_sw5_gfg_gkb} * The Cloud Provisioning and Governance application supports integration with continuous delivery solutions (also known as configuration management). Create an Ansible or Terraform configuration management provider and then run Discovery on the provider to find its resources. For more information, see [Support for continuous delivery (configuration management)](https://servicenow-prod.fluidtopics.net/OlBJyDuCBuqiXNB_P1uDaA "The Cloud Provisioning and Governance application supports integration with continuous delivery solutions (also known as configuration management). Ansible is supported as the default config management provider.") and [Create a workload provider type](https://servicenow-prod.fluidtopics.net/4iWfuOuaec1wPZQle0GfSA "Create a workload provider type for each new configuration management provider. This information appears in the order catalog form as management attributes that your users can select when provisioning a virtual resource through a configuration management provider.") for each new configuration management provider. This information appears in the order catalog form as management attributes that your users can select when provisioning a virtual resource through a configuration management provider. * If you are creating catalogs based on terraform templates and sharing the catalog with multiple domains. Perform module listing (config discovery) in the global domain. The MID Server should be created in the global domain and should only be assigned with Terraform capability for its discovery. This allows SPs to share catalogs with multiple domains. Warning: Don't create a global MID Server with any other capability other than configuration management for Terraform. Create a common terraform catalog and share it with multiple customers: * Create MID Server in global domain as a global admin. * [Create a Terraform Open Source config provider](https://servicenow-prod.fluidtopics.net/MC9kz03hkBOFfsDUVmaWEw "Create a Terraform Open Source config provider in Cloud Provisioning and Governance. The Terraform Open Source config provider enables Cloud Provisioning and Governance to discover the Terraform Open Source config installables (Terraform templates) and detect changes in them."). Note: Add only "Terraform" as the config provider. * [Create a catalog item based on a Terraform template](https://servicenow-prod.fluidtopics.net/eg3__mvq0PtiwOXDHCsnkg "Create a catalog item from the Terraform template to request cloud resource provisioning. Activated catalog items appear in the cloud user portal."). {#domain-admin-workflow__ul_u35_z5j_jkb} * Cloud Provisioning and Governance supports using ServiceNow AI Platform rules with workflows. Rules are collections of conditions and actions. ​If all conditions of a rule evaluate to true, the system performs the actions. If any condition evaluates to false, the system does not perform the actions. Creating rules helps you track activities and more quickly respond to and resolve issues. Take advantage of the workflows' framework to automate your Day 2 operations. Quickly write a workflow that communicates with a Cloud API or a particular resource. Use SSH, PowerShell, or a similar tool, to access and then extend the workflow capabilities. For more information, see [Day 2 operations using workflows](https://servicenow-prod.fluidtopics.net/9qzA0hlHJsVd_618QDwNHg "Take advantage of the workflows framework to automate your Day 2 operations. Quickly write a workflow that communicates with a Cloud API or a particular resource. Use SSH, PowerShell, or a similar tool, to access and then extend the workflow capabilities."). * [Budget-based notification and approval](https://servicenow-prod.fluidtopics.net/zIx4YtdLTgOmdJY~7Zo66g#costbased-quota-managment "Administrators can assign a budget for a group and a user within the group. When the user or group reaches the budget limit threshold, notifications are sent alerting them about it.") Domain Separation in Cloud Provisioning and Governance supports data separation of budgets. You can assign domain-specific budgets. Assign a budget for a group and a user within the group. When the user or group reaches the budget limit threshold, notifications are sent alerting them about it. For more information, see [Configure budgets](https://servicenow-prod.fluidtopics.net/zIx4YtdLTgOmdJY~7Zo66g#configure-budgets "You can configure budgets for groups and users within that group. You can set up a budget period for the group, allocate a budget limit to a group and to each user within that group.") * [Create Tags for cloud resources](https://servicenow-prod.fluidtopics.net/BgEZNrEgft1auqIJThegFQ#cloud-tagging "Tags categorize cloud resources to provide richer and more detailed tracking and billing report data.") Tags categorize cloud resources to provide richer and more detailed tracking and billing report data. Tag keys are not domain separated and are shown to users of other domains. Tag visibility depends on the associated CI domain or associated billing record domain. Tags that are not associated to any CI or billing record are visible to all domain admins. When a tag is created, it shows up in any new catalog that you create. The cloud admin has to choose the tags they want for their catalog. * Billing data can be viewed separately for each domain. Billing jobs use the domain of service account configured. Configure the Billing setup to enable cloud admins and cloud users to view reports like cloud billing data and cloud tag usage on the billing dashboard.Define the scheduled job that regularly uses a MID Server to download billing data from the provider. Cloud Provisioning and Governance saves the data in a cost table and uses the information to generate reports. For more information on setting up billing schedules and downloading billing reports, see: * [Define the schedule for downloading AWS billing data](https://servicenow-prod.fluidtopics.net/ls7yJYktonKDRKHFEleyJA "Define the scheduled job that regularly uses a MID Server to download billing data from the provider. Cloud Provisioning and Governance saves the data in a cost table and uses the information to generate reports.") * [Define the schedule for downloading Azure billing data](https://servicenow-prod.fluidtopics.net/qa4OaokcTNNLvx0eTzHn0Q "Define the scheduled job that regularly uses a MID Server to download billing data from the provider. Cloud Provisioning and Governance saves the data in a cost table and uses the information to generate reports.") {#domain-admin-workflow__ul_nvz_2lb_ckb} {#domain-admin-workflow__ul_ggv_bvv_15b} {#domain-admin-workflow__ul_iw5_4b3_3kb} ## Next Steps {#domain-admin-workflow__section_e1c_tfk_fkb} Important: While creating custom operations invoking workflows on resource blocks, ensure that you change the context to the appropriate domain. To change the context to the right domain, edit the Workflow Activity to call the following script from within the workflow. Ensure that an appropriate user is obtained from the Service Account creator, or the order user. Invoking this impersonation script enables the workflow to be executed in the correct context and choose the right MID Server belonging to the associated domain. //var orderContext = json.decode(workflow.inputs.ordercontext) ; new CMPDomainSeparationUtil() .impersonateUser(current.request.requested_for); For more information on performing Cloud Provisioning and Governance life-cycle operations that are available for each domain that you are managing in your instance, see [Cloud User Portal](https://servicenow-prod.fluidtopics.net/G0E9zjrqG8ToM0WQcRh4cg "The Cloud User Portal gives you immediate access to all day-to-day cloud activities."). **Related concepts** * [Additional Cloud Provisioning and Governance setup on Day 2](https://servicenow-prod.fluidtopics.net/V7R_tlFGQTkRJ2Xos2Murg "After you have performed Day 1 setup, you can perform optional setup and configuration procedures as needed and in any order. Detailed instructions for each procedure follow this overview.") * [Discovery patterns used by ITOM Visibility](https://servicenow-prod.fluidtopics.net/_qxdmD6N5su6Ad7JOjMRVQ "Service Mapping and Discovery use patterns in their discovery process that cover most industry standard network devices and applications. You can customize these patterns and create new ones.")