Why two-way sync breaks between contract tools and PSA platforms
Why two-way sync breaks between contract tools and PSA platforms
Key takeaways
- "Two-way sync" between a contract tool and a PSA usually turns out to be a handful of one-way flows. Ask which record moves, in which direction, and what starts it.
- A signed agreement should change by amendment. If a PSA edit can rewrite a signed SOW, the integration has broken the contract, whatever its marketing page says.
- XClause connects to ConnectWise PSA, Autotask, HaloPSA and SuperOps on Pro and above. It reads clients and contacts from all four, and ConnectWise PSA, Autotask and HaloPSA can also receive clients created in XClause. Contracts only go out, and no PSA receives invoices.
- XClause reads device counts from NinjaOne and SuperOps and never pushes counts back. It doesn't connect to Datto RMM, N-able, Kaseya VSA or Syncro.
The record on each side isn't the same record
A PSA agreement and a signed contract describe the same deal, and they are built for different jobs. The PSA agreement is an operating record: what gets billed each month, which tickets are covered, how many hours are left in the block. The contract records what the client agreed to. Scope, rates, term, notice period, and who signed on which date.
Sync assumes the two map field for field. Mostly they don't. There's nowhere sensible in a PSA agreement for a limitation-of-liability clause, and a signed SOW has no business knowing which ticket used up the last hours of a block. So "two-way sync" shrinks to the few fields that exist on both sides, and the vendor has to decide which side wins for each one. That decision is the integration. The arrows on the diagram are decoration.
A signed document should only change by amendment
Most integration pages skip this part. Say a tech adds three workstations for a client in the PSA, and the integration syncs both ways. If that change flows back and rewrites the device count on the signed SOW, the document no longer matches what the client signed. Your billing might now be right and your contract wrong. That's the worst version of the problem, because the PDF with the signatures on it says something different from the system everyone works in.
The change should travel the other way round. The new count shows up as a gap between what the client has and what the agreement covers. Someone amends the agreement, the client signs the amendment, and billing follows the new version. It's slower than a sync, on purpose, and it is the only order in which the contract stays true.
One field, one owner
When two systems can both write the same field, the last write wins, and nobody notices until a rate reverts or a client name changes back overnight.
The fix is dull. Give every field one owner. Device counts belong to the RMM. Tickets and time belong to the PSA. Rates, terms and signatures belong to the contract. Each system reads the fields it doesn't own and writes only the ones it does. An integration built that way is really several one-way syncs pointed in different directions, and that is fine. It's what you want.
Polling isn't real time
Most contract-to-PSA integrations, XClause included, don't hear about a change the moment it happens. They ask on a schedule, or when someone presses a button, and between runs the two systems disagree.
XClause has no webhooks from PSA or RMM platforms. NinjaOne device counts refresh every 6 hours and whenever you press Sync all. ConnectWise, Autotask and SuperOps refresh when you press Sync, and ConnectWise agreement additions are also read nightly. Writes going the other way, like a device change pushed to SuperOps or a HaloPSA opportunity, happen when you save or create the contract. If a vendor tells you their sync is real time, ask what triggers it.
Product mapping drifts
Quantity sync depends on a map that says this line on the contract is that product in the PSA. Maps go stale. Someone renames a product, retires a SKU, or builds a new bundle for one client, and the mapped line quietly stops updating. A good integration makes an unmapped line visible. A weak one skips it and reports success.
What XClause actually syncs with each PSA
All four connect directly through the PSA's own API, with no middleware in between. They're included on Pro and above, and not on Starter.
| PSA | Comes into XClause | Goes out from XClause |
|---|---|---|
| ConnectWise PSA | Companies, contacts, agreement additions | New clients (linked instead if ConnectWise has one company with the same name); managed unit counts on agreement additions, off by default and only after you map products |
| Autotask | Companies and contacts | New clients, and device changes you make in XClause |
| HaloPSA | Clients and contacts | The client, plus one opportunity or quotation per contract, closed when the MSA and SOW are both signed |
| SuperOps | Clients and managed devices | Device changes you make in XClause |
Two things never go to a PSA. The first is an invoice. When you switch on invoice sync, invoices go to QuickBooks Online, Xero or FreshBooks instead. The second is the signed document. The executed PDF, its certificate of completion and the renewal reminders stay in XClause, on the agreement. HaloPSA's opportunity does carry the contract's start and end dates as text, and XClause doesn't update them when the agreement renews.
Nothing you change in a PSA edits an XClause contract either. If a client's device count grows, XClause shows the gap against the agreement, and the fix is an amendment the client signs.
RMM: counts in, nothing back
XClause reads device counts from two RMMs. NinjaOne is read every 6 hours and on demand, and XClause never writes anything to it. SuperOps, a PSA and an RMM in one, is read when you press Sync now, and a device you add or edit in XClause is updated in SuperOps as well. The counts come in so XClause can compare what a client actually has against what their agreement covers.
XClause doesn't connect to Datto RMM, N-able, Kaseya VSA or Syncro today. If one of those runs your fleet, the device counts would have to reach XClause some other way, usually through your PSA.
Five questions for any vendor's "two-way sync"
- Which records? Clients, contacts, agreements, line items, invoices. Get the actual list.
- Which direction for each one? Both ways for clients and out-only for contracts is a reasonable design, as long as you know that's what you're buying.
- What starts a sync? A webhook, a schedule or a button. Ask how stale the data can get between runs.
- Who wins a conflict? If both sides change the same field, which value survives, and does anyone find out?
- What happens to a signed document when the PSA changes? The right answer is that it doesn't change. A new version gets signed instead.
If your agreements are flat monthly fees that never move, a one-way push of clients and a calendar reminder may be all you need. This starts to matter once agreements carry per-unit pricing, device counts move every month, and someone has to explain why the PSA and the signed SOW disagree.