Every ticketing integration makes a trade-off you might not notice until it matters. A ticket lands in your source system at 10:31. A comment is added at 10:32. Your sync runs at 10:34. And unless something explicitly preserves those original times, the integration stamps everything with 10:34.
For low-stakes environments, that two-minute gap is irrelevant. But when you're operating under SLA commitments, that gap is the difference between a compliant response and a breach on paper.
Integrations work by polling or listening for changes, then replicating them into the destination platform. The ticket creation event and the replication event are two different moments in time. Most integrations, by default, record when the ticket arrived in the destination, not when it was originally raised.
This creates a distorted record. Reporting pulls from the destination system and shows a ticket opened at 10:34, when the end user actually submitted it at 10:31. At scale, across dozens or hundreds of tickets per day, those discrepancies compound. Response time metrics drift. SLA reporting becomes unreliable. And when a client queries a breach, you're defending numbers you know aren't accurate.
The same issue applies at the comment level. A technician adds a note at 10:32 to request escalation. The sync records it at 10:34. In the destination system, the audit trail no longer reflects the actual sequence of events.
SLA management depends on clean timestamps. If your ticketing integration is the layer between your PSA and your client's ITSM platform, the integrity of that data layer determines the integrity of everything built on top of it.
This is particularly relevant for MSPs and IT service providers working across platforms like Service Desk Plus and Halo PSA, where the source system is capturing the client's experience in real time, and the destination system is where your team operates, reports, and invoices from.
When those two records tell different stories about when things happened, reconciling them is a manual and time-consuming process. And in SLA disputes, the burden of proof sits with the provider.
Support Fusion has added timestamp preservation to the Halo PSA connector. When enabled, the original creation date and time for each ticket and each comment is carried through the sync and recorded accurately in the destination system.
That means a ticket raised at 10:31 is recorded at 10:31 in Halo PSA, regardless of when the sync ran. Comments are treated the same way. The record in your destination platform reflects what actually happened, not when the integration processed it.
In addition to timestamps, comment ownership is now mapped to the correct field in Halo PSA. This means the technician or end user who added a comment is properly attributed in the destination system, improving both the technician experience and the accuracy of your reporting data.
Not every environment needs this. Some integrations are set up for data aggregation rather than client-facing SLA management. Others may already handle timestamps differently at the source. Forcing timestamp preservation across the board would create problems for those configurations.
That's why this is opt-in. A single toggle in your Halo connector integration settings enables or disables timestamp preservation. You decide whether it fits your operation, and you can adjust it without touching anything else in the integration.
This reflects a broader principle in how Support Fusion is built: the platform handles the complexity of cross-system data transfer, but operational decisions stay with the team running the integration.
If you're running a Service Desk Plus to Halo PSA integration through Support Fusion, navigate to your integration settings on the Halo connector side. The timestamp preservation toggle is available there. Enable it, and original ticket and comment timestamps will be preserved from the next sync onwards.
If you have questions about whether this setting is right for your configuration, the Support Fusion team can help you assess it against your reporting and SLA requirements.