Software AG Products 10.11 | Using CentraSite | Policy Management | Introduction to Design and Change-Time Policies | Issues to Consider When Creating Design/Change-Time Policies
 
Issues to Consider When Creating Design/Change-Time Policies
The following are issues that may occur when creating Design/Change-Time policies for your CentraSite registry:
*When an event occurs in the registry, CentraSite executes all policies whose scope encompasses the event. Use priorities to control the order in which CentraSite executes the policies. Consider assigning something other than the default priority of 11 to routine policies. Doing this enables you to more easily interject higher priority policies for the events associated with those policies.
*Many of the built-in actions provided with CentraSite (including the approval actions) are scoped for state-change events and can only be used with objects that are under lifecycle management. Before you create a policy, determine which policy actions you want to use and verify the event types that they support. To create certain types of policies, you may have to first apply a lifecycle model to the objects that you intend to govern with those policies.
*Exercise caution when using OnTrigger policies! If the policy updates objects, the scope of the policy is set precisely and targets only the set of objects that you intend to change. If used incorrectly, this type of policy can change objects in ways that cannot easily be undone.
*By default, CentraSite is configured to record only policy failures in the policy log. You can optionally configure CentraSite to log both successful and failed policies in its log. However, if you do this, the log can grow rapidly. Consider logging successful policy executions only when it is necessary for tracing or troubleshooting purposes or if you enable this option as part of your normal operations, consider purging the log on a regular basis.
*When CentraSite executes a policy, the policy's actions are executed on behalf of the user who triggered the policy (the actions are executed under that user's account). If the user does not have the permissions necessary to complete an operation initiated by a policy action, the action and the policy fails. For example, if a user triggers a policy that sets permissions on an object, the policy fails unless the user has full permission on the object. (Only users with full permission on an object are allowed to change the object's permission settings.)