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

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!

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?

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

 

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.

 

Reply


Terms & Conditions