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

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Resource blocks in Cloud Provisioning and Governance

# Resource blocks in Cloud Provisioning and Governance {#ariaid-title1}

* Release version: Australia
* 
* Updated March 12, 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 6 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 Resource blocks in Cloud Provisioning and Governance

Resource blocks serve as middleware components that connect catalog items, the Cloud API (CAPI), and the Configuration Management Database (CMDB).
They facilitate the provisioning process by defining operations and handling responses from cloud providers, enabling seamless integration with the CMDB.
Show full answer Show less  

## Key Features

* **Blueprint Integration:** Resource blocks act as building blocks within blueprints, which are the basis for catalog items (stacks) in the Cloud Catalog.
* **Operations:** Each resource block defines operations like Provision and Deprovision, which interact with CAPI to execute tasks on the cloud.
* **Interfaces:** Resource blocks include guest and host interfaces that facilitate connections to adjacent resources, allowing for vertical (containment) and horizontal (attached-to) connections.
* **Input Parameters:** These hold essential values for operations, such as datacenter location, and are used by CAPI during execution.
* **Response Processors:** Scripts that manage responses from cloud providers, ensuring that the CMDB is updated accordingly.

## Key Outcomes

By utilizing resource blocks, ServiceNow customers can effectively manage cloud resources, automate provisioning tasks, and maintain updated records in the CMDB. Customers can create custom resource blocks, configure operations, and integrate Terraform for enhanced orchestration, thus optimizing their cloud management processes.  
Resource blocks act as a type of middleware component between catalog items, the Cloud
API (CAPI), and the CMDB.
The following graphic illustrates how resource blocks fit between other components in the
system:

Blueprints
:   Each resource block becomes a building block within a blueprint. The blueprint eventually
    becomes a catalog item (also called a stack) that a user provisions from the Cloud
    Catalog.

Cloud API (CAPI)
:   Each resource block defines allowable operations, such as Provision and Deprovision. These
    operations call various components within CAPI to carry out the operation that is received
    from the stack.

The CMDB
:   Each resource block is based on a CI type from the CMDB. Resource blocks also have a
    response processor that handles responses from the cloud provider to take some type of action
    in the CMDB, such as creating or updating a CI.

## How resource blocks are connected {#resource-blocks__section_pm2_dmt_w2b}

Resource blocks are connected to each other in blueprints. For example, in this blueprint, a
virtual server resource block is connected to storage. The virtual server and the storage are
both connected to an AWS datacenter resource block.  
Figure 1. Blueprint server with storage

For these connections to be successful, each resource block needs to specify a type of
interface. This graphic illustrates these interfaces:  
Figure 2. Types of interfaces for resource blocks  
* The guest interface connects to the resource that is above it. The guest interface contains the operations (also called operation signatures), which allows users to take action on their resource.
* The host interface connects to the resource below the resource block in the blueprint. The host interface also contains operation signatures.
* The bindings connect adjacent resources.
{#resource-blocks__ul_csn_x4t_w2b}  
Resource blocks can have as many guest interfaces, host interfaces, and bindings as necessary. Connections can be made in different directions:

* Vertical connections require the top resource block to have the same host interface as the bottom resource block guest interface.  
  Note:  
  In blueprints, this vertical connection is called a containment connection.
* Horizontal connections bind one resource to another, but both resources have to reside on top of the same resource block.  
  Note:  
  In blueprints, this horizontal connection is called an attached-to connection.
{#resource-blocks__ul_wpz_1rt_w2b}  
The same example blueprint with a virtual server with attached storage on an AWS datacenter, the resource blocks are configured as this graphic illustrates: Figure 3. Interfaces for resource blocks  
{#resource-blocks__table_ils_l45_w2b__entry__2}

| Resource block | Interfaces and bindings |
|-|-|
| Virtual server | * Host interface: Compute * Binding: to Storage Volume {#resource-blocks__ul_htw_rp5_w2b} |
| AWS Datacenter | * Guest interface: Compute * Guest interface: Storage Server interface {#resource-blocks__ul_ajl_5p5_w2b} |
| Storage | Host interface: Storage Server interface The binding between the virtual server and the storage is unidirectional. You configure the binding on the virtual storage resource block only by specifying the storage resource block. You do not need to configure another binding on the storage resource block. |
[ ]

{#resource-blocks__table_ils_l45_w2b}

## Guest interfaces and operations {#resource-blocks__section_ut2_zpj_mz}

Each guest interface provides a default set of operations (also called operation signatures)
that allow the user to choose what they want to do with a virtual resource. The most common
operation is Provision, which means that a virtual resource is created. Many guest interfaces
and corresponding operations are provided by default with the Cloud Provisioning and Governance application. You can use these default guest interfaces for
many of your resource blocks.  
If you do need to create a new guest interface, these operations are provided by default:

* Start
* Stop
* Provision
* Deprovision
* Cleanup
* ModifySchedule
* ModifyLease
{#resource-blocks__ul_a1w_v2v_w2b}

## Resource block component details {#resource-blocks__section_ntm_z4z_w2b}

Each resource block contains these components:

Layers

:   The logical layer in the stack that this resource block belongs to. By default, Cloud Provisioning and Governance provides the layers. When you configure resource blocks,
    you can choose the one that relates to you.

Operations for each guest interface

:   As mentioned, each guest interface provides operations. For example, the most common
    operations for a virtual server are Provision,
    Deprovision, Start,
    Stop.

Input parameters for each operation

:   The input parameters hold values that the cloud provider uses, via CAPI, when operations
    are run. These parameters hold the information that the user selects while performing an
    operation, such as provisioning, on a stack.

    For example, a user typically must specify the location, which is a datacenter, that a
    stack belongs in. The value that the user selects in the Location
    field is held in the Location parameter. The system takes this parameter, which is available
    by default for the virtual server resource block, and passes it to the
    CreateNode CAPI interface operation. The CreateNode
    interface operation tells the cloud provider to create (or provision) the actual virtual
    server.

Steps for each operation

:   Each operation requires a step to do the actual work. Each step calls a specific interface
    and method in CAPI, and passes along the input parameters required by that method. For
    example, the Provision operation on a virtual server provides one
    step to first connect and create a virtual machine, and another step to create the node in
    the cloud provider. Each step provides different input parameters. To connect and create a
    virtual machine, the cloud account, among many other parameters, is required. To create the
    node, the cloud account is not required.

    You can add as many steps as needed for each operation. You can also use output attributes to pass values in attributes from one step to another step, or from steps
    in one operation to steps in a subsequent operation. For example, the
    Provision operation for a virtual server can provide an output
    attribute for the network interface ID and another for the node ID. When the cloud provider
    sends the response, the actual ID of the network and node are parsed out of the response and
    saved in the output attributes. Subsequent steps can then use the IDs to perform actions.

Response processors

:   Response processors tell the system what to do in the CMDB. When the cloud provider sends
    a response after an operation is run, the processor handles the response.

    Note:  
These processors are scripts that are system includes. They are not MID Server script includes like the CAPI scripts that you can create to integrate with the cloud provider.  
Figure 4. How components work together  
Users can see catalog items, also called stacks, in the Cloud Catalog. A catalog item is based on a blueprint, which in turn is composed of resource blocks that are connected together.

1. The user kicks off the process by requesting a stack. The request is the Provision operation in the system.
2. The system runs the steps in order for the Provision operation for the resource blocks that comprise the stack.
3. Each step calls CAPI to determine which method to run, while also passing in values for necessary parameters.
4. CAPI interfaces with the API of the cloud provider to provision the actual resource.
{#resource-blocks__ol_gm1_ft1_x2b}  
Figure 5. Process flow when a resource is created in the cloud provider  
1. The cloud provider provisions the resource and responds with JSON.
2. The system parses the response inside the resource script in the resource block.
3. The system updates the CMDB. When provisioning a new resource, the system creates a CI in the correct table.
4. The new stack appears in the cloud user portal for the user to manage.
{#resource-blocks__ol_eyh_sjb_x2b}

## The Resource Blocks page

Manage resource blocks in the Resource Blocks page. Open the Cloud Admin portal, and then
navigate to DesignResource Blocks.  
Figure 6. Resource Blocks page components
* **[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.
* **[Configure resource block input parameters](https://www.servicenow.com/docs/xypepZBZ2bD_LYTPf6BbsA)**   
  You can configure operations for each interface of a resource block by specifying input parameters, steps, and output attributes. Input parameters hold values that the system requires to identify and manage a virtual resource, such as the datacenter and resource group that the resource is in.
* **[Add operation steps to a resource block](https://www.servicenow.com/docs/OUxDqc9uOQJuG8AhhK8KHQ)**   
  After you configure operations and input parameters for your resource block, add steps for each operation to tell the system which Cloud API (CAPI) to call. Each step is a separate call to CAPI.
* **[Extend Cloud Provisioning and Governance resource blocks with an override operation](https://www.servicenow.com/docs/pdl3pIfp7K6AK9oM3eKVlg)**   
  You can extend your existing guest interface to create a new operation. You can also create a new guest interface with its own operations, parameters, and inputs.
* **[Add a resource script to a resource block](https://www.servicenow.com/docs/_8PTkzBdes6daJJamttSCw)**   
  A resource script operates on a resource during deployment or returns data to the CMDB after a resource is deployed.
* **[Configure a response processor](https://www.servicenow.com/docs/CYPkWLrI4zVow5fRs2DJLA)**   
  Configure a response processor to handle responses from datacenters.
* **[Add Terraform Orchestration interface on a resource block](https://www.servicenow.com/docs/fMV7F~J5TLHAenUISK2yVg)**   
  After you have activated the Terraform store app for Cloud Provisioning and Governance, to support cloud-based operations for cloud providers using Terraform Open Source Edition. Add the Terraform Orchestration interface on resource block, to execute cloud-based operations via terraform templates.
* **[Create a resource block for Microsoft Azure Cloud](https://www.servicenow.com/docs/ARYEU~2T8BTPfTa5EqVArw)**   
  Resource blocks are the building blocks of cloud catalog items. Create a resource block for the Microsoft Azure Cloud Platform provider, based on a CI type from the CMDB.

*[\>]: and then