How are Automation Service Broker policies processed

Policies are processed based on the policy definition. In particular, the scope and the enforcement level determine which policy is valid when you have multiple policies that might apply to a single deployment.

This article provides general information about policy processing, but it also includes more details for the different types of policies.

How policies are ranked based on organization level and enforcement type

When a user, who is a member of a project, creates a deployment, there might be more than one policy that applies to that deployment.


	To evaluate the policies, the system first identifies and ranks policies. Are there any hard policies at either the organization and project level. If there are hard and soft policies, then only the hard policies are considered and ranked. If there are only soft policies, then the soft policies are ranked. The ranking of all hard or all soft policies is ordered by scope, with organizational policies having a higher rank than project policies. The final discriminating characteristic is the creation date, with older dates be ranked higher than newer dates.

Ranking order diagram for policy processing

To evaluate the policies, the system first identifies and ranks policies.

Are there any hard policies at either the organization and project level. If there are hard and soft policies, then only the hard policies are considered and ranked. If there are only soft policies, then the soft policies are ranked.
The ranking of all hard or all soft policies is ordered by scope, with organizational policies having a higher rank than project policies.
The final discriminating characteristic is the creation date, with older dates be ranked higher than newer dates.

How policies are processed based on organization level and enforcement type

The policies are evaluated, ranked, and, where applicable, merged to produce an effective policy. An effective policy produces the intended results but is not always a specific named policy.

This section includes the following examples:

Lease policies
Day 2 actions policies

Review the following lease policy examples.


	After identifying the policies to be considered and ranking them, the policies are then evaluated to identify the merge order. The highest ranking policy becomes the baseline. The second-level policy is applied on top of it, and so on. If a policy is incompatible with the preceding policies, then it is discarded from consideration. For example, the values are higher they the preceding policies. Any policy that is discarded is ignored. To see which policy is applied, select Content and Policies > Policies > Enforcement, locate the deployment, and review the decision notes.
	Rather than applying one policy and excluding all the others above, the policies are merged and might include values from more than one individual policy. In this example, the merging process excludes Policy 2 from consideration because the values are higher than Policy 1. Next, Policy 3 is evaluated against Policy 1. The Lease and Total Lease values in Policy 3 are lower than Policy 1, so those values, in addition to the Grace period, become part of the effective policy.

Example of how lease policies are ranked.

After identifying the policies to be considered and ranking them, the policies are then evaluated to identify the merge order.

The highest ranking policy becomes the baseline. The second-level policy is applied on top of it, and so on.
If a policy is incompatible with the preceding policies, then it is discarded from consideration. For example, the values are higher they the preceding policies.
Any policy that is discarded is ignored. To see which policy is applied, select Content and Policies > Policies > Enforcement, locate the deployment, and review the decision notes.

Example of how ranked policies are processed and merged.

Rather than applying one policy and excluding all the others above, the policies are merged and might include values from more than one individual policy.

In this example, the merging process excludes Policy 2 from consideration because the values are higher than Policy 1.

Next, Policy 3 is evaluated against Policy 1. The Lease and Total Lease values in Policy 3 are lower than Policy 1, so those values, in addition to the Grace period, become part of the effective policy.

Review the following day 2 actions policy examples.


	After identifying the policies to be considered and ranking them, the policies are then evaluated to identify the merge order. The highest ranking policy becomes the baseline. The second-level policy is applied on top of it, and so on. If a policy is enforced by preceding policies, for example, policy 3, then it is discarded from consideration. Any policy that is discarded is ignored. To see which policy is applied, select Content and Policies > Policies > Enforcement, locate the deployment, and review the decision notes.

Example of how day 2 actions policies are ranked.

After identifying the policies to be considered and ranking them, the policies are then evaluated to identify the merge order.

The highest ranking policy becomes the baseline. The second-level policy is applied on top of it, and so on.
If a policy is enforced by preceding policies, for example, policy 3, then it is discarded from consideration.
Any policy that is discarded is ignored. To see which policy is applied, select Content and Policies > Policies > Enforcement, locate the deployment, and review the decision notes.

Lease policy management goal considerations

Now that you know how lease policies are processed, identify your policy management goals. By understanding how the policies are processed, you can meet your management goals without creating an excessive and unmanageable number of policies.

When deciding how to implement your policies, consider the following scenarios.

Lease policy goals and enforcement examples
Day 2 policy goals and enforcement examples

Table 1. Lease policy goals and enforcement examples
Management goal	Configuration Example	Behavior
Meaningful default organization-level policy that still allows the project-level policy values to influence the applied values.	Organization policy = Soft Grace period: 10 Lease: 100 Total Lease: 100 Project 1 policy 1= Soft Lease: 20 Total Lease: 50 Project 2 policy 1= Soft Lease: 10 Total Lease: 30	A member of project 1 requests a catalog item. Project 2 is not considered because it is not applicable to project 1 deployments. The merged effective policy is: Grace period: 10 Lease: 20 Total Lease: 50
Always default to the organization-level policy.	Organization policy = Hard Grace period: 10 Lease: 100 Total Lease: 100 Project 1 policy 1= Soft Lease: 20 Total Lease: 50	A member of project 1 requests a catalog item. Project 1 policy 1 is not considered because the hard organization level project is a higher rank and the soft policy is not considered. The effective policy is: Grace period: 10 Lease: 100 Total Lease: 100
All policies are defined at the project-level, with no organization-level default policy.	Project 1 policy 1 = Soft Grace period: 10 Lease: 100 Total Lease: 100 Project 1 policy 2= Soft Lease: 20	A member of project 1 requests a catalog item. They are both soft policies, and they are both for project 1. The values are merged. The effective policy is: Grace period: 10 Lease: 20 Total Lease: 100

The day 2 actions policies are used in these examples.

Table 2. Day 2 policy goals and enforcement examples
Management goal	Configuration Example	Behavior
Meaningful default organization-level policy that still allows the project-level policy values to influence the applied values.	Organization policy = Soft Actions : Deployment.* Project 1 policy 1= Soft Actions: Cloud.vSphere.Machine.* Project 2 policy 1= Soft Actions: Cloud.Azure.Machine.*	A member of project 1 requests a catalog item. Project 2 is not considered because it is not applicable to project 1 deployments. The merged effective policy is: Action : {Deployment.* ,Cloud.vSphere.Machine.*}
Always default to the organization-level policy.	Organization policy = Hard Action : Deployment.* Project 1 policy 1= Soft Action : Cloud.vSphere.Machine.*	A member of project 1 requests a catalog item. Project 1 policy 1 is not considered because the hard organization level project is a higher rank and the soft policy is not considered. The effective policy is: Action : {Deployment.* }
All policies are defined at the project-level, with no organization-level default policy.	Project 1 policy 1 = Soft Actions : Deployment.ChangeLease Project 1 policy 2= Soft Action : Deployment.Delete	A member of project 1 requests a catalog item. They are both soft policies, and they are both for project 1. The values are merged. The effective policy is: Action : {Deployment.ChangeLease , Deployment.Delete}

Approval policy goals and enforcement examples

The approval policy evaluation follows this process.

A request for a deployment or day 2 action is submitted.
The approval service queries for policies that apply to the project that is requesting a catalog item or changing a deployed item.
All the applicable project- and organization-level scope policies are returned.
The approval policies are filtered based on the deployment criteria. Deployment criteria apply to deployments and day 2 actions.
If no matching policies are found, no approval is required and the deployment process proceeds.
If there are matching policies, for example, AP1, AP2, APn, then an approval item is created as:
- Enforced policies = AP1, AP2, APn.
- Approvers = A union of all the approvers in all the enforced policies.
- Auto expiry = Reject, if any policy has a reject value; otherwise, approve.
- Expiry = Minimum number of days of any of the enforced policies.

The following table provides a sample of multiple policies. The description of how they are processed is below the table.

Policy	Configuration example
AP1	Scope = Organization Auto expiry = Approve Expiry = 7 days
AP2	Scope = Project 1 Auto expiry - Approve Expiry = 3 days
AP3	Scope = Project 1 Auto expiry = Reject Expiry = 4 days
AP4	Scope = Project 2 Auto expiry = Approve Expiry = 5 days

Based on the policies and configuration examples above, the following information explains how a Project 1 request is processed.

The scope evaluation returns AP1, AP2, and AP3. AP4 is not included because it is a Project 2 policy.
Assuming that AP1, AP2, and AP3 satisfy the deployment and action criteria, then the approval item includes the following values:
- Approvers = Any or all the approvers from AP1, AP2, and AP3 are added as approvers.
- Auto expiry = Reject. AP3 provides the more restrictive behavior.
- Expiry = 3 days. AP2 provides the lowest value.