--- sourceDocument: Australia IT Operations Management sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/de-DE/it-operations-management Release : - australia ft:locale : - de-DE ft:publication_title : - Australia IT Operations Management ft:clusterId : - itom bundleId : - itom workflow : - Technology --- # Domain admin considerations # Domain admin considerations {#ariaid-title1} * Freigeben Version: Australia * * Aktualisiert 12. März 2026 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 8 Minuten Lesedauer 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. Hinweis: * 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=australia&pubname=australia-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/0tcs3VdRbPA_x9v5yWtNJQ "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/1QRLQQ7u25LgHskyXoZtmw "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/tPx7o0TYtEpHFnh42_n12A "To set up Google Cloud for the first time, follow the steps in this Day 1 setup guide in the order they are presented. After completing the Day 1 setup, you can proceed with the optional Day 2 configuration steps as needed, in any order. Detailed instructions for each step are provided in the sections below.") * [Day 1 setup guide for VMware on Cloud Provisioning and Governance](https://servicenow-prod.fluidtopics.net/8tqJRNeTIdueWyO7DAeilQ "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/eBtr5QkzlEgnqNI930y~0A "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/6~mzAmwH9Huc50~eueWuHg "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/HBxVGhEpzcycieYR7ma2ZA "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/3IDBT71oapHdBE_T6JFg8A#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/Gil9ygLpus_0ztYG9zQ1_g "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/qCxiqgtnUDtimecqQ_sYyA "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/iKzZfalyXcwjX2lR9ae~KA "Applications that access VMware cloud resources need access to VMware credentials.") * [Google Cloud Platform Discovery](https://servicenow-prod.fluidtopics.net/FITuaC6G2P53Nchszgj9dg "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/Nn~EaNzDmEHgxf7afulNCA "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/bc~ZYr18gQba82s0bbnumQ "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/2mvF7acxWTIJV8hjO~xx7A "After activating Event Management, set it up to receive and process events, and generate and analyze alerts.") * [AWS events-driven discovery](https://servicenow-prod.fluidtopics.net/wLyaKKWolkmvMCS7STyfmg "The Amazon Web Services (AWS) Config service can raise events for any changes in the life-cycle state or the configuration of a cloud resource. The ServiceNow event-driven discovery uses the events to auto-update the latest resource information in the Configuration Management Database (CMDB).") * [Configure the Microsoft Azure Alert service to auto-update the CMDB](https://servicenow-prod.fluidtopics.net/2OhGW0Z7s_4kprfM8_urlg#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/n1rOTsbpCJ8SnFN66q~FMw "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/iH3mBGFRwdW1ZG8kZ4SpDg "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/7EEX5Kvdy_UFL_GdxVrYjw "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/pP3dIF~S6r2E7IX0PemXEw "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. Warnung: 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/j9gSMyzqgHntpe4NnH4RNg "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."). Hinweis: Add only "Terraform" as the config provider. * [Create a catalog item based on a Terraform template](https://servicenow-prod.fluidtopics.net/NXe28JbQgL~MTdSTJxdtGg "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 with subflows. 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 flow designer subflow to automate your Day 2 operations. Quickly write a subflow that communicates with a Cloud API or a particular resource. Use SSH, PowerShell, or a similar tool, to access and then extend the subflow capabilities. For more information, see [Day 2 operations using subflows](https://servicenow-prod.fluidtopics.net/IjQ4tmFj4Dn6a~yg7gEncg "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/FT9U_ae7LB1T_Ynm5fEuwg#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/FT9U_ae7LB1T_Ynm5fEuwg#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/nRWv6loV2zY6wYKVj4Q4ig#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/vlYKaOUg9KtlKgAnaW7aBQ "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/Inhym19lvFOrUBz23ymNxg "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} Wichtig: 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/4eTFUF7zvee5Gq9J5oTvoQ "The Cloud User Portal gives you immediate access to all day-to-day cloud activities."). **Zugehörige Konzepte** * [Additional Cloud Provisioning and Governance setup on Day 2](https://servicenow-prod.fluidtopics.net/QFI0mq~zUgmtEASz3MMCyg "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/OjfwnF9YTM~M_1VajzsgCw "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.")