Azure tag governance in workflow studio

Go to solution
john_wenzel
Mega Contributor

3 weeks ago

Sorry I am somewhat new to this platform so if it seems like I do not know what I am talking about, its because I do not know what I am talking about. 

 

I have a tag policy set up for azure. I want to create a ticket for a dynamic team based on the user tags on the resource.  The flow input includes the configuration item and with this I have managed to pull all of the tags for that resource.  

 

However in the ticket I want to include the link to azure within the ticket. 

 

cmdb_ci_resource_group provides the information I need in field object_id

cmdb_ci_vm_instance provides the information I need in field vm_object_id

cmdb_ci_cloud_storage_account provides the information I need in field csa_object_id

 

I have 100's of different types of resources that I want the flow to work with. 

 

The configuration item in the flow doesn't appear to constrain any of these value in the data picker. 

 

Can anyone provide recommendations on the best way to manage pulling these values within a flow?

 

Thanks in advance. 

0 Helpfuls
  • 368 Views
1 ACCEPTED SOLUTION

Go to solution
pavani_paluri
Kilo Sage

2 weeks ago

Hi @john_wenzel ,

 

 
You’ve got lots of different Azure resource types in your CMDB, and each one stores its Azure object ID in a different field (object_id, vm_object_id, csa_object_id, etc.). When you build a Flow in ServiceNow, the “configuration item” input doesn’t automatically know which field to use, so you can’t just pick one value in the data picker and expect it to work across all classes.
 
How to handle it
Option 1: Script step in your Flow  
  Add a small script action that looks at the CI’s class (sys_class_name) and then pulls the right field. For example:  
If it’s a resource group → use object_id  
If it’s a VM → use vm_object_id  
If it’s a storage account → use csa_object_id  
  Then build the Azure portal link with that ID.
 
Option 2: Common field across classes 
  Add a new field (say, azure_object_id) to each CI class. Populate it with the correct value from the class‑specific field using a business rule or transform. Then your Flow only has to look at azure_object_id no matter what type of resource it is.
 
If you only need to support a handful of resource types, a simple script with a switch/case is fine. But since you mentioned you have hundreds of resource types, the cleaner long‑term approach is to standardize on a common field like azure_object_id. That way your Flow logic stays simple and doesn’t need to branch for every class.
 
Mark it helpful if this helps you to understand. Accept solution if this give you the answer you're looking for
Kind Regards,
Pavani P

 

View solution in original post

1 REPLY 1

Go to solution
pavani_paluri
Kilo Sage

2 weeks ago

Hi @john_wenzel ,

 

 
You’ve got lots of different Azure resource types in your CMDB, and each one stores its Azure object ID in a different field (object_id, vm_object_id, csa_object_id, etc.). When you build a Flow in ServiceNow, the “configuration item” input doesn’t automatically know which field to use, so you can’t just pick one value in the data picker and expect it to work across all classes.
 
How to handle it
Option 1: Script step in your Flow  
  Add a small script action that looks at the CI’s class (sys_class_name) and then pulls the right field. For example:  
If it’s a resource group → use object_id  
If it’s a VM → use vm_object_id  
If it’s a storage account → use csa_object_id  
  Then build the Azure portal link with that ID.
 
Option 2: Common field across classes 
  Add a new field (say, azure_object_id) to each CI class. Populate it with the correct value from the class‑specific field using a business rule or transform. Then your Flow only has to look at azure_object_id no matter what type of resource it is.
 
If you only need to support a handful of resource types, a simple script with a switch/case is fine. But since you mentioned you have hundreds of resource types, the cleaner long‑term approach is to standardize on a common field like azure_object_id. That way your Flow logic stays simple and doesn’t need to branch for every class.
 
Mark it helpful if this helps you to understand. Accept solution if this give you the answer you're looking for
Kind Regards,
Pavani P