bug/missing-sla-policies

[fivetran-catfritz]

PR Overview

This PR will address the following Issue/Feature:

• [Bug] Agent Work Time and Requester Wait Time Erroneously Being Filtered Out of zendesk__sla_policies #155
• zendesk fivetran DBT package is incorrectly calculating values from the source data #141

This PR will result in the following new package version:

• v0.17.0 since it will be released with PR bugfix/too-many-partitions #165.

Please provide the finalized CHANGELOG entry which details the relevant changes included in this PR:

Bug Fixes

• Fixed an issue in the zendesk__sla_policies model where tickets that were opened and solved outside of scheduled hours were not being reported.
  • Resolved by adjusting the join logic in int_zendesk__agent_work_time_business_hours and int_zendesk__requester_wait_time_business_hours. (#164, #156)

Under the hood

• Added integrity validation within integration tests to ensure zendesk__sla_policies and zendesk__ticket_metrics models produce consistent time results. (#164)
• Reduced the weeks looking ahead from 208 to 52 for performance. (#156)

PR Checklist

Basic Validation

Please acknowledge that you have successfully performed the following commands locally:

• dbt run –full-refresh && dbt test
• dbt run (if incremental models are present) && dbt test

Before marking this PR as "ready for review" the following have been applied:

• The appropriate issue has been linked, tagged, and properly assigned
• All necessary documentation and version upgrades have been applied
• docs were regenerated (unless this PR does not include any code or yml updates)
• regen on release branch!
• BuildKite integration tests are passing
• Detailed validation steps have been provided below

Detailed Validation

Please share any and all of your validation steps:

• As demonstrated in the related issue [Bug] Agent Work Time and Requester Wait Time Erroneously Being Filtered Out of zendesk__sla_policies #155, the agent_work_time and requestor_wait_time slas were not brought through in our test data. This was happening because tickets were getting filtered out where the start and end times had 0 overlap with a schedule. Adjusting the joins fixed this.

  • I created ticket '11106' to ensure it was completed entirely with no overlap with a schedule for testing.

• Below shows tickets '76' and '11106' with the current version of the package. As expected, we do not get all the SLAs.

  • 

• After the changes, all the SLAs are now present.

  • 

• Added integrity test sla_metrics_parity to make sure the sla_elapsed_time from zendesk__sla_policies matches the corresponding agent_work_time_in_business_minutes, requester_wait_time_in_business_minutes, or first_reply_time_business_minutes from zendesk__ticket_metrics.

• Added integrity test metrics_count_match to make sure my updates did not drop any tickets.

• All tests pass when the following vars are used:

  using_domain_names: false
  using_user_tags: false
  using_organization_tags: false
  fivetran_integrity_sla_metric_parity_exclusion_tickets: (1,56,80)
  fivetran_integrity_sla_first_reply_time_exclusion_tickets: (1,56,80)
  fivetran_consistency_sla_policies_exclusion_tickets: (76, 11106)
  fivetran_consistency_sla_policy_count_exclusion_tickets: (76, 11106)

• These tickets are omitted since 76 and 11106 are expected not to match, since this update fixes an issue with those tickets. (1,56,80) are from prior tests.

  • 

• I have also tested on customer data (see internal tickets) and confirm the models are behaving as expected.

If you had to summarize this PR in an emoji, which would it be?

💃

[fivetran-catfritz]

I updated this test since the prior version did not detect when the dev schema had extra tickets not present in the prod schema and should cause a failure unless omitted.

[fivetran-joemarkiewicz]

@fivetran-catfritz just two small comments in the CHANGELOG. Otherwise this looks good to me!

[fivetran-joemarkiewicz]

I know we somewhat mention it in the logic changes within relevant models, but can we explicitly callout here that this issue was identified and addressed for requester_wait_time and agent_work_time slas.

[fivetran-joemarkiewicz]

I don't love this suggestion, but want to add a bit more context here as to why we are making this change.

Suggested change

	- Reduced the weeks looking ahead from 208 to 52 for performance. ([#156](https://github.com/fivetran/dbt_zendesk/pull/156), [#167](https://github.com/fivetran/dbt_zendesk/pull/167))
	- Reduced the weeks looking ahead from 208 to 52 for to improve performance. This decision was made as it was found to be unnecessary to track ticket SLAs going out more than a year. ([#156](https://github.com/fivetran/dbt_zendesk/pull/156), [#167](https://github.com/fivetran/dbt_zendesk/pull/167))

[fivetran-catfritz]

How about this? G came up with it of course. 😄
Reduced the weeks looking ahead from 208 to 52 to improve performance, as tracking ticket SLAs beyond one year was unnecessary.

[fivetran-catfritz]

@fivetran-joemarkiewicz Updated the changelog with your suggestions. How does it look now?

[fivetran-catfritz]

How about this? G came up with it of course. 😄
Reduced the weeks looking ahead from 208 to 52 to improve performance, as tracking ticket SLAs beyond one year was unnecessary.