The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
A one-way sync has a clear story: system A changes, system B follows. A two-way sync has a failure mode one-way syncs literally cannot have. The two directions can trigger each other.
Picture Zendesk tickets linked to Salesforce cases. An agent escalates, which writes a case in Salesforce. Engineering updates the case, which writes status back to the ticket. But that write to the ticket looks like any normal ticket change, so it can fire the escalation sync again, which updates the case, which syncs back to the ticket. Now both records are updating in a tight cycle. A runaway loop is worse than no integration at all.
Two controls stop it.
Actor exclusion: the integration writes through a dedicated user, and each side ignores changes made by that user. When the sync-back updates the ticket, the Zendesk trigger sees its own integration user and does nothing. You're telling each system not to react to itself.
Skip-unchanged guard: before propagating a change, compare the incoming value to what's already there. If nothing actually changed, stop. This catches the echoes that slip past actor exclusion, like a re-save that touches no real field.
The second hard problem is source of truth, and in a two-way sync it usually isn't one system. It's per field. Here, Zendesk owns the customer conversation and original context; Salesforce owns the engineering status and resolution. Neither owns the whole record. You decide ownership field by field, or the two directions quietly overwrite each other and call it a sync.
I wrote up the full design, including the status-mapping decisions between two systems that model status differently, as a spec and runbook below.
github.com
public-portfolio/03-salesforce-zendesk-case-escalation/case-escalation-spec.md at main · nodrel-dev/public-portfolio
Integration and systems documentation samples for SaaS ops teams — runbooks, specs, and architecture decision records, written from the codebase. - nodrel-dev/public-portfolio
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
The fix for an agent that keeps getting your design system wrong isn't a better prompt.
It's putting the rules where the agent reads them.
In the repo. In skills. In checks it can run itself.
Writing a course about exactly this.
What sells it for me is the refusal telling the agent exactly where the token should go. A bare "no hex" error usually just sends it looping. Does guard.mjs run only as an agent hook, or in pre-commit too so it catches humans as well?
Testing two color directions for Pilotly, an AI agent platform for product teams.
Which direction would you pick for an AI automation product?
3 voted
100%
0 voted
0%
3 votes
Closed
A website feels designed when every section follows the same rules.
For Vanaxity, our AI content engine, we kept it simple: one type family, the same spacing on every section, one button shape, and the same deep-space palette on desktop and mobile.
It holds across languages too. One switch, and the site reads in Vietnamese with the same layout.
That's how I like to work at Van Data Team: design the site, then build the agent behind it.
What's the first thing you check when a site starts to feel inconsistent?