Currently I’m developing the OpsHub Integration Manager tool for supporting the HubSpot connector to sync the Tickets entity from the HubSpot to other systems like Jira, ServiceNow etc.
Now the issue I’m facing is, earlier some internal updates are done by the HubSpot processes leading to the change in Last modified time of the Ticket entity, even after the last update done by a user or via API. (Which is a known behaviour).
But recently from the last 12th November 2025, there is one source type - Conversations which is making some updates continuously after the update done by API.
Here is the property history screenshot for my current Ticket entity.
NOTE : Now here the first 3 updates are done by me later on using API source - Aloof-Jelly ( app name) so ignore those changes.
So, here we can see that after the entity is created using the API the Last Closed date is set using the API source, and then after that, the last modified date is updated by the source - Conversations.
Currently, in my integration tool, I’m filtering the updates done on a particular entity using the source type. And ignoring all such changes done by the source type is API i.e. my Application.
But since here the last update is not done by API, this entity gets synced to the other system, even if it was not required to sync.
Therefore want to ask that, is there any recent updates made in HubSpot’s Tickets entity leading to this behavior. And how to avoid such unwanted source’s updates.
I am unsure of any recent platform changes, but one thing that you could do instead of filtering based on that is have your integration create a custom behavioral event as well when it happens. Example it could be that the integration ticket is updated, and include the relevant properties in the custom event. You can then use the event as your sync filter to avoid any system changes.
Let me know if this helps, or if you have any other questions!
Was I able to help answer your question? Help the community by marking it as a solution.
Adding more clarity on how the custom behavioral event approach works and why it solves the issue you’re running into with Conversations updating tickets in the background.
When Conversations updates a ticket, it still increments hs_lastmodifieddate even when no meaningful ticket field has actually changed. Because your current sync logic reacts to any non API change, these internal updates trigger unwanted syncs. A custom behavioral event gives you a clean, intentional signal. Only changes that you decide are sync worthy will generate this event, so Conversations related updates never trigger your integration.
Here’s how you can implement this is to define a custom behavioral event associated with the Ticket object. This event might be named ops_ticket_sync_candidate and include event properties such as external_system, sync_action, ticket_status, ticket_priority, or anything else you want to log at the moment the event fires. This event becomes the only indicator your integration listens for.
Let me know if this helps, or if you have any other questions!
Was I able to help answer your question? Help the community by marking it as a solution.
Thanks @BrandonWoodruff , for your solution, want to know that the field ops_ticket_sync_candidate will be custom field, but how can I update this field’s value based on any changes, like is there any worklflow or webhook needed to be attached to it?
Also, currently this type of change might require a new design level implementation in my current product. So, apart from this want to understand that, is this Conversations’ updates are recently introduced or not, as earlier this was working correctly.
And if it is there then how can I resolve this quickly.
Thanks,
Aniket.
What you’re seeing with Conversations touching the ticket after your API write isn’t new in concept, but the cadence definitely changed this quarter. Conversations now updates a few internal fields whenever a thread is linked or re-evaluated, and that increments hs_lastmodifieddate even if nothing user-visible changed. HubSpot documents how these system changes behave in property history and why they still count as updates in workflows or integrations (Create and edit properties )
If you need a near-term fix without redesigning your sync layer, the quickest approach is to filter for what changed, not who changed it. In a ticket-based workflow, you can compare current values against prior values or use re-enrollment rules to scope updates you actually care about
That gives you a stable way to ignore background modifications from Conversations until you’re ready to adopt Brandon’s event-based pattern.
A quick question on your integration. Do you also need Jira or ServiceNow to push updates back into the same ticket later? If so, Stacksync keeps those two-way updates consistent and shields you from these internal HubSpot touches, since only meaningful field changes propagate. Hope this helps.
Was I able to help answer your question? Help the community by marking it as a solution.
