• Added granular access control on create, delete, and run Playbooks and plays.

• Added the ability to add labels to Playbooks and then assign the labels to roles. This limits the access to run Playbooks based on labels and roles assigned to those labels.

• Enhanced the ability to store and visualise KPI sensor data to 72 hours.

• Added the ability to monitor CLI based KPIs for 3rd party devices.

• Enhanced the Alert Dashboard for better usability.

For information on how to use Cisco Crosswork Change Automation see the "Automate Network Changes" chapter in the Cisco Crosswork Change Automation and Health Insights User Guide.

• For information about using flexible Playbook development tools, see Custom Playbooks tutorial in Cisco Crosswork Change Automation Developer Guide on Cisco DevNet (https://developer.cisco.com/).

• When using dynamic tags to run a playbook on a set of devices, the playbook will be executed on groups of 20 devices at a time until the playbook has been run on all of the tagged devices.

For information on how to use Cisco Crosswork Health Insights, see the "Monitor Network Health and KPIs" chapter in the Cisco Crosswork Change Automation and Health Insights User Guide.

• Group the KPIs within a KPI Profile for monitoring relevant device metrics. For best results, limit to 10 KPIs per KPI Profile. Maximum number of KPIs that can be supported within a KPI profile is 50.

  Note

  The KPIs vary in the amount of data they collect. Although the system allows for up to 50 KPIs, care must be taken to ensure that you have both license and Crosswork Data Gateway capacity in place before deploying the KPIs. For more information, see the section Enable KPI Profile on Devices in Cisco Crosswork Change Automation and Health Insights 4.1 User Guide.

• For optimal performance, enable a KPI Profile in batches of no more than 100 devices.

  Note

  When you are enabling KPI profiles on devices, ensure that sufficient capacity is available on Cisco Crosswork Data Gateway. If sufficient capacity is not available, it may cause overload and outage. For more information, see the section Enable KPI Profile on Devices in Cisco Crosswork Change Automation and Health Insights 4.1 User Guide.

• For best system performance, use the default KPI cadence.

  Note	KPI cadence is set based on the nature of the KPI. Any decisions about using a lower cadence (for example, as low as 10 seconds) should be reviewed with Cisco Professional Services.

• Sometimes, under certain load conditions, the execution of a Playbook times out.

  • If it continues to fail, try changing the time out for the job.

  • If it fails because of the device being locked, try changing the device state to DOWN and UP again.

• While scheduling playbooks across a dynamic group tag, the corresponding job set screen for the job in the Job History page will not display the relevant devices, until the job is scheduled for execution.

• Running a Playbook on multiple devices at the same time with different collection_type parameter values may result in failure. Re-executing the failed Playbook will resolve the issue.

• Under extreme load conditions, Cisco Crosswork Change Automation may fail to clean up the collection jobs that were created. These stale collections jobs can be deleted using API.

• If you try to access Cisco Crosswork Change Automation UI after restarting the robot-nca pod, you may get a temporary error message (pstream host lookup failed) for 5 minutes.

• After a KPI Profile is enabled, editing cadence and threshold parameter for any of the associated KPIs can be achieved using one of the three procedures detailed below:

  • Create a custom KPI with the required cadence and threshold parameters and associate with the existing KPI Profile.

  • Create a new KPI Profile with the relevant KPIs associated. Update the cadence & alert parameters before enabling this new KPI Profile.

  • Disable the KPI Profile & perform the modifications on relevant associated KPIs and re-enable the KPI Profile.

• For custom KPIs:

  • While creating custom KPI using API directly, user must select the full sensor path to the leaf sensors (not partial sensor path) up to a certain hierarchy (gather path).

  • All leaf sensor paths are reserved for that KPI use only.

• Any Cisco Crosswork Health Insights job stuck in the processing state that does not complete within the stipulated time out of 60 minutes will be marked as "failed". After addressing any underlying issues (for example, device connectivity, credentials or NSO sync, and so on), the same job must be reapplied.

• Filtering is case sensitive for the Manage KPIs and Enable-Disable KPI Profiles pages.

• For using Cisco Crosswork Health Insights alert forwarding functionality, you must setup one Alert provider with correct credentials.

• You can view KPI graphical data in the Cisco Crosswork UI for the last 72 hours only, go to the grafana dashboard (https://<IPaddress:port>/robot-grafana/) and select the desired KPI.