Multiple conversation_updated_at for same tag_id and conversation_id in conversation_tag_history table | Community
Skip to main content
Answered

Multiple conversation_updated_at for same tag_id and conversation_id in conversation_tag_history table

  • March 26, 2025
  • 3 replies
  • 171 views
U
Forum|alt.badge.img+1

Hello,

When I query the conversation_tag_history table, I noticed there can be multiple conversation_updated_at values for the same tag_id and conversation_id.
Usually the MIN(conversation_updated_at) value is accurate, but I wonder how this can be the case?
It happens frequently so I don’t think it’s because someone is removing a tag and adding it again, but I can be mistaken.

Thanks in advance!

Best answer by Paul B12

Hi ​@User2149 Paul here from weekend support engineering to help you out 🤝 

Since you're accessing conversation_tag_history via the Fivetran Intercom connector, what you're seeing likely reflects the underlying tag change log stored in Intercom’s internal event stream. It's expected to see multiple conversation_updated_at entries for the same conversation_id and tag_id, especially if the tag was modified (e.g. reapplied, or touched via API or workflow logic) without being fully removed.

In most cases:

  • The earliest timestamp (MIN(conversation_updated_at)) indicates when the tag was first applied

  • Later timestamps may result from internal updates, reapplications, or data sync noise that Fivetran captures but Intercom’s UI doesn’t show explicitly

You're not mistaken to assume users may not be manually adding/removing tags each time it could also be triggered by:

  • automated workflows

  • API calls

  • support teammate actions

  • or even backend reprocessing of conversation metadata

If you're trying to extract first-time tag usage for a conversation, your approach using MIN() is correct.

 

Levi Martens

3 replies

Paul D
Intercom Team
Forum|alt.badge.img+2
  • Paul DIntercom Team
  • Intercom Team
  • 88 replies
  • June 12, 2025

Hi ​@User2149 - Could you please share more details on where you are finding the conversation_tag_history table? Are you retrieving an individual conversation via the API?

Paul | Technical Support Engineer
U
Forum|alt.badge.img+1
  • User2149
  • Author
  • Active User
  • 16 replies
  • June 13, 2025

It’s surfaced through a regular ETL tool, in our case Fivetran. We’re using the Intercom connector inside Fivetran.

 

Levi Martens
Paul Byrne
Intercom Team
Forum|alt.badge.img+6
  • Paul ByrneIntercom Team
  • Intercom Team
  • 118 replies
  • Answer
  • June 15, 2025

Hi ​@User2149 Paul here from weekend support engineering to help you out 🤝 

Since you're accessing conversation_tag_history via the Fivetran Intercom connector, what you're seeing likely reflects the underlying tag change log stored in Intercom’s internal event stream. It's expected to see multiple conversation_updated_at entries for the same conversation_id and tag_id, especially if the tag was modified (e.g. reapplied, or touched via API or workflow logic) without being fully removed.

In most cases:

  • The earliest timestamp (MIN(conversation_updated_at)) indicates when the tag was first applied

  • Later timestamps may result from internal updates, reapplications, or data sync noise that Fivetran captures but Intercom’s UI doesn’t show explicitly

You're not mistaken to assume users may not be manually adding/removing tags each time it could also be triggered by:

  • automated workflows

  • API calls

  • support teammate actions

  • or even backend reprocessing of conversation metadata

If you're trying to extract first-time tag usage for a conversation, your approach using MIN() is correct.

 


Terms & ConditionsAccessibility statement