Default Policy

The default policy feature allows you to preset object properties to override factory default values with your own values - when new objects are created. Default policies can be set for each object type a user can create. Default policies can be set at the root of the Job Scheduler and on any folder or plan object (the three ActiveBatch containers). They are created on the container-level because they are policies governing objects that are placed in the container. This means you can have different default policies for different containers. Benefits of using this feature include:

 

• Reducing typos and other data entry mistakes when new objects are being created.

• Speeding up the process of object creation, since properties will be preset.

• Setting standards, since the properties will be the same for objects that are using the policy.

 

How to create a default policy

 

Using the Navigation pane, right click on the desired container (Scheduler root, folder or plan) that you wish to create a default policy for. Select Policy > Defaults.

 

A Default Policies window will pop up. Select the object type you wish to create a default policy for, then click the SET button, as depicted in the image below.

 

 

A new tab will be added the Main view named New <Object Type> Default Policy. The new tab will display the property sheets for the object type you selected to create a policy for. This is because they are the object's property sheets - except you aren't creating a new object, you are creating a new default policy for that object.

 

Navigate to the property(s) you wish to preset and enter your desired values.

 

Note: If the property you wish to preset is not listed on the property sheet, that means there is a limitation that does not allow the property to be preset. For example, you cannot preset the Alert properties of a Default Job Policy. Therefore, the Alerts tab is not present when creating a Default Job Policy.

 

 

When you are done presetting properties, click the Save or Save and Close toolbar item. When a default policy is set on a Folder or Plan, the Folder or Plan's icon in the Navigation pane will change to indicate this. Also, the Default Policy window, as depicted below, will display object(s) configured using a default policy in a different color (in this example, there is a default Job policy set).

 

 

How default policies are applied to newly created objects

 

Any time you add a new object type, the system looks to the closest (parent) container object for a default policy (to see if one has been configured). 

 

For example, if you are adding JobA to Folder2, the system checks to see if a default job policy has been set on Folder2 (since Folder2 will be the job's parent container after it is saved). If the system finds a default policy on the parent container (Folder2), it stops looking and uses it. If it does not find a default policy on the parent container, it will look to the next closest container for the object being added. In continuing with our example, if JobA is being added to Folder2, and Folder2 is a child object of Folder1 (JobA's full path is /Folder1/Folder2/JobA), the system will look to see if a default Job policy has been set on Folder1 (if it does not find one of Folder2). If it finds a policy there, it stops looking and uses it. If it does not find a policy, it looks to the next container (in this example, only the root is left), looking for a default job policy. As stated, the system stops looking for a policy as soon as it finds one. If one is not found, the property sheets for the new object will be tabbed in the Main view and consist of factory default property settings, including security. 

 

Security is often a consideration when setting default policies. Oftentimes factory default security is not what customers want to keep. Therefore, setting up a default policy that includes the security that the new objects should be configured with is frequently used. Keep in mind that every object type (e.g. queue, user account, job, plan etc.) that a user can create should have a default policy created with security configured, unless you want the object to consist of factory default security.

 

Setting a default job policy to preset the job's queue and user account object is another good use of default policies. Every job must be associated with a queue and user account. When presetting these values in a default job policy, the job author creating the new job does not have to populate these properties using the dropdown list to navigate to, then select, the desired queue or user account. If the queue and/or user account is different based on the type of job being added, then create different containers for those objects and set the default job policy accordingly.

 

Note: Default policies can be overridden by the user creating the object. For properties that support entering a simple string or numeric value, the user can delete the default policy value and enter their own value. For properties that support a checkbox, the user can uncheck the box, and so on. However, if the property that is being overridden is referencing an object (e.g. a queue, user account, schedule, alert, etc.), then the user must be granted the "use" permission for the object they are selecting to override the default policy with. Otherwise, they will receive an access denied error when attempting to save the object.