Closed tickets that keep reopening are frustrating. They're also the kind of thing that gets blamed on the sync, often unfairly. This week's customer insight video from Steve looks at a real case where the culprit was an existing Jira automation rule, not the Support Fusion sync at all.
The customer noticed that tickets closed in one system were being reopened after the sync ran. Because the sync was the newest thing in their environment, it was the obvious suspect. But when the team dug in, the picture was different.
Jira Service Management ships with a set of default automation rules out of the box. One of them is designed to reopen a ticket when a customer replies to a resolved issue. That makes sense in isolation. The problem is that when the Support Fusion sync updates a ticket, it does so as a system user. That update was triggering the automation rule, which then reopened the ticket. From the outside, it looked like the sync was the cause. Underneath, it was two legitimate processes stepping on each other.
This kind of conflict isn't unique to Jira. Plenty of PSA and ITSM tools have automation built in, whether it's Autotask, HaloPSA, ConnectWise Manage, or ServiceNow. Some of those rules ship as defaults and get forgotten about. Others are custom-built by the team over years. When you add a two-way sync to an environment like that, you're introducing a new actor into a system that wasn't designed with the sync in mind.
In this case, the team worked with the customer to map what the sync was doing against what the automation rule expected. A small adjustment resolved the conflict. No data was lost. Tickets stopped reopening.
But the more useful outcome was the process change. The team now spends more time during the onboarding phase understanding what existing automation is in place before the sync goes live. That means looking at:
This isn't a new category of problem. Any time you add a new integration to an existing environment, you're adding a new variable. The difference with ticket syncing is that the interactions can be subtle. A rule that triggers on a field update might not cause any issues in day-to-day use, but behaves unexpectedly when a sync writes to that same field programmatically.
The good news is that these conflicts are identifiable and fixable once you know to look for them. Most of the time, the resolution is a small configuration change, either in the automation rule or in how the sync behaves for a particular field. The key is catching them before they surface as support issues rather than after.
If you're setting up a ticket sync, or about to add Support Fusion to an environment that already has automation in place, it's worth doing a quick audit before the connection goes live:
This kind of pre-flight check adds a bit of time to onboarding. It saves considerably more time in troubleshooting afterward.
The Support Fusion team works through this as part of the onboarding process for every new connection. If you're evaluating a sync for your environment, or you're already live and seeing unexpected behaviour, it's worth having a conversation about what automations might be in play.
Find out more at suppfusion.com