Release Notes

September 2026

We've made the following changes in v1.8.0:

• Resolved custom ticket field IDs in the ticket_field_history_columns variable to their actual field titles, so int_zendesk__field_history_pivot and zendesk__ticket_backlog use readable custom field names instead of raw numeric IDs. Custom fields can be referenced by either their numeric ID or their title. If multiple custom fields resolve to the same title, the raw field ID is appended to keep column names unique, and a field with no title falls back to its ID. Standard fields (status, priority, etc.) are unaffected.
• Made 1 schema/data change (1 possible breaking change):

  Data Model	Change type	Old	New	Notes
  stg_zendesk__ticket_custom_field	New staging model			Definitions for custom ticket fields, including their title and type. To disable, set the using_ticket_custom_field variable to False.

August 2026

We've updated the following quickstart data model packages to add DuckDB as a supported destination:

June 2026

v1.7.0

Under the Hood

• Migrates the union_connections, apply_source_relation, and partition_by_source_relation macros to the dbt_fivetran_utils package.
• Adds the fivetran_using_source_casing variable for case-sensitive destination support. When enabled, downstream transformations respect source casing to ensure consistent results. See the Additional Configurations section of the README for details.

v1.6.1

Schema/Data Change

1 total change • 1 possible breaking change

Feature Enhancement

• Updates SLA models to use historical priority levels when applying SLA targets. SLA events now reference the priority that was in effect at the time the event occurred, rather than the current priority. This ensures tickets with priority changes over time receive accurate SLA target calculations.

Bug Fix

• Ensures first reply time records in zendesk__sla_policies use the proper schedule when calculating elapsed business minutes.
• Ensures the proper priority SLA target is used in cases where the priority was changed immediately after ticket creation.

May 2026

v1.6.0

Schema/Data Changes

3 total changes • 3 possible breaking changes

March 2026

v1.5.1

Bug Fix

• Fixes non-deterministic SLA reply time calculations in int_zendesk__reply_time_business_hours and int_zendesk__reply_time_combined for tickets with multiple SLA policies. Previously, lapsed_business_minutes and breach calculations mixed results across policies when the same ticket_id, metric, and sla_applied_at had more than one sla_policy_name. Window functions now partition by sla_policy_name to correctly isolate each policy's calculation.

v1.5.0

Schema/Data Change

4 total changes • 2 possible breaking changes

Under the Hood

• Replaces reference to stg_zendesk__user with int_zendesk__user_aggregates in zendesk__ticket_summary to better align with dbt best practices and reduce DAG complexity.

v1.4.1

Documentation

• Removed documentation from zendesk.yml for dynamic columns from zendesk__ticket_field_history and zendesk__ticket_backlog to prevent persist_docs errors when these columns are not present.

v1.4.0

Schema Changes

5 total changes • 0 possible breaking changes

Feature Update

• Adds support for the sla_policy_metric_history and ticket_sla_policy source tables to enable more granular SLA policy tracking based on ticket priority levels.
  • These new tables are dynamically enabled in Fivetran Quickstart based on whether they are being actively synced. For dbt Core users, the tables are enabled by default but can be disabled with the following configuration in your dbt_project.yml:

vars:
  using_sla_policy_metric_history: false
  using_ticket_sla_policy: false

• Adjusts SLA policy logic to use the current ticket priority level's targets for calculating metrics. Previously, targets were taken from the priority that a ticket was first assigned to.

Bug Fixes

• Updates Snowflake regex parsing in the extract_schedule_day() macro.
• Aligns with Zendesk's method of calculating agent replies and comment metrics for messaging/chat. Previously, we counted each individual chat message as a distinct comment. In accordance with Zendesk's docs, we now count active conversation sessions.
  • For example, if an agent sends three messages in the same active conversation and then the conversation ends, that exchange counts as one Agent reply. Previously, we would have counted three replies.

February 2026

v1.3.1

Documentation

• Updates the instructions for running the package on unioned data sources and integrating source tables into your project's DAG.

Bug Fix

• Aligns the audit_log DAG inclusion logic with other source tables to avoid failures during docs generation.

January 2026

v1.3.0

Documentation

• Updates README with standardized Fivetran formatting.
• Removes duplicative column yml definitions.

Under the Hood

• In the quickstart.yml file:
  • Adds table_variables for relevant sources to prevent missing sources from blocking downstream Quickstart models.
  • Adds supported_vars for Quickstart UI customization.

v1.2.1

Feature Update

• Introduces the max_ticket_length_weeks variable. This variable defines the maximum length of time, in weeks, that the package expects a ticket to be open for business hour calculations and SLA policy computations.
  • The default value is 52 weeks (one year)
  • If your organization has tickets that are open for more than a year, apply the following configuration in your root dbt_project.yml file:

### dbt_project.yml
vars:
  zendesk:
    max_ticket_length_weeks: 208 # Integer value: Ensure this is >= the longest period a ticket was open (in weeks)

October 2025

v1.1.0

Schema Changes

4 total changes • 0 possible breaking changes

Feature Update

• Materializes the above intermediate models as tables so as to optimize runs of zendesk__ticket_metrics and avoid potential timeout issues. (PR #216)
  • If you would like to maintain the ephemeral materialization of these models and are running the Zendesk package via dbt Core, add the following configuration to your dbt_project.yml:

models:
  zendesk:
    agent_work_time:
      int_zendesk__ticket_work_time_business:
        +materialized: ephemeral
    reply_times:
      int_zendesk__ticket_first_reply_time_business:
        +materialized: ephemeral
    resolution_times:
      int_zendesk__ticket_full_resolution_time_business:
        +materialized: ephemeral
      int_zendesk__ticket_first_resolution_time_business:
        +materialized: ephemeral

Bug Fixes

• Removes a filter in int_zendesk__updates that was erroneously filtering out some first reply messages. This filter was intended to remove "batched" chat messages stored in the TICKET_COMMENT table, but the filter is unnecessary (and in some cases problematic) for properly calculating downstream SLA metrics. (PR #216)
• Creates the partition_by_source_relation() macro to dynamically include source_relation in the partition clauses of all window functions based on whether multiple Zendesk sources are being used. Previously, Redshift users running the package on one Zendesk connection may have encountered constant expression errors due to source_relation containing the same value across all records. (PR #219)
• Updates the logic in int_zendesk__schedule_spine to accommodate 24/7 schedules. Previously, tickets with 24/7 schedules may have experienced gaps in business time metrics. (PR #218)
• Updates calculations of sla_breach_at from the minute to second level to avoid potential rounding errors that may have caused discrepancies between Zendesk data models and UI reports. This adjustment has been made in the following intermediate models (PR #217):
  • int_zendesk__agent_work_time_business_hours
  • int_zendesk__agent_work_time_calendar_hours
  • int_zendesk__reply_time_business_hours
  • int_zendesk__reply_time_calendar_hours
  • int_zendesk__requester_wait_time_business_hours
  • int_zendesk__requester_wait_time_calendar_hours

Documentation

• Renders a sample SLA Policy report from the Zendesk Streamlit App in the README. (PR #220)

September 2025

v1.0.1

Bug Fixes

• Fixed uniqueness issue in int_zendesk__user_role_history by removing duplicate and erroneous logs with identical timestamps.