What happens when a new SLA policy is created?

does this still work? I'm trying to update as our SLAs were updated and some tickets still appear breached even after creating a new SLA using created at date and I've mass updated those tickets with a tag as suggested. However the tickets still appears breached and the adding of the tag did not result in the expected behavior that is explained in this tread. What am i doing wrong or is still no longer a thing with Zendesk?

Hi Alberto, if a ticket is suspended the tag trick won't work, as you'll have to first recover the ticket (only then you can update it in order for an SLA policy to be applied).

Last question: what if the ticket is suspended? Does the update "tag" trick work as well? 

Basically, among the number of dates, the SLAs dataset contains two apparently similar dates, Ticket update date and SLA update date, and I was wondering which of these is getting the update after a tag is added.

I'll simply try and see the result.

Hi Alberto Gugel, thanks for the example! Exactly: when the ticket was created or updated in March, an SLA policy was applied, and its First Reply Time metric was achieved.

Later on, some update between that date and Apr 27 caused an SLA policy change. This is likely because of your SLA conditions; your second policy is probably identical to the first but more specific (applying if the ticket belongs to a specific Organization, for example). So this table doesn't mean that multiple SLA policies are applied to the ticket, it shows the SLA policies that were and are applied to the ticket.

Regarding your last question, I don't quite follow, I'm sorry. Applying a tag is just a simple way to update the ticket without interfering with workflows, and this update will force Zendesk to check all triggers first, then all SLA policies second. Because it's a new tag, triggers shouldn't fire... And if there's a new policy that matches the ticket, it will be applied.

Hi Pedro Rodrigues and thanks for responding.

Here is what I intend:

Ticket 2832 is evaluated against two different policies. I think this is due to the fact that one metric was already completed/achieved when the new policies were created. Am I right? Please, consider we are looking at the SLAs dataset (i.e. Zendesk Explore).

Interesting the idea of applying a tag to trigger the sla/ticket update, but will it move the Ticket update or the SLA update date?

Thanks

Hi Alberto Gugel, SLA policies are configured almost like triggers, conditions-wise. For most customers the main goal is to ensure there aren't any conflicting policies enabled, unless we actually intend them to behave like that until the correct one is applied (as Zendesk checks them from top to bottom, as explained here).

Additionally, in order for a new policy to be applied retroactively to existing tickets, we must force an update event. Depending on the scenario, I usually advance-search the tickets I want - or create a view for that purpose - and then apply a specific tag (for example, 'admin_sla_new_yyyymmdd' -- where yyyymmdd is the current date) to create that update event.

Only one policy can be active per ticket, however, so I'm not sure I understand what you mean by "there are tickets associated with more than one policy".

Do you mean that multiple policies are being applied to a ticket when you look at ticket events?

Thanks in advance for clarifying!