About policies

Policies are rules that contain multiple condition and action sets. They can be triggered to reduce noise by suppressing alerts or grouping alerts together, automatically promote alerts to incidents, assign runbooks to remediate alerts, and invoke IBM Tivoli Netcool/Impact policies to take actions on your alerts.

Cloud Pak for AIOps policies are created in the Policy editor, where you can build condition sets based on Alert properties and Alert insights.

The policies table displays all of the Cloud Pak for AIOps policies that are preset, created by you and your team, or generated by AI analytics. You can enable or disable these policies, create new ones, and edit existing policies. When you click a policy in the table, you can see more details in the side panel. The list of policies is split by pagination, use the navigation arrows beneath the table to move between the next or previous page of policies. To customize the number of rows that are displayed in the table, click the Down chevron icon next to the Items per page.

By default, policies are sorted in the table by Order ascending (policies with a lower number are processed first). Where execution order is the same, policies are sorted by Last run descending (the most recent policies are displayed first in the table).

Note: Preset policy names and internal action references to "story" or "stories" are synonymous with incidents. Incident triggers and condition references supported in the "Invoke IBM Tivoli Netcool/Impact" policy template are stored as story. For policy search based on conditions, use "story" instead of "incident". For example, to find incident.title in a policy search, use story.title. These internal references and policy names have no bearing on actual behavior and are for internal processing purposes only. Any references to "story" in preset policy names, or other policy details or specifications is not an error, and is equivalent to incident in all respects.

Policies table columns

Policies table columns
Column	Description
Policy name	A name to identify the policy. The default name of a policy is automatically created based on the alert summary field, and specifically on the alert with the highest severity that has ocurred most frequently. To customize a policy name, point the cursor over the name and click Edit . Preset policy names cannot be customized.
Order	Determines the order in which the policy is executed. Execution order is set at policy creation time, on a sliding scale of 1-100. Policies with a lower number are processed first. This is especially important for incident policies. Set the execution order lower for your most important incident policies. Values outside of 1-100 are reserved for suppression, some analytics, and preset policies that handle system needs. Note: Actual execution order is a combination of trigger type and execution order. So when the table is sorted by execution order, you might see later Last run times on higher priority policies. This is because the processing for different triggers occurs at different times.
Tags	Tags are used to identify the different types of policies. Cloud Pak for AIOps policies are tagged with the following policy types: Analytics: policies generated by AI analytics. Analytics policies can be viewed, enabled, disabled, and deleted from the Policies table. Impact: a Cloud Pak for AIOps policy that invokes a IBM Tivoli Netcool/Impact policy, through a IBM Tivoli Netcool/Impact integration. By default, IBM Tivoli Netcool/Impact policies are invoked without input or transformation. Editing options are available in the IBM Tivoli Netcool/Impact policy template. Incident: policies to create actionable incidents from alerts to improve insights into your issue. Preset: preset policies define the core behavior of event and alert processing. Preset policies can be viewed, enabled, or disabled from the Policies table. Runbooks: policies that assign a runbook to alerts for easier automated resolution. Scope-based: policies that group alerts based on common properties and time of occurrence to identify when issues might be related. Seasonal: policies that group alerts together that occur within a seasonal time window. Suppression: suppress alerts that do not need attention to reduce noise and improve team focus. Temporal: policies that group alerts together that occur within a short time of each other. User: policies that can be edited by the user. All Runbook and Incident policies, even if tagged as Preset, are also tagged with User. User policies can be viewed, enabled, disabled, modified, and deleted from the Policies table.
Last modified	Displays a timestamp of the last modification to the policy. The date is expressed as month, day, year. The time is expressed as hours:, minutes:, seconds. The time also indicates whether AM or PM. For example, 3/9/2022, 4:45:17 PM. Enabling or disabling a policy, renaming or editing a policy, and adding a comment from the Journal tab in the side panel will all update the last modified time stamp.
Last run	Specifies the date and time on which a policy was last run. The date is expressed as month, day, year. The time is expressed as hours:, minutes:, seconds. The time also indicates whether AM or PM. For example, 3/9/2022, 4:45:17 PM. Note: If an alert meets the incident-creation conditions of multiple policies, only one incident is created. However, all policies that proposed an incident, and the system incident creation policy will have the same Last run time.
Status	The icons in this column indicate one of the following execution states for a policy: Policy successful, no recent failures Policy has not been attempted Policy successful, but has had recent failures Policy failed on last attempt
State	Denotes if a policy is Enabled or Disabled . You can click the toggle button to change a policy state. Disabled policies do not take any action against incoming alerts. You can also enable or disable a policy in the policy details side panel, or directly within a seasonality or temporal policy details page. Note: Disabling preset policies will prevent some event and alert processing features from working.

Note: A yellow execution status Policy successful, but has had recent failures will remain for 8 hours in the event where a policy fails, but then works. Irrespective of how many times the policy works in that 8-hour period. If a policy is "flapping", that is alternating between failing and working, the execution status flips between a yellow and red status.

For more information about policies, see the following topics:

The following policy templates are available: