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.

• Step1: Clone the Existing Policy Specification
• Step2: Apply the Required Specification Changes
• Step3: Configure the Assignment Rules
• Step4: Prevent Unwanted use of the Current Policy
• Step5: Test the New Behaviour
• Step6: Keep the Original Policy for Historical Reporting
• Step7: Switch on a New or Replacement Policy

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.

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

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.

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

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:

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):

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:

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:

OR

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.

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

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.

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:

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.

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.

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.

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: support@cloudset.zendesk.com).