Problem Definition

As a JSM administrator, there are possible situations when it might make sense to want to modify an SLA goal and have all corresponding issues recalculate (including issues that have already met the goal/non-ongoing SLAs). For instance: if the 'Time to first response' SLA goal was mistakenly typo'ed and a number of issues were opened and responded to (i.e., the goal hit a Stop condition) before the mistake was noticed and corrected.

According to our documentation, Setting up SLAs:

Updating SLAs

When you change the configuration of existing SLAs, we follow these rules:

• We don’t recalculate, or touch in any way, cycles that have already been completed. A cycle is completed when a request fulfills the Start and Stop conditions (depending on your configuration and events, another cycle of the same SLA might then be started).
• We recalculate ongoing SLAs so they measure against your new configuration and metrics.

It might happen that ongoing SLAs will be completed or discarded entirely after changing the configuration. This can happen if you remove the previous Start or Stop conditions or change them to something else, which will trigger the completion. As mentioned earlier, ongoing SLAs will be recalculated to use your new configuration.

Suggested Solution

A configuration option to select whether non-ongoing SLAs are affected by SLA goal configuration changes should be added to allow Administrators the option of modifying historical SLA data.

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available