Paragon Insights Rules and Playbooks

Rule Filtering

Starting in HealthBot Release 3.0.0, you can filter the Topics and Rules displayed on the left side of the Rules page. This allows you to quickly find rules that you are looking for. The search function works for topics, rules, sensor-types and other categories; working not only on titles, but also on the defined contents of rules.

The following procedure explains this filtering feature.

1. Navigate to Configuration > Rules in the left-nav bar.

   The Rules page is displayed. To the left of the rule definition area is a new section as shown in Figure 1 below.

   Figure 1: Rule Filtering

2. From the pull-down menu, select the type of search you want to perform.

3. In the search field, begin entering your search text.

   The topic list below shrinks to display only topics and rules that match your search criteria.

Sensors

Start configuring the new rule using the Sensor block. Figure 2 shows the sensor definition for the OpenConfig sensor pppoe-error-statistics.

Figure 2: A Sensor Definition

1. Click the add sensor button (+ Add Sensor).

   A new sensor definition appears and is named Sensor_random characters, like Sensor_2kgf04.

2. Change the sensor name to something that makes sense for the rule you are defining.

3. From the drop-down list, choose the sensor type. You can choose one of: OpenConfig, Native GPB, iAgent, SNMP, Syslog, or NetFlow.

   The required elements for defining the Sensor Type change depending on the selection you make. The frequency is expressed in #s, #m, #h, #d, #w, #y, or #o where # is a number and s, m, h, d, w, y specifies seconds, minutes, hours, days, weeks, years, and offset respectively. The o expression is used for defining an offset multiplier for use in formulas, references, triggers, learning periods, and hold-times.

   The following list describes the elements that change based on your choice of Sensor Type. None of the other rule elements change because of a Sensor Type selection.

   • OpenConfig

     Sensor path is defined from a drop-down list of available OpenConfig sensors. Frequency refers to how often, in seconds, the sensor reports to Paragon Insights. The frequency can be overridden if the sensor is included in a frequency profile.

   • Native GPB

     Sensor path refers to the path for a Native GPB sensor. Port refers to the GPB port over which the sensor communicates with Paragon Insights.

   • iAgent

     File is the name of a YAML-formatted file that defines the NETCONF-accessible sensor. Table is defined from a drop-down list of available PyEZ tables and views in the YAML file. Frequency refers to how often the sensor is polled by Paragon Insights and can be overridden by including the sensor in a frequency profile. Based on the table you’ve selected, input fields for a target or dynamic arguments might also be provided. For these additional fields, you can do one of the following: Leave the input field blank. No default value will be applied. Enter a fixed value that will remain constant. Enter a variable name enclosed in double curly/flower brackets (for example, {{test-variable}}) The variable name must belong to a variable that was previously defined in the Paragon Insights rule, and the variable’s Type option must be set to Sensor Argument.

   • SNMP	Table is defined from a drop-down list of available SNMP tables. Frequency refers to how often, in seconds, Paragon Insights polls the device for data and can be overridden by including the sensor in a frequency profile.

   • Syslog

     Pattern set is a user-configured element that includes one or more patterns (you configure a pattern for each event you want to monitor). The Maximum hold period is used in advanced cases and refers to the maximum time that the system will wait when correlating events using multiple patterns within a pattern set.

     Note:

     The syslog sensor requires some pre-configuration. See Syslog Ingest for more details.

   • Flow	Template Name is a Juniper-supplied built-in list of NetFlow v9 and IPFIX templates.

Fields

A sensor will generally carry information about multiple things. For example, a sensor that watches interfaces has information about all of the interfaces on the device. In Paragon Insights, we call these things Fields. Now that you’ve defined a sensor, you’ll need to tell Paragon Insights which fields you’re interested in.

1. Click the Fields link.

   The screen updates and shows the defined field objects.

2. Click the add field button (+ Add Field).

3. Replace the random field name with a name that make sense for the rule you are defining, such as interface-name, configured-threshold, etc.

4. (Optional) Add descriptive text for the new field.

5. Set the appropriate Field Type. The options for field type are: string, integer, float, and unsigned integer. String is the default field type.

   Starting in Paragon Insights Release 4.2.0, you can also select unsigned integer as a field type. An unsigned integer is a data type that can contain values from 0 through 4,294,967,295.

6. (Optional) Toggle the Add to rule key switch.

   The add rule to key switch tells Paragon Insights that this field should be indexed and searchable. For example, when you enable this switch, the field name will be listed on the Devices page under the Keys column.

7. Select the appropriate ingest type (Field source) from the pull-down menu.

   The following list shows the options available for the Ingest type (Field source) menu.

   • Sensor–Use this or another sensor definition.

     • Path-Follow this Open Config or Netconf path within the sensor definition to gather specific data like the names of the interfaces. For iAgent sensors the Path refers to the path defined in the YAML file.

     • Where–Filter the available data to gather information about a specific element within, like a specific interface. This field can reference the Variables defined elsewhere within the rule. When referencing variables, use moustache notation, enclosed in slashes, such as: {{interface_name}}.

     • Zero suppression-For some sensors associated with devices running Junos OS, such as Junos Telemetry Interface Open Config and native GPB sensors, no field data is sent from the sensor when the data’s value is zero. Enable the zero suppression switch to set the field data value to zero whenever no field data is sent from the sensor.

     • Data if missing-Specify a value as the default data value whenever no data is sent from the sensor. The format of the specified value should match the defined field type (string, integer, or float). If the zero suppression switch is also enabled, then the specified data-if-missing value is ignored, and the default sensor data value is set to zero.

   • Reference–A reference to a field or trigger value from another rule.

     • Data if missing-Specify a value as the default data value whenever no reference data is fetched. The format of the specified value should match the defined field type (string, integer, or float).

   • Constant–Use a constant when referring to a Variable defined within the rule, whose value doesn’t change, such as IO_Drops_Threshold A constant can also be a string or numeric value that does not change and is not a reference to a variable.

     • Constant value–Use moustache notation to reference the variable like this: {{IO_Drops_Threshold}}.

   • Formula–Select the desired mathematical formula from the Formula pull-down menu.

8. (Optional) Set the Field aggregation time-range. Located above the Fields tab with the general rule parameters, this periodic aggregation setting helps to reduce the number of data points entered in the database. For example, if the sensor settings specify that Paragon Insights ingests data every 10 seconds, you could configure this setting to aggregate and record the relevant field data, say, every 60 seconds. Note that when using this setting, any field-specific time ranges must use the same value.

Vectors

(Optional) Now that you have a sensor and fields defined for your rule, you can define vectors.

A vector is used when a single field has multiple values or when you receive a value from another field.

1. Click on the Vectors link.Figure 3 shows the Vectors block for a newly added vector.

   Figure 3: Vectors Block

2. Click the add vector button (+ Add Vector)

3. Replace the random vector name with a name that makes sense for your rule.

4. Select an ingest type from the drop-down list. The additional input fields will vary depending on the selection you make.

   For path:

   Parameter	Description
   List of fields	Select a field from the drop-down list. The list of fields is derived from all of the defined fields in this rule.
   Time-range	Specify a time range from which the data should be collected. The time range is expressed in #s, #m, #h, #d, #w, #y where # is a number and s, m, h, d, w, y specifies seconds, minutes, hours, days, weeks, and years respectively. For example, enter 7 days as 7d.

   For formula:

   Parameter	Description
   Formula Type	Select a formula type from the drop-down list: unique Creates a vector with unique elements from another vector. and Compares two vectors and returns a vector with elements common to both vectors. or Compares two vectors and returns a vector with elements from both vectors. unless Compares two vectors and returns a vector with elements from the left vector but not the right vector.
   Vector name	(Unique formula type only) Select a vector name from the drop-down list. The list of vectors is derived from all of the defined vectors in this rule.
   Left vector	Select a vector name from the drop-down list. The list of vectors is derived from all of the defined vectors in this rule.
   Right vector	Select a vector name from the drop-down list. The list of vectors is derived from all of the defined vectors in this rule.

Variables

(Optional) The Variables block is where you define the parts of the sensor that you are interested in. For example, a rule that monitors interface throughput needs to have a way to identify specific interfaces from the list of available interfaces on a device. The field details are discussed below.

1. Click on the Variables tab.

2. Click the add variable button (+ Add Variable)

3. Replace the random Variable name with a variable name that makes sense for your rule, such as pem-power-usage-threshold.

   Best Practice:

   The accepted convention within Juniper for naming of elements within Paragon Insights is to always start with a lower-case letter and use hyphens to separate words. Make sure that your variable names are unique, clearly named, and follow a recognizable pattern so that others can understand what the variable is for. Any abbreviations should be used consistently throughout.

4. Set an appropriate default value in the Default value field.

   Default values vary depending on field type. Integer field types use numeric default values, while string field types use strings to set exact defaults and regular expressions that allow you to set the default from a list. Any default values set during rule definition can be overridden at apply-time at either the device or device group level.

5. Select the appropriate variable type from the Type drop-down list.

   Available field types are: Integer, Floating Point, String, Boolean, Device, Device Group, and Unsigned Integer.

   Starting in Paragon Insights Release 4.2.0, you can also select unsigned integer as a variable type. An unsigned integer is a data type that can contain values from 0 through 4,294,967,295.

Functions

(Optional) Define any needed functions.

The Functions block allows users to create functions in a python file and reference the methods that are available in that file. The python file must be created outside of Paragon Insights. You must know about the method names and any arguments because you will need those when defining the functions.

Starting with Paragon Insights 4.2.0 release, you can use a Python user-defined function to return multiple values.

For example, consider that you have a function example_function.py that has three return values. When you call the example_function.py in a rule, the first return value in the user-defined functions (UDF) is stored in the rule field that calls the function. You only need to configure return fields, such as r2 and r3, for the remaining two return values. You can configure these fields for return values in the Return List of the Functions tab.

In the time-series database, the name of Return List fields are prefixed with the name of the rule field that uses the UDF. For example, rule_field_name-r2.

Figure 4 shows the Functions block for the chassis.power/check=pem-power-usage rule. The field details are discussed below.

Figure 4: The Functions Block

To configure a function:

1. Click on the Functions link.

2. Click + Add Function.

3. Enter a function name such as used-percentage.

4. In the Path to function field, enter the name of the python file that contains the functions. These files must be stored in the /var/local/healthbot/input/hb-default directory. The pull-down list is populated with all the Python (.py) files in that directory.

5. In the Method Name field, enter the name of the method as defined in the python file. For example, used_percentage.

6. (Optional) Enter a description for the function in the description box.

7. (Optional) For each argument that the python function can take, click the add argument button (+ Add Argument).

   Each time you click the add argument button, you’ll need to enter the name of the argument and set the toggle switch as to whether the argument is mandatory or not. The default is that none of the arguments are mandatory.

8. (Optional) If there are more than one return value in the function, click +Add Return List.

9. Enter a name for the return value and the data type, such as an integer.

Triggers

A required element of rule definition that you’ll need to set is the trigger element. Figure 5 shows the Triggers block for the system.memory/check-system-memory rule. The field details are discussed below.

Figure 5: The Triggers Block

Setting up triggers involves creating terms that are used to set policy. If the terms within a trigger are matched, then some action is taken. Terms can evaluate the fields, functions, variables, etc that are defined within the rule against each other or in search of specific values. Terms are evaluated in order from the top of the term list to the bottom. If no match is found, then the next term (if any) is evaluated until a match is found or until the bottom of the term stack is reached.

1. Click on the Triggers link.

2. Click on the add trigger button (+ Add Trigger).

3. Replace the random trigger name with one that makes sense for the trigger you are defining, such as foo-link-operation-state. We recommend using a name that is very unique to the rule and trigger to avoid having the same trigger name across two or more rules.

4. (Optional) Enter a value in the Frequency field. This value tells Paragon Insights how often the field data and triggers should be queried and evaluated. If no entry is made here, then the sensor frequency is applied for this value. The frequency entered here can be entered as a multiple or, an offset, of the sensor frequency such as 2o. For example, if the sensor frequency is 10s and the trigger frequency is 2o, then the trigger frequency would be 20s (2*10s).

5. Click the add term button (+ Add Term).

   The Term area will expand and show an add condition button, (+ Add Condition) in the When section and Color and Message fields in the Then section.

6. To define a condition that the term will evaluate, click the + Add Condition button.

   The When section expands to show Left operand, Operator, and Time range fields.

   Note:

   Setting a condition is not required. If you want to guarantee that a Term takes a specific action, don’t set a condition. This could be useful, for example, at the bottom of a term stack if you want some indication that none of the terms in your trigger matched.

7. Select values from the pull-down menus for each of these fields.

   Depending on which Operator is chosen, a new field, Right operand may appear in between the Operator and Time range fields.

   The left and right operand pull-down menus are populated with the fields and variables defined in the rule. The operator field determines what kind of comparison is done. The time range field allows the trigger to evaluate things such as if there were any dropped packets in the last minute.

8. (Optional) Set values for the Color and Message fields, and add Action Engine information in the Then section.

   These fields are the action fields. If a match is made in the condition set within the same term, then whatever action you define here is taken. A color value of green, yellow, or red can be set. A message can also be set and is not dependent on whether any color is set.

   Starting in Paragon Insights Release 4.2.0, you link action workflows (Action Engine) to rules while setting up triggers. You can also add input arguments while linking action workflows. The Action Engine section is enabled only with a PIN-Advanced license. For more information, see Paragon Insights Licensing Overview.

   If color or message are set, a toggle button labelled Evaluate next term appears at the bottom of the Then section. The default value for this button is off (not active).

   Note:

   If no match is made in the When section of a term, the Then section is ignored. If this happens, the next term down, if any, is evaluated.

   If a match is made in the When section, then the actions in the Then section, if any, are taken and processing of terms stops unless the Evaluate next term button is set to on (active).

   Setting the Evaluate next term button allows you to have Paragon Insights make more complex evaluations like ’if one condition and another condition are both true, then take this action’.

Rule Properties

(Optional) Specify metadata for your Paragon Insights rule in the Rule Properties block. Available options include:

For more information on rules and telemetry sensors supported in a Junos OS and Junos OS Evolved software release for a specific hardware platform, see Telemetry Sensor Explorer.

Pre/Post Action

You can use the following general workflow to work with pre- or post-action tasks:

1. Configure Action Engine Workflows. See Manage Action Engine Workflows for more information.

2. Configure Pre-Action or Post-Action tasks depending on your use case.

   See Pre-action Tasks to configure pre-action tasks and see Post-action Tasks to configure post-action tasks.

3. Create a playbook with rules that have pre or post-action tasks. See Paragon Insights Rules and Playbooks for more information.

4. Run an instance of the new playbook on device groups to execute pre-action tasks. See Paragon Insights Rules and Playbooks for more information.

5. Stop the instance of the new playbook to execute post-action tasks. See Paragon Insights Rules and Playbooks for more information.

6. Monitor the status of pre-action and post-action tasks. See Manage Action Engine Workflows for more information.

Before you configure pre-action and post-action tasks in rules, you must configure Action Engine workflows. See Manage Action Engine Workflows to configure Action Engine workflows.

To configure pre-action tasks:

1. Click the Pre/Post Actions tab on the Rules page.

2. In the Pre-Action section, select an action engine workflow in the Action Engine field.

3. Enter the input argument from the list in the device field. The list shows arguments you previously configured in the selected action engine workflow as the pre-action task.

4. Enable execute-once if you want Paragon Insights to execute the pre-action task only once on each device in a device group.

5. Do one of the following:

   • Click Save to save your configuration changes but do not deploy the updated configuration. You can use this option when, for example, you are making several changes and want to deploy all your updates at the same time later. See Commit or Roll Back Configuration Changes in Paragon Insights for more information.

   • Click Save and Deploy to save the rule configuration in the GUI and deploy the configuration. When the rule is included in a playbook and a playbook instance runs on a device group, Paragon Insights executes the pre-action task parallel to ingesting telemetry data.

Before you configure pre-action and post-action tasks in rules, you must configure Action Engine workflows. See Manage Action Engine Workflows to configure Action Engine workflows.

To configure post-action tasks:

1. Click the Pre/Post Actions tab on the Rules page.

2. In the Post-Action section, select an action engine workflow in the Action Engine field.

3. Enter the input argument from the list in the device field. The list shows arguments you previously configured in the selected action engine workflow as the post-action task.

4. Enable execute-once if you want Paragon Insights to execute the post-action task only once on each device in a device group.

5. Do one of the following:

   • Click Save to save your configuration changes but do not deploy the updated configuration. You can use this option when, for example, you are making several changes and want to deploy all your updates at the same time later. See Commit or Roll Back Configuration Changes in Paragon Insights for more information.

   • Click Save and Deploy to save the rule configuration in the GUI and deploy the configuration. When you stop the playbook instance (with this rule) from running on a device group, Paragon Insights executes the post-action task after it stops the service for playbooks.

View Information About Playbook Instances

To view information about playbook instances:

1. Click the Configuration > Playbooks option in the left-nav bar.

   The saved playbooks are listed in the table on the main Playbooks page.

   

   • Playbooks that have been applied to a device group or network group are identified in the table by a right caret next to the playbook name.

   • The Instances column in the table shows the number of playbook instances running and paused.

   • Starting with HealthBot Release 3.1.0, some playbooks require the purchase and installation of advanced or premium licenses. These playbooks are identified by the green circle with a white star in it. As shown above, it tells you which license is required when you hover your mouse over the icon.

   • The Live column (in the Action section of the table) shows a colored circle indicator that represents the overall status of the playbook instances for each playbook. The following table provides the color definitions:

     Table 1: Color Definitions for the Live Column

     Color	Definition
     Green	All instances associated with this playbook are currently running.
     Yellow	One or more instances associated with this playbook are paused.
     Gray/Black	There are no instances associated with this playbook, or an instance is associated with this playbook but the configuration has not been deployed yet.

2. Click on the caret next to the playbook name to expand or collapse the playbook instance details. If no caret is present, then the playbook has not been applied to any device groups or network groups.

   The following playbook instance details are displayed:

   Column Name or Widget	Description
   Instance Name	User-defined instance name.
   Schedule	Name of the schedule profile applied to the playbook instance. For information on how to configure a schedule profile, see Create a Schedule to Automatically Play/Pause a Playbook Instance Click on the name to display the schedule details.
   Device/Network Group	Device group or network group to which the schedule is applied.
   No. of devices	Number of devices on which this playbook instance is deployed. This is applicable for device group instances only, not for network group instances.
   Status	Current status of the playbook instance. Status can be either Running or Paused. The Status column also indicates whether the action was performed automatically or manually. Note: If the status of a playbook instance is Running (automatic), you can manually pause the schedule for this instance using the Pause Schedule button. In this case, the status will change to Paused (manual). To resume running the schedule for this instance, you must manually run the instance using the Play Schedule button. In this case, the status will change back to Running (automatic), and the play and pause actions associated with the schedule will resume.
   Started/Paused at	Date and time when the playbook instance was last started or paused. The date reflects local browser time zone.
   Next Action	This column applies only to playbook instances associated with a schedule. It indicates whether the playbook instance is scheduled to automatically pause or play in the future. This column is blank if no schedule is associated with the playbook instance or if the status of the instance is Paused (manual).
   Play/Pause button	Pauses or plays a playbook instance or the schedule for a playbook instance. The Play/Pause button toggles between the two states. For more information, see Manually Pause or Play a Playbook Instance.
   Trash can icon	Deletes the playbook instance.

Create a Playbook Instance

To create a playbook instance for a device group:

1. Click the Configuration > Playbooks option in the left-nav bar.

2. Click the Apply icon (in the Action section of the table) for the desired playbook.

   A pane titled Run Playbook: <playbook-name> appears.

3. In the Name of Playbook Instance field, fill in an appropriate name for this instance of the playbook. This is a required field.

4. (Optional) In the Run on schedule field, choose the name of the schedule that you want to apply to this playbook instance. You can apply only one schedule per playbook instance. If you want a specific playbook instance to run on multiple schedules, you must create multiple versions of the instance, each with its own unique name and schedule.

   For information on how to configure a schedule, see Create a Schedule to Automatically Play/Pause a Playbook Instance.

   To view information about an existing schedule:

   1. Click the Settings option in the left-nav bar.

   2. In the Scheduler Settings section, a summary of the properties for each saved schedule is shown in the table. Click on a specific schedule name to view additional details.

5. In the Device Group section under Rules, apply this playbook instance to the appropriate device group using the drop-down list.

   The list of devices in the Devices section changes based on the device group selected.

   Note:

   If your playbook contains network rules, the Device Group section does not appear. Instead, it is replaced with a Network Groups section (not shown).

6. Click one of the devices listed in the Devices section.

   Here is where you can customize the variable values that will be set for this device when the playbook is run.

7. In the section titled Variable values for Device <Device Name>, the variables for each rule in the playbook can be seen by clicking on the rule name. The default values for each variable are displayed as grey text in each field. You can leave these values as-is or override them by entering a new value.

   Repeat steps 6 and 7 for each device in the device group, as needed.

8. When you are satisfied that all of the variable values are appropriate for all the devices in the device group, select one of the following options.

   Save Instance	Save your edits but do not deploy the updated configuration and do not run the instance. You can use this option when, for example, you are making several changes and want to deploy all your updates at the same time.
   Run Instance	Deploy the configuration, and, if no schedule profile was applied, immediately run the instance. If a schedule profile was applied, the instance will run according to the configuration of the profile.

Manually Pause or Play a Playbook Instance

When an instance is paused, Paragon Insights does not collect, analyze or raise an alarm on the device or network group data associated with the playbook rules. Data collected prior to pausing the instance is retained in the system, but no new data is collected or analyzed until the instance is played again.

The following table describes the state of the playbook instance when a particular button is displayed in the Play/Pause column:

To manually pause a playbook instance or schedule:

1. Click the Configuration > Playbooks option in the left-nav bar.

   The list of existing playbooks is displayed.

2. Click the caret next to the name of the playbook that you want to pause.

3. Choose one of the following options:

   • Click the Pause Instance button to pause a playbook instance (not associated with a schedule).

   • Click the Pause Schedule button to pause the schedule that’s associated with a playbook instance.

4. The Play/Pause Playbook Instance dialog box appears. Select one of the following options:

   Pause

   Flags this playbook instance to be paused the next time you deploy the configuration. Use this option if you are making several changes and want to deploy all your edits at the same time.

   Pause & Deploy

   Immediately pause the playbook instance and deploy the configuration. It will take a few seconds for the playbook table to update to show the instance is paused. There is a slight delay in updating the table because the play and pause actions are asynchronous and run in the background, allowing you to perform other actions. The status of this asynchronous activity can be tracked through the deploy icon located in the upper right corner of the window (as indicated in the success message of deploy action). Once this action is complete, the status is reflected in the playbook table as well.

   Once the playbook table is refreshed, the playbook name shows a yellow icon in the Live column as a visual indicator that an instance is paused.

5. To resume a paused playbook instance, follow the same steps as above except choose one of the following options for Step 3:

   • Click the Play Instance button to resume running a playbook instance (not associated with a schedule).

   • Click the Play Schedule button to resume running the schedule associated with a playbook instance. The schedule determines when the instance resumes playing.

Create a Schedule to Automatically Play/Pause a Playbook Instance

To automatically play/pause a playbook instance, you must first create a schedule and then apply the schedule to the playbook instance. You can apply only one schedule per playbook instance. If you want a specific playbook instance to run on multiple schedules, you must create multiple versions of the instance, each with its own unique name and schedule.

To create a schedule for a playbook instance:

1. Click the Settings > System option in the left-nav bar.

2. Click the Scheduler tab.

3. In Scheduler Settings, click the add scheduler button (+ Scheduler).

4. Enter the necessary values in the text boxes and select the appropriate options for the playbook instance schedule.

   The following table describes the attributes in the Add a scheduler and Edit a scheduler panes:

   Attributes	Description
   Name	Enter the name of the playbook instance schedule.
   Scheduler Type	Choose discrete. You can configure a discrete length of time to play the playbook instance using the Run for field. Once the run time has ended, Paragon Insights will automatically pause the instance. You can also configure Paragon Insights to automatically resume playing the instance using the Repeat field.
   Start On	Use the pop-up calendar to select the date and time to play the playbook instance for the first time.
   Run for	Configure a discrete length of time to play the playbook instance. First enter an integer value and then choose the unit of measure (minute, hour, or day) from the drop-down list. Once the run time has ended, Paragon Insights will automatically pause the instance. You can also configure Paragon Insights to automatically resume playing the instance using the Repeat field.
   End On	(Optional) Use the pop-up calendar to select the date and time to pause the playbook instance indefintiely. Leave blank if you want the playbook instance to play indefinitely. Note: If a playbook instance is associated with a schedule and is running when the End On time is reached, then the instance will continue to run until the configured Run for length of time is reached. At this time, the instance will pause indefinitely.
   Repeat	Configure the Run for field before configuring the Repeat field. The Repeat interval must be larger than the configured Run for length of time. In the drop-down list, choose one of the following: The frequency (every day, week, month, or year) at which you want the playbook instance to play. The Never option if you want the playbook to play only once. The Custom option to specify a custom frequency at which you want the playbook instance to play. Use the Repeat Every field to configure the custom frequency.
   Repeat Every	(Optional) If you chose the Custom option for the Repeat field, enter the custom frequency at which you want the playbook instance to play. First enter an integer value and then choose the unit of measure (minute, hour, or day) from the drop-down list.

5. Click Save to save the configuration or click Save and Deploy to save and deploy the configuration.

6. Now you’re ready to apply the schedule to a playbook instance. For more information, see Create a Playbook Instance.