Managing and Testing Policy Specification Changes

When making policy specification changes that will alter the calculation of targets and measurements, it is recommended that the changes are thoroughly tested before applying to your live tickets.

It is also often the case that there is a need to replace an existing policy, or make changes to the specification that shouldn't be applied to tickets until an agreed start date and time, or that the changes should only be applied to new tickets or those of a certain category.

When this need arrises, the following procedure is recommended to implement these changes.

  Advisory Note

It is advisable to walk through and familiarise yourself with this procedure before attempting to replace a policy specification or make updates to a policy specification that might cause significant changes to the calculation of your measurements.

Step1: Clone the Existing Policy Specification

Before any changes are made, the specification for the current policy should be cloned in order to create a new version.

This allows the new policy specification to be tested before applying to your live tickets and before the current policy is replaced.


Uniquely Name the Cloned Version

The cloned version of the policy should be uniquely named to distinguish from the current version.



Step2: Apply the Required Specification Changes

Make all necessary changes against the CLONED policy specification as described in the following article:  Creating and Maintaining Policy Specifications - (Policies Tab)

This might be changes to the priority dimension used in the policy specifications or the settings used during the calculation of targets and measurements.




Step3: Configure the Assignment Rules

Configure the rules that determine when the CLONED policy specification should be assigned to a ticket, as described in the article named Creating and Maintaining Policy - (Policies Tab) under the headings:

  • Defining Policy Selection Rules
  • Defining Policy Exception Rules
  • Policy Selection Fallback Rule

Create Unique Conditions for the Cloned Policy

Depending upon the purpose and scope of the specification changes, these assignment rules might be copied from the current policy, or created from scratch.

But if there is a need to continue using the current policy specification for existing tickets or different categories of ticket, the assignment rules must have at least one unique condition.

This can be achieved through the use of a new or existing ticket field value that uniquely identifies the ticket, for example:


OR through the presence of a tag value, and this is often best applied using an exception rule, for example:


Consider Guarding the use of the Cloned Policy

In order to prevent assignment of the CLONED policy before the specification has been fully tested, it might be necessary to consider the use of an exception policy to prevent assignment unless a specific tag has been added to the ticket, for example (This exception rule can be removed once the new policy specification is ready for use):



Step4: Prevent Unwanted use of the Current Policy

The assignment rules for the original policy might be similar to those for the new cloned policy, in which case there will be a need to organise the policy assignment rules so that the new policy version is assigned in place of the original version.

This can be achieved using one of the following options:

Option1: Apply an Exception Rule to the Original Policy

An exception rule can be used to prevent the policy assignment if the ticket has been categorised or tagged to indicate that the new version of the policy specification should be used, for example:





Option2: Reorder your Policies

Reorder your policy specifications as described in the article named Creating and Maintaining Policy - (Policies Tab), under the heading:

  • Specify the Precedence of Policy Selection Rules

Make sure that the new version of the policy is listed above the original version, to ensure the selection rules are checked first.

If the conditions are met without meeting the conditions for an exception rule, the new version will be assigned to the ticket and no further policy assignment rules are checked.



Step5: Test the New Behaviour

Once the specification changes have been applied in the new policy version and the assignment rules are in place, it will be possible to confirm that the policy is applied to a ticket when expected and the target date & time is calculated correctly for each event, for example:


It is also advisable to confirm that the following behave as expected:

  1. The event timers start, pause, stop and restart
  2. The events pass or violate
  3. The event measurements are correctly calculated



Step6: Keep the Original Policy for Historical Reporting

If you are using the measurements for the original policy within views and reports, it is recommended that the original specification is left in place.

Otherwise, if the policy is removed from your Performset configurations, the corresponding option value in the SLA3 SLA ticket field won't be available for use.

  Advisory Note

It will be necessary to update your views and reports to take account of the new version of the policy, since this will be given a different option value in the SLA3 SLA ticket field.

Option1: Prevent Further use of the Original Policy

If the original policy should no longer be used once the new version is switched on and all existing tickets using the original policy have been closed, the assignment rules should be adjusted accordingly.

This is best achieved using an exception rule to check for the presence of a tag value that will never be present on the ticket, for example:


Option2: Copy the New Specifications after Testing

If purpose of creating a new version is purely for testing purposes, it might be more appropriate to copy over the new specifications to the original policy once testing is complete.

  Advisory Note

This might include changes to the assignment rules, but any assignment rules introduced to the cloned version purely for testing need not be copied over.

Apply the Changes to the Original Policy

The changes must be copied by applying them manually against the original policy specification using the Performset configurator, but they won't take effect until the configurations are saved.

Remove the Unwanted Clone

Once the changes have been applied to the original version, the cloned version of the policy used for testing can be deleted, since it isn't required in your views and reports.



Step7: Switch on a New or Replacement Policy

If the new policy version isn't removed after testing and must be assigned to new tickets, it will be necessary to make the necessary adjustments in your Zendesk to switch on its use against your live tickets.

Depending upon the option chosen in Create Unique Conditions for the Cloned Policy above, it might be necessary to create a trigger to categorise or tag your tickets to meet the assignment rules for the new Policy version.

Otherwise, it might be necessary to instruct your agents to start using a new option value in a tickets field to categorise tickest so that the new policy version is assigned.

Considerations when Assigning the New Policy Version to Existing Tickets

If a decision is taken to assign the new policy version to existing tickets that have already been processed by the original version, it might be necessary to apply a reassessment or reenactment in order to accurately recalculate targets and measurements using the new specification.

This can be achieved by following the instructions in the article named Reassessing an Invalid SLA Measurement, but if there are a large number of existing tickets, it might be necessary to arrange a bulk reassessment with the cloudset support team (contact:

Was this article helpful?
0 out of 0 found this helpful



Please sign in to leave a comment.