---
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


---

# Populate the location based on the cloud account

# Populate the location based on the cloud account {#ariaid-title1}

* Release version: Yokohama
* 
* Updated January 30, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read

This example walks you through an existing set of blueprint rules that Cloud Provisioning and Governance provides by default.

## Before you begin

Before you can follow this example, you should be familiar with creating blueprints and blueprint rules. See these resources:

* [Cloud Provisioning Blueprints](https://servicenow-prod.fluidtopics.net/sa6wT_Zb5dIhb3bBAk43iA "A blueprint is a specialized catalog item template for offering cloud services, or stacks, to cloud users. Blueprints work with any cloud service provider, such as Amazon AWS Cloud or Microsoft Azure Cloud. Blueprints are in restricted usage from the Orlando release.")
* [Build a Cloud Provisioning blueprint](https://servicenow-prod.fluidtopics.net/EFg~MX6L_NVB5~4R31bKpg "Use the blueprint designer to create custom blueprints for the Cloud Provisioning and Governance application. Blueprints are deprecated in the Orlando release.")
* [Configure a blueprint rule](https://servicenow-prod.fluidtopics.net/mkV44JlrjQeHD3mu5wOJqQ#configure-a-blueprint-rule "Configure a rule that contains actions the system can take on blueprint attributes.")
{#analyze-default-blueprint-rules__ul_jb3_hc4_p2b}

Role required: sn_cmp.cloud_service_designer

## About this task

The goal of this example is to show you how a default set of blueprint rules
accomplishes the task of populating the Location field based on the Cloud Account.
Because this example walks you through default data, you do not need to create any
records if you are following these steps.

This blueprint, which includes a virtual server that can be provisioned in an AWS
datacenter, is used to illustrate the example:

## Procedure

1. Open a similar blueprint with a virtual server or similar.
2. On the blueprint form, click the Catalog tab, and then click the tile that represents the Provision operation.  
   ![Catalog item]()
3. Click the General Info variable set in the Variable Sets related list.
4. Click the CloudAccount variable to open the Cloud Variable form.  
   Notice these items:
   * In the Rules related list at the bottom, two rules are provided:
     * ReloadLocation reloads the value in the relocation field. This rule runs first because it has a lower order number than the other rule.
     * TriggerChangeEvent Location tells the system to trigger the actions for the rules that are already configured for the Location variable.
     {#analyze-default-blueprint-rules__ul_ndl_hbr_2gb}
   * The Lookup Select Box field specifies that the Cloud Account field provides a selection for the user to make. The options that the user can select comes from the CloudAccountPool, which is on the Type Specifications field.

   {#analyze-default-blueprint-rules__ul_ul2_qg4_p2b}
5. Click the Reload Location rule, and then click the Reload Location action from the Actions related list.  
   Notice these items:
   * The Action Type is
     Reload, which tells the system to
     reload the catalog item form so that a new value for the field
     specified in the Target Variable (the
     Location) can be populated.

   * The DataSource field tells the system to reload the location.
   * The KeyValues list, which is only used when you specify a Reload action type, specifies that the user is passing in the cloud account via the form. The cloud account is necessary to reload the correct value for the location because the location is loaded from a pool. That pool has a filter that requires the input of the cloud account to return the correct location options.
   {#analyze-default-blueprint-rules__ul_q5c_r1m_p2b}
6. Navigate back to the CloudAccount catalog property form and open the other rule: TriggerChangeEvent Location.
7. Click the Actions related list, open the TriggerChangeEvent Location action, and then click the TriggerChangeEvent Location action from the Actions related list.  
   Notice these items:
   * The Action Type is
     TriggerChangeEvent, which tells the
     system to trigger the actions for the rules that are already
     configured for the Location property. By default, several rules
     are already configured for the Location property. These include
     rules that reload other fields, like OS Profile, Network, and so
     on.

   * No KeyValues are required because this action is not a reload action.
   {#analyze-default-blueprint-rules__ul_ezr_h2m_p2b}  
   The result of these two rules on the CloudAccount attribute is illustrated in the following example:

8. Perform these steps to see why the system populated the value AWS Datacenter - us-east-1 in the Location field and how the system determines which location is related to the My Cloud Account value:
   1. In the same blueprint, open the General Info variable set, and then open the Location parameter.
   2. Click the Type Specifications tab.  
      Notice the values that can be populated for the
      Location field from the
      CloudLocationPool resource pool.
   3. Navigate to ManageResource Pools, open CloudLocationPool, and notice these items:  
      * The locations come from the records in the Lookup Table, which in this example is Associated Datacenter \[sn_cmp_ca_assc_datacenter\].
      * The actual value to display to users in the Location field on the catalog item form comes from the Lookup Field. In this example, the Lookup Field specifies the Alias column from the Associated Datacenter \[sn_cmp_ca_assc_datacenter\] table. The Alias column holds the actual, user-readable names for all locations.
      {#analyze-default-blueprint-rules__ul_uqg_gjr_2gb}
   4. Go to the standard interface of your instance, not the Admin Portal, and enter <kbd class="ph userinput">sn_cmp_ca_assc_datacenter.list</kbd> in the navigation filter.  
      The list of datacenters that are already associated with cloud
      accounts appears.

      Notice that the My Cloud Account cloud account
      is already associated with AWS Datacenter - us-east-1, which is the value that the user sees in
      the Location field. The system knew to display that value because of
      the association in this Associated Datacenter table. The system
      created this association when your Cloud Provisioning and Governance administrator created the
      cloud account for AWS, and then ran discovery on the us-east-1
      datacenter in that cloud account.

      It is possible that multiple datacenters could be associated with
      My Cloud Account. In that case, the
      Location field reloads all the associated datacenters and in the
      Location field. Since the Location field is of type Select, the
      field allows the user to select which location to choose.
   {#analyze-default-blueprint-rules__substeps_fzl_smy_q2b}

*[\>]: and then