Starting version 8.9.03, BMC Network Automation is renamed to TrueSight Network Automation. This space contains information about BMC Network Automation 8.9.02 and previous versions. For TrueSight Network Automation 8.9.03 and later releases, see the TrueSight Network Automation documentation.

Adding or editing a policy

This topic was edited by a BMC Contributor and has not been approved.  More information.

This topic provides instructions for adding or editing a policy and describes how policies interact with conditions.

BMC Network Automation supports the following types of policies:

  • Time-based policies: Execute once at a specified date/time, or on a recurring basis. Time-based policies can run conditionally or unconditionally. When using condition(s) in a time-based policy, the condition(s) must have occurred in the past for a designated network span at the time of execution.
  • Event-based policies: Triggered by detected conditions (that is, events). These events can be from external systems (for example syslog), events reporting detection of configuration changes or discrepancies, system events, user events, policy events, and so on.


  • The default action on some predefined policies is to log an event. Before enabling the policy, delete this action and add the appropriate email or SNMP notifications.
  • BMC strongly recommends that you enable the Auto Archive policy so hat configuration changes made external to the system can be detected, archived, and audited in realtime. See Configuring existing syslog servers to forward events.
  • Additional information about configuring policy notifications (for example, compliance violations detected) can be found in Managing policies and Performing a quick start configuration.

To add or edit a policy

  1. In the BMC Network Automation console, click the Policies tab, and select Policies > Policies.

  2. On the Policies page, perform one of the following actions:
    • To add a new policy, select Add.
    • To edit an existing policy, select Edit in the relevant row.
    • To create a new policy by copying and editing an existing policy, select Copy in the relevant row.
  3. On the Details tab of the Add/Edit/Copy Policy page, enter information in the following fields:




    Specify a unique name for the policy, up to 40 characters.


    (Required for a new policy) Specify either time or event-based policy.


    Select any of the following options:

    • Enabled: Select to enable the policy.
    • Auto Purge: Select to purge the policy when it becomes dormant. A policy becomes dormant when the end date/time has expired. If you plan to run the policy after it has become dormant (for example scheduled run once snapshot), clear this check box.
    • On Error, Skip Remaining Actions: If an action fails, skip remaining actions.

    (Applicable for version 8.9.01 and later) Send Notification

    Whether to send an email and SNMP trap notification to one or more recipients and SNMP manager stations based on the state changes in the job that is created when the policy executes.

    (Applicable for version 8.9.00) Send EmailWhether to send an email based on job state transitions in the job that is created when the policy executes.
  4. For a time-based policy, specify how often to run the policy through the Repeat field. Then set the start time, end time, and run times. The exact method to set the run times differs, depending on your choice in the Repeatfield.
    • Run Hourly: Run policy hourly at the specified runtimes (up to every 5 minutes)
    • Run Daily: Run policy daily at the specified runtimes.
    • Run Weekly: Run policy weekly at the specified runtimes.
    • Run Monthly: Run the policy monthly at the specified runtimes.
  5. For an event-based policy, configure the following settings:
    • Execution Delay: (Optional) Specify the number of minutes (from 1 to 60) to delay execution of the policy after it is triggered. A value of blank or zero disables the delay, resulting in immediate execution of the policy when a trigger is received.
      Policies shipped with BMC Network Automation have the delay disabled. During the delay, if an identical trigger occurs, the policy does not run again on that trigger, as the original run is still pending.
      Use the delay when, under normal operating conditions, multiple identical triggers can be expected within a short period of time.


      • If users make manual changes to a device by going in and out of config mode repeatedly and generate several syslog messages that trigger the Auto-Archive policy, a delay in the policy (for example, five minutes) can reduce the number of snapshots caused by several device changes performed close together.
      • If a configuration has multiple compliance violations causing multiple events to trigger a policy, using the delay enables the policy to run only once for all detected violations.
    • Activate & Deactivate: Specify when the policy is active (for example select Current and Never for a policy that should always be active).
    • Interval: (Optional) Specify time of day when the policy is active (for example from 8:00 to 18:00--core business hours). Unselect the interval if the policy is active all hours of the day.
    • Weekday: (Optional) Specify which days of the week the policy is active (for example Monday-Friday). If you want to run the policy every day of the week, do not select any of the days.
  6. On the Conditions tab, associate conditions with the policy.
    Conditions are required for event-based policies, and optional for Time-based policies. You must define conditions first for use in a policy. The conditions below state execute the policy actions when no other compliance violations have been reported in the recent past.

    Specify conditions through the following fields:
    • Triggering Condition: Select a condition that triggers the testing of all other conditions (specified in the Other Conditions box). When the triggering condition and other conditions are true, the policy initiates the Action list.
    • Other Condition(s): (Optional) Logical expression of conditions that have occurred in the past (for example, Change Detected Past).
      To connect multiple conditions or modify a condition, select an operator — AND, OR, NOT, or an opening or closing parenthesis.
      To add or remove a condition, use the + or - buttons.
  7. On the Actions tab, specify the actions to be executed when the policy condition is evaluated as true by clicking Add Action in the menu and selecting the actions to be added to the list.

    For a list of available actions and their associated parameters see Managing jobs.
    You can perform the following actions on actions:

    ViewView policy action.
    EditEdit policy action.
    CopyCreate a copy of policy action.
    DeleteDelete policy action.
    Move DownChange the order of actions downwards.
    Move UpChange the order of actions upwards.
  8. On the Job Details tab, assign dynamic field values for the job that is created when the policy executes.
  9. If you are editing an existing policy, on the Status tab you can view historical policy executions and you can select a Job ID to display the Job Details report. 

    The report shows details of any action completion status and any configuration changes made or detected, as applicable. 
  10. Click Save.

Back to top

How policies interact with conditions

In the BMC Network Automation system, any event logged to the Event Log can cause a policy to trigger. These events include external events (syslog), configuration change detection events, and configuration discrepancy events. All policies must have a triggering event. For time-based policies, time is the trigger that wakes up the policy. For event-based policies, the Triggering Condition is the triggering event that wakes up the policy.

In the example, the Triggering Condition is Compliance Violation Detected Now. The policy time is the past 1 minute (see below). So if within the policy time two or more compliance violation events (that is, Occurrence Count = 2) are logged, the policy is triggered once (that is, suppress multiple notifications if configuration file has more than one violation).

Multiple policies can be active at one time. For example, one policy can send notifications of security changes to the security team; another policy can send notifications of Running versus Startup discrepancies to the Engineering team; while another policy can be monitoring device configuration changes to perform real-time configuration snapshot operations.

For more about creating or editing conditions, see Viewing the conditions listing.


When a policy includes emailing attached reports, it is possible those reports are configured for the Entire Network span. Normally, selecting Entire Network results in a report filtered by the security restrictions of the requesting user. That is, the report does not include devices in realms the user cannot access. Because a policy is not associated with any particular user, this security filtering does not occur. A report on the Entire Network can include every device in the BMC Network Automation system (optionally filtered by a device filter). Caution is needed to ensure sensitive information about the network is not disclosed to unauthorized email recipients. In addition, a report on the Entire Network can consume a lot of CPU while being generated.

Back to top

Related topics

Viewing the policies listing
Creating a notification job
Creating a configuration snapshot

Was this page helpful? Yes No Submitting... Thank you