Policies for Cloud Provisioning

  • Release version: Zurich
  • Updated July 31, 2025
  • 5 minutes to read
    • Summarize
    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 Policies for Cloud Provisioning

    Cloud policies in ServiceNow provide system-wide control over cloud provisioning activities by automating approvals, resource operations, blueprint operations, and catalog item settings. Policies are triggered by specific events such as blueprint provisioning, resource operations, or lease expiration, and can override user inputs, create approval tasks, reserve IP addresses, manipulate form fields, execute scripts, call Cloud APIs, or manage subflows.

    Show full answer Show less

    How Policies Work

    Each policy is associated with a trigger event that activates the policy engine. The engine evaluates policy rules, which consist of conditions and actions. Actions execute only if all conditions are true. Policies can be targeted to specific blueprints, catalog items, or apply broadly to any matching operation. When multiple policies apply, execution order is controlled by defined settings, with special rules for approval policies to ensure only the first successful approval applies.

    Key Components

    • Triggers: Events such as blueprint provisioning, resource operations (start, stop, provision, deprovision), or lease end that initiate policies.
    • Policy Rules: Sets of conditions (e.g., CPU size, operation type, lease timing) and actions (e.g., override values, create approval tasks, send notifications) that define policy behavior.
    • Approvals: Cloud approval policies specify approvers (managers, groups, roles) and enforce approval workflows before proceeding with cloud activities.
    • Policy Groups: Containers for related policies that facilitate consistent application and management of multiple policies across the organization.
    • Policy Action Scripts: Custom scripts to dynamically get, update, or set values in cloud requests, including tagging resources for billing and reporting.

    Practical Use and Benefits for ServiceNow Customers

    • Automate and enforce governance for cloud provisioning and resource management through customizable policies.
    • Control user input by overriding property values and dynamically adjusting request forms to simplify user experience and reduce errors.
    • Ensure compliance and accountability with structured approval processes involving designated approvers.
    • Use policy groups to organize and consistently apply related policies across cloud environments.
    • Integrate custom logic and automate complex workflows using policy action scripts and Cloud API calls.
    • Export and import policies as update sets for backup, migration, or restoration, preserving all associated rules and scripts.

    Important Considerations

    • Flows cannot be invoked while adding a resource operation step due to a known limitation.
    • When multiple approval policies apply, only the first successful approval policy and its first successful rule and action are executed.
    • Order of execution for non-approval policies depends on the configured Order of Execution property; identical order values have no guaranteed execution sequence.

    A cloud policy can override a property value set by a user, create an approval task, reserve an IP address, pre-populate or hide form fields, execute custom scripts, call the Cloud API, or start or abort subflows. A cloud policy gives you system-wide control over approvals, resource operations, blueprint operations, or catalog item settings.

    A user requests a stack that triggers an approval policy

    1. On the Cloud User Portal, a user submits a request to provision a particular blueprint. The process of provisioning the blueprint is the trigger that causes the policy engine to apply an approval policy. A cloud approval policy specifies the users who must approve a specified cloud activity before the activity can proceed.
    2. The policy engine determines that the request meets the condition specified in the rule for the policy. In this example, the condition evaluates to true whenever a particular blueprint is being provisioned.
    3. Because the condition is met, the policy engine performs the action that is also specified in the rule. In this example, the action is to create an approval action for the manager.
    4. While the approver (the manager) reviews the approval request, the user sees a "waiting for approval" status message on the Cloud User Portal.
    5. After the manager approves, the blueprint is provisioned.
    Figure 1. User waiting for approval
    User waiting for approval
    Note:
    You cannot invoke flows while adding a resource operation step. This is a known limitation.

    About policy triggers

    Triggers are events that set the policy engine in motion. For example, the on Catalog item request end trigger fires after a user submits a request form. When you think about defining a policy, you might first consider how the policy will be triggered. Examples:
    • A user requests a Stop operation on a virtual server (the on Stack resource operation trigger fires)
    • A resource reaches the end of its lease (the on Lease End trigger fires)
    • A user requests a particular stack (the on Blueprint provision trigger fires)

    You typically refer to a policy by the name of the trigger for the policy. For example, you might refer to a policy that is triggered by the on Lease end trigger as a "Lease end policy." For more detail on the types of trigger that you can implement, see Triggers for cloud policies.

    How policies work

    For each policy, you typically configure a trigger that starts the policy engine. The policy engine enforces the policy by running all rules that are defined for the policy. A policy rule is a collection of conditions and actions. ​If all conditions evaluate to true, the policy engine performs the actions. If any condition evaluates to false, the policy engine does not perform the actions.
    • Some policy types apply only to particular types of cloud operation, like start, stop, provision, or deprovision, or to a particular target, like ‘on blueprint123 provision operation’ or ‘on catalog item ABC launch’​.
    • You can configure a policy that does not specify a target, for example, ‘on any blueprint provision operation’ or ‘on any catalog item launch’​. Errors on policies that apply to any object are ignored.
    • If multiple policies apply, you can specify the order that the policies are applied (with an exception that is described in a following section).
    • Policies can work with dynamic forms to allow you to show or hide form fields from end users. Users see only information that you decide they need for them to understand and complete their tasks.

    Policy groups

    A cloud policy group is a container for related policies. Consider grouping policies that are often used together or should be considered together. Grouping policies can help you to apply policies consistently across your organization.

    Order of execution when multiple policies apply

    Order of execution when multiple "approval" policies apply:

    When multiple "approval" policies apply, the policies are applied in the following order. (The approval policies are on Blueprint provision (approval), on Stack operation (approval), on Stack resource operation (approval), and on Task remediation ):

    1. Only the first successful approval policy is applied and no other approval policies are applied.
    2. If the applied approval policy has multiple rules, only the first successful rule is used.
    3. If a rule has multiple actions, only the first successful action is performed.
    4. If the applied approval policy includes both a custom approval and a Service Now approval, only the custom approval process is performed.

    Order of execution for all other policy types:

    • Policies are applied in the order that is specified by the Order of Execution property setting.
    • If multiple policies have the same Order of Execution setting, then order is not guaranteed.

    About operations in policies

    Triggers are often based on user requests and the operations (start, stop, provision, or de-provision) that can run on a blueprint, a catalog item, a resource, or a stack. Some trigger types do not specify a cloud operation. For example, the on Lease End trigger fires independently of any operation.

    About policy rules

    A policy rule is a collection of conditions and actions. ​If all conditions evaluate to true, the policy engine performs the actions. If any condition evaluates to false, the policy engine does not perform the actions.

    • Conditions: Conditions can consider request form data, resource activity, or user activity. Examples:
      • Is the size of the requested CPU greater than 32?
      • Is this a Stop operation?
      • Is the lease for this resource ending in the next 7 days?
    • Actions: If all conditions evaluate to true, the policy engine runs the actions that the rule specifies. Expressions in policy actions can set or override values. Examples:
      • Override the value that the user specified by changing the CPU size to 16 and then start the approval process. (because the condition was met that the requested CPU is greater than 32).
      • Create an approval task for the manager. (because the condition was met that a Stop operation was requested).
      • Send notifications to every user in the ABC group. (because the condition was met that the lease ends in 7 days).

    Policy action scripts

    • Use policy action scripts to get, update, or set values in cloud requests.
    • Your instance tracks tagged resources for billing and reporting. Policy action scripts can add and modify resource tags.