review updates

CHANGELOG.md

@@ -10,6 +10,7 @@
 - Included additional logic within the `int_zendesk__ticket_schedules` model to more accurately select the **active** default schedule.
   - Previously the model could possibly select a deleted schedule. This update ensures only an active schedule is selected.
 - Overhauled the logic used to calculate `sla_breach_at` within the `zendesk__sla_policies` and upstream models for reply time SLAs. It was found this field was inconsistent with the actual breach/achieve time of an SLA. The overhaul should now ensure reply time SLA is accurate to either be the time of the SLA breach or achieve event.
+  - In particular, for first and next reply time SLAs the `sla_breach_at` will be the time of the breach if the SLA was breached or the time the SLA was achieved if it was not breached.
 - Adjusted the `next_reply_time` SLA elapsed time metric calculation to also take into consideration the ticket solved event as a valid SLA event. Previously if a reply time SLA was attached to a ticket and there was no reply, but the ticket was closed then the SLA would be breached. This update ensures a closed event serves as a route for the SLA to be achieved or breached.
 - Modified the logic that matches schedule weeks when calculating reply time business metrics. Previously long running SLAs would be excluded from the final model, now all reply time business SLAs regardless of sla elapsed duration will be included in the end `zendesk__sla_policies` model.
 

models/sla_policy/reply_time/int_zendesk__reply_time_business_hours.sql

@@ -62,8 +62,6 @@ with ticket_schedules as (
 
     from ticket_sla_applied_with_schedules
     cross join weeks
-    -- We need to understand more why the below is needed. I feel this is more a performance issue than a data quality issue. Still need to confirm.
-    {# where {{ fivetran_utils.ceiling('target/total_schedule_weekly_business_minutes') }} >= generated_number - 1  #}
 
 ), weekly_periods as (
 

models/sla_policy/reply_time/int_zendesk__reply_time_calendar_hours.sql

@@ -10,9 +10,9 @@ with sla_policy_applied as (
   select
     *,
     {{ fivetran_utils.timestamp_add(
-        "minute",
+        "second",
         "cast(target as " ~ dbt.type_int() ~ " )",
-        "sla_applied_at" ) }} as sla_breach_at
+        "sla_applied_at" ) }} / 60 as sla_breach_at
   from sla_policy_applied
   where not in_business_hours
     and metric in ('next_reply_time', 'first_reply_time')

models/sla_policy/reply_time/int_zendesk__reply_time_combined.sql

@@ -158,8 +158,8 @@ with reply_time_calendar_hours_sla as (
   select  
     *,
     case when is_sla_breached
-      then sla_breach_at
-      else coalesce(agent_reply_at, next_solved_at)
+      then sla_breach_at -- If the SLA was breached then record that time as the breach 
+      else coalesce(agent_reply_at, next_solved_at) -- If the SLA was not breached then record either the agent_reply_at or next_solve_at as the breach event time as it was achieved.
     end as sla_update_at,
     case when total_runtime_minutes < 0 -- agent has already replied to prior to this SLA schedule
         then 0 -- so don't add new minutes to the SLA

models/zendesk__sla_policies.sql

@@ -123,7 +123,7 @@ select
   in_business_hours,
   sla_breach_at,
   case when sla_elapsed_time is null
-    then {{ dbt.datediff("sla_applied_at", dbt.current_timestamp_backcompat(), 'minute') }}  --This will create an entry for active sla's
+    then ({{ dbt.datediff("sla_applied_at", dbt.current_timestamp_backcompat(), 'second') }} / 60)  --This will create an entry for active sla's
     else sla_elapsed_time
       end as sla_elapsed_time,
   sla_breach_at > current_timestamp as is_active_sla,