Skip to main content
Docs
Feature Requests Onboarding Trust Center Status Page

Community

Connector Improvement: Intercom: support non-history mode for the tables

Answered
Maxim Gashkov User

Currently most of the tables coming from Intercom connector are being synced in a pseudo-history mode where PK consists of id and updated_at fields, notable example being conversations_history table.

As we mostly do analytics on the current version of each conversation (and a lot of other entities like this) it makes querying the data warehouse extremely tedious. We would like to retain only the latest version of each row for all tables in the Intercom schema.

Is this something that is realistic to expect in the near future?

Please sign in to leave a comment.

Comments

2 comments

Date Votes
  • Official comment
    Ray User

    Hi Maxim,

    We don't plan to change these tables to non-history or to make these tables' historic natures optional, but we do plan to improve the schema such that the identification of the "active" versions of records is extremely easy. Please stay tuned and we'll have more to share in the coming months.

  • Clay Johns User
    • Edited

    THIS!

    Plus, we have noticed that Intercom has updated_at fields, and even if none of the actual data fields have changed, because that updated_at changed, Fivetran creates all new records for that object and all dependent objects.  So, for instance, contact triggers contact_company and contact_tag even though the ONLY change is on contact.updated_at.  If every contact has ~4 tags on average, just touching 1000 contact records without actually changing them creates 1k+1k+4k=6k records.  If you do that 4x per day, thats 6x4=24,000 records per 1k contacts per day.

    Just that one contact_tag_history table accounts for 10% of our MAR last month and Intercom is a "nice-to-have" not even a primary connector.  And 99.99% of it is useless data.

    Why is this connector history-only anyway?  I hate the chatty hubspot connector, but at least it has BOTH the standard "current" table AND a history table and you can choose not to keep the history.  Same with the postgres connector.  We *want* to see the contact tags, but not for an extra 1MM MAR/month.

    Now, I can kind-of see creating new contact entries because of the updated_at change, but completely recreating all dependent objects simply because of that is wasteful.

    Also, I love {slight sarcasm} that a full year later after "please stay tuned" that hasn't happened and the only change is that Fivetran finally started using a newer version of Intercom's API and including newer fields after being 2+ years behind.