Cloud Management Troubleshooting - Policies

Introduction - How policies work


In the Cloud User Portal UI, for example, when you are provisioning a cloud resource such as creating a VM, the following fields can be displayed:

In Cloud Management, policies will be executed if a set of conditions are met. If these conditions are met, rule actions defined in configured rules will be executed. The following rule actions are available:

  1. Property Override - This action will set the value of a given parameter of the operation, for example, if the user wants to override the Lease End Date parameter.
  2. Execute a script - Execute a ServiceNow script on the instance. All the operation parameters are available as inputs to the script, for example: Stack Name can be accessed through formData.StackName.
  3. Abort Process - This action will stop the workflow that drives the overall orchestration (Blueprint Request).

The "Blueprint Request" workflow governs resource provisioning and should not be edited. When an item is provisioned, Policies are processed at a given workflow activity based on the Policy Trigger the user configured.

To create a new policy,  navigate to Cloud Management > Policy.

In Kingston navigate to Cloud Admin Portal > Govern > Policies.

Notice the Policy Triggers available and their corresponding workflow activities for the following triggers:

  • Catalog item request start
  • Blueprint provision
  • Blueprint provision approval
  • Catalog item request end


After the policy is named and a trigger is defined, you can configure actions (property override, execute a script or abort the workflow).

The overall logical structure of a policy

A policy is executed on a trigger for a set of rules. These rules contain a set of conditions. If the conditions are met, actions are executed, for example, property override or execute script. A trigger can have 1 to n policies but the recommendation is to have only one trigger per policy because policies are executed one at a time. A policy can have 1 – n rules and each rule can have 0 to n conditions. Based on the true value of conditions, actions will be executed (1 – n actions). 

You can optionally configure a policy group if you want to group a set of policies based on a particular trigger.




The first step in troubleshooting policy issues is to go to Cloud Root Cause Analysis.



In Kingston, Root Cause Analysis Dashboard can be found by navigating to Cloud Admin Portal > Operate.

You can also go straight to the filter navigator and type sn_cmp_cloud_trail.list.

From Cloud Root Cause Analysis you can check the policy steps and get more information by drilling into Cloud Orchestration Trail. For more in-depth troubleshooting you can go to sn_cmp_cloud_trail.list and filter the Step.Name is Apply Policy.

If you open and inspect the record, you can look at the payload in the Message Details and by using a JSON parser you can troubleshoot it by analyzing the following: 


object -> rules -> index -> input -> formData 


or, for modified fields: object -> rules -> index -> modified -> formData 


If you are running script, you can modify attributes only in the formData .


The attributes available when you are writing a script are the ones under input, as follows:

  • catalogItemId
  • contextKey
  • ciInstanceId
  • requestItemId 

 entityId is: Catalog ID, Catalog Item ID, Group Item ID, Resource ID

You can use any online JSON viewing tool such as http://jsoneditoronline.org/ to easily see the relevant attributes.


Article Information

Last Updated:2017-11-28 19:21:43