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


---

# Remove a field from a cloud catalog form

# Remove a field from a cloud catalog form {#ariaid-title1}

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

Remove a field from the Cloud Provisioning and Governance catalog form when the user belongs to a specific group.

## Before you begin

Role required: sn_cmp.cloud_service_designer  
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.")
{#remove-mandatory-field-example__ul_jb3_hc4_p2b}

## About this task

The goal of this example is to hide the Cost Center field on the catalog form when the catalog requester belongs to the Database group. You can follow an example like this one when you want to show or hide catalog item fields
based on values in other fields.

## Procedure

1. Create a blueprint with a virtual server.  
   For this example, a blueprint with a virtual server on an AWS datacenter is used.

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 CostCenter variable to open the Cloud Variable form.
5. Configure the rule that removes the cost center based on the user group:
   1. In the Rules related list, click New.
   2. Fill out the Name and description Fields.
   3. Right-click the form header and select Save.
6. Configure the condition that requires the User Group to equal Database:
   1. In the Conditions related list, click New.
   2. On the form, fill in the fields.  
      {#remove-mandatory-field-example__table_ik4_nbs_t2b__entry__3}

      | Field | Value to enter or select | Description |
      |-|-|-|
      | Operand | UserGroup | This value is the User Group field that the user selects. |
      | Operator | --None-- | Keep this value --None-- because this condition is the only condition you need to configure. If you add more conditions, you can select another operator to determine how the system evaluates this condition in relation to the others. |
      | Value | 287ee6fea9fe198100ada7950d0b1b73 | This value is the Sys ID of the Database user group, which is provided as part of the demo data in your instance. See [Sys ID](https://www.servicenow.com/docs/access?context=c_UniqueRecordIdentifier&version=yokohama&pubname=yokohama-platform-administration&ft:locale=en-US) for more information. |
      [ ]

      {#remove-mandatory-field-example__table_ik4_nbs_t2b}
   3. Click Submit.
7. To understand why the Sys ID of the user group is required for the system, perform these steps:
   1. Open the blueprint again and click the Provision operation again.
   2. Click the General Info from the Variable Sets related list.
   3. Click the UserGroup variable.  
      Notice that on the Type Specifications tab, the system populates user groups from UserGroupPool. The system runs the scripted pool filter named
      GroupsUserBelongsTo.

   4. In the Cloud Admin Portal, navigate to ManageResource Pools.
   5. Find and open UserGroupPool.  
      Notice that the values for the pool are derived from the table in the Lookup Table field, which in this case is the Group \[sys_user_group\] table.  
      Also notice that there are two queries in the Resource Pool Filters related list:
      * All is a generic query that returns the list of all records from the Lookup Table. The value it returns from that table is from the Lookup Field, which in this case is the Sys ID. However, the system ignores the All query in this case because the scripted query is present.
      * GroupsUserBelongsTo is a scripted query that returns the Sys ID of records in the Lookup Table.
      {#remove-mandatory-field-example__ul_zqs_hqy_q2b}  
      Important:  
      When a scripted query is present, the system uses it instead of the generic ALL query.

      Both the generic query and the scripted query return the Sys ID of the record in the lookup table. But what is actually happening here is that the system ignores the All query and the value
      specified in the Lookup Field, and it uses the GroupsUserBelongsTo script.  
      Figure 1. A scripted query
   {#remove-mandatory-field-example__substeps_vz2_kpy_q2b}

*[\>]: and then