Types of Policies


Policies provide consistent controls over what people can do.  They limit the options down to the only acceptable ones.

Policies are hierarchical, broker will work out the effective policy.

Levels & Types 




Hours of Operation







When's best?

It's best to apply a policy when:

  1. You want the policy to apply ALL the time
  2. There are no exceptions 

A policy won't work well when:

  1. You want the policy to apply MOST of the time 
  2. There are known exceptions
  3. You need to make case by case decisions

If you find you need  to change a policy often then it's time to rethink the level the policy is at.


Policies are hierarchical, a lower level policy cannot override a higher level policy. In the example below you can how the lower level policies are reducing the regions available at each level.

Expect to have the least policies at the Global level with more at the environment level and most at the Catalog level where you are specifying what is needed for a particular solution being deployed in a particular environment.

Effective Policy 

Broker works out the effective policy on a Catalog item by implementing the Global policy followed by the Environment policy with the Catalog item policy being implemented last.

It is possible to create an effective policy that results in no valid options.


Add a Global Policy when you want that policy to apply ALL the time to every environment and every catalog item.  

For example:

  • For data that always needs to stay in Australia, for example to comply with specific privacy requirements then you would set a Global data sovereignty policy.  Remember this would then apply to your development data as well as production.  If that doesn't suit perhaps you need separate environment policies.


This is where policies will become really useful but you'll want to remember to leave some room for those tight, end of project processes where more flexibility is likely to be needed.  Longer hours and fast turnaround are important options in IT. 

For example:

  • To get real savings from being in cloud you might put an hours of op policy on your dev environment that limited availability to 7 to 7 Monday to Friday. Again think about the exceptions before applying this one.


To apply consistent controls with each deployment record a policy on a Catalog item.


  • You may wish to apply a restriction on how much memory can be resized for where you've got a significant SQL server load. 

What's Next?

Types of Policies



Getting Going with Broker, Broker Knowledge Base 

Log a support ticket or ask the Community


Was this article helpful?
0 out of 0 found this helpful