Stateful sync is vital for RevOps and data teams to succeed. It is also a complex concept, so we’ll break it down with an analogy.
How to Understand Stateful Sync: The Chess Analogy
Imagine playing a game of chess with a friend online.
You make a move on your computer, the board updates on your friend’s computer, and vice versa. It’s like you’re playing from the same physical board. If you need to step away, the state of the board is maintained. You can pick up right where you left off when you come back. In software terms, this is a stateful application.
Now imagine if the application did not maintain the state of the game.
You make a move. Your friend can’t see it on her board because there’s no “shared state.” So, you text her “knight to f3.” She reads your message, updates her board, then sends you her move “knight to f6,” and so on. You are both playing from your boards and communicating changes back and forth. If your dog knocks your board over, you’ll have to go back to the beginning and repeat every move to regain the last shared state. In software terms, this is a stateless application.
Stateful vs. stateless sync
To “sync” data between two applications is more than moving data from A to B. iPaaS tools like Zapier, Workato, and SnapLogic simply copy fields or records and paste them into destinations. This stateless approach is unaware of changes in the “source” or “origin” system. Because changes frequently happen after this data movement has occurred, and you can’t build triggers for every single field or change type, you end up with a mess… in two places. ETL and reverse ETL have the same problem, just with different jargon.
Stateful sync, on the hand, is the ongoing management of data in multiple locations so that you can identify first-party records, govern data authority, manage deletes, and apply universal deduplication and merge programs.
What are stateless integrations good for?
Stateless applications are suitable for many things, just not for unifying and synchronizing customer data across your GTM stack. Unfortunately, that’s precisely where we’re using them.
Here’s a real-world example of where stateless apps go wrong:
Last week, the stateless Hubspot <> Salesforce integration went down. No data flowed between these two systems during the 36 hours of downtime.
Hubspot claims there was no data loss, but that’s not the point. Any new data that emerged didn’t move from system to system. Because both systems changed independently during those 36 hours – it’s going to be impractical to get them fully back in sync.
It’s the equivalent of a dog knocking over your chess board AND your friend playing on without you. You can try to repeat all the moves (e.g., your business processes) on new data to get things back to a shared state, but the game will never be the same.
That sucks for your employees and your customers.
Making matters worse, this is just one of the stateless integrations in your tech stack. You probably have tens, if not hundreds, of these things moving data between your business systems. And you wonder why your customer data is such a mess?
So, why are integrations stateless?
Because maintaining the state of customer data across two or more systems has historically been a complex and costly problem to solve, specifically at scale. It requires a data store, a data model that adapts to constant change, and an engine that makes every system speak the same data language and behave the same way – no matter the protocol or interface.
It isn’t out-of-reach or prohibitively expensive anymore.
Syncari solved this problem in a way that’s so novel it’s patent-protected.
We applied over 40 years of collective experience in making data consistent and accessible across systems to create a stateful, multi-directional sync engine that connects to any business system or data source. And we built a no-code UX for business technologists.
Our customers keep data in stateful sync across every stage of the customer journey, from leads to renewals and back. And they’re doing it for $5k a month.
The result:
- Happier customers
- Durable growth
- Lower costs
Check out our customer stories or request a demo to see it in action.
So, to recap:
The four core features of stateful sync:
Sync is a very misused term. Merely moving data from point A to point B is not sync. Typical issues when syncing data across multiple systems:
- Record Identity. When keeping 3 or more systems in sync with each other, records from different systems must be stitched together using a universal id – stateless integrations and point-to-point connectors don’t have this.
- Data Authority. With stateless integrations, the system that has the native connector defines rules on who is authoritative, without providing the users any control on this (eg: Marketo says all fields of leads are owned by Marketo, and all fields of contact are owned by Salesforce – real world requires more fine grained control). Point-to-point API integration tools don’t even offer this concept.
- Data Management, especially for deletion. When multiple systems are connected to each other, what happens if a record is deleted in system A? Do you auto-delete them in systems B & C, or simply keep them disconnected from each other? Or allow deletes to propagate only from certain systems? This is a very hard issue to solve and the user is again at the mercy of whatever the native connector decides, or be left with incongruent data across systems.
- Universal Deduplication & Merge. What happens if system A supports merges, and system B doesn’t support merges? What if the merge capabilities in one system are radically different from the other connected system? Look at how Hubspot merges records and how Marketo merges (or not). What happens when you want to propagate the results of a merge on accounts to Netsuite? Things become pretty hairy and inconsistent and you again end up with inconsistent data across systems, without even knowing why.
