No More Data Ping-Pong — Thanks to Cross Updating Preventer (XUP)

Updated on 1st December 2025 by Susanna Fagerholm

Many integrations keep two systems aligned by sending updates from one to the other. This type of back‑and‑forth, bi‑directional sync can accidentally trigger an infinite loop. System A updates System B, which prompts System B to update System A, and so on. The result is noise in both apps and a rapid consumption of tasks. Cyclr’s Cross Updating Preventer, or XUP, helps break that loop. 

The Cross Updating Preventer makes sure that an inbound update in one system does not kick off an unnecessary one in another. Let’s explore how product and development teams can use it to reduce pointless writes, protect task usage, and keep data changes meaningful.

Cross Updating Preventer at a glance

XUP stores a snapshot of the set key fields of outgoing data, and then compares those same fields when data comes back in. The connector therefore has two exit points: True and False. 

If the values have not changed since the last time they were seen, XUP flags the event as not a real update. The Cycle can then exit on a “False” path and avoid calling the destination connector again.

XUP provides four methods that work in pairs across directions to decide whether a change is new or just a reflection of a prior update:

• Update OK (Outbound)
• Store Data (Outbound)
• Update OK (Inbound)
• Store Data (Inbound)

The Update OK methods compare mapped values against values stored by the opposite direction’s Store Data method. The Store Data methods save the values so the opposite direction can check them later.

How the Decision Works

Update OK (Outbound) checks the fields against values stored by Store Data (Inbound) by using a user-defined Common Key. If any value differs, the step exits through True and the update should continue. If all values match, it exits through False, signaling that nothing actually changed since the last time the record was seen.

Update OK (Inbound) performs the same comparison against values stored by Store Data (Outbound). Even though the methods are labeled inbound and outbound, each method in one cycle does not directly talk to its counterpart in the same cycle. Each Update OK method looks at data stored by the Store Data method in the opposite direction of travel.

Using the Cross Updating Preventer in 7 steps

1. Choose the main system.
   • Decide which of the two systems will be the ‘main’ one and be consistent. Treat updates leaving it as Outbound and updates returning to it as Inbound.
     
2. Install one Cross Updating Preventer per object type.
   • Keep each record type isolated. When guarding several kinds of records, install a separate Cross Updating Preventer connector for each type. For example, use separate connectors for Contacts and Leads.
   • Give each installation a clear name that describes the object type that it will be mapped for.
     
3. Decide the Common Key.
   • Pick a unique value that exists on both sides. For contacts, an email address often works.
   • If no shared unique value exists, build a concatenated key by combining each system’s unique ID with a divider, for example: [SystemA ID]_[SystemB ID]
   • Store each system’s ID on the other system’s record so the same key can be built in both directions.
     
4. Open the connector and select Setup.
   • Enter the field names as a comma-delimited list. Avoid special characters because these names become JSON property names. Setup creates fields in the correct locations and adds them to the Methods.
     
5. Place the four Methods in Cycles with the correct pairing.
   • Update OK (Outbound) compares against values saved by Store Data (Inbound).
   • Store Data (Outbound) saves values that Update OK (Inbound) will check later.
   • Update OK (Inbound) compares against values saved by Store Data (Outbound).
   • Store Data (Inbound) saves values that Update OK (Outbound) will check later.

6. Map consistently.
   • Map the Common Key and the same comparison fields on each paired Method. Normalize formats so comparisons are reliable.
   • Use script if needed, for example: trim whitespace, lower case email addresses, cast numbers, or round currency values.
     
7. Confirm the outcomes.
   • If any mapped value differs, the Update OK Step exits True and will continue to the destination update. If all values are the same, it exits False and stops the update.

Practical Example: QuickBooks and Shopify Items

Many two-way item or product synchronizations connect a system that manages the catalog, pricing, or inventory with a system that publishes or sells those items. In that setup, a change can bounce indefinitely: System A updates an item, System B picks it up and writes it back, and the loop starts. 

In our example, we treated QuickBooks as the main system (Outbound: QuickBooks → Shopify; Inbound: Shopify → QuickBooks). 

We laid out the two Cycles so each Update OK compares against the opposite Store Data:

• In the QuickBooks to Shopify Cycle, we placed Update OK (Outbound) before the Shopify update step, then ran Store Data (Outbound) after a successful write. 
• In the Shopify to QuickBooks Cycle, we placed Update OK (Inbound) before the QuickBooks update step, then ran Store Data (Inbound) after a successful write. 

A genuine change made in QuickBooks reaches Shopify once and is stored for comparison. When the same values try to return, Update OK (Inbound) compares them with what Store Data (Outbound) saved and blocks the echo. Real changes from Shopify still pass through, so the items stay synchronized without back-and-forth updates.

The returning update that simply mirrors the last outbound change is recognized and stopped. By preventing the cross‑update loop from forming, this keeps both systems synchronized, avoiding redundant transactions while still allowing genuine changes to pass through.

Watch the full walkthrough along with other examples of how Cyclr helps solve common integration problems:

Troubleshooting Tips for Cross Updating Preventer

• If the connector returns a repeated True when nothing has changed, confirm that the exact same fields are mapped on both sides of the pair and that formats are normalized in both directions. A stray space or a different number format will force a difference.
• If the connector returns False instead of an expected True, check that the changed field is part of the XUP field list and that the Common Key resolves to the same record in both systems.
• Keep one Cross Updating Preventer connector per object type. This avoids cross‑talk between unrelated data.
• When using concatenated keys, the string should be built exactly the same way everywhere. Use the same order, the same divider, and no extra spaces.

Configured this way, the Cross Updating Preventer removes cross‑update loops and keeps bi-directional syncs clean.

Conclusion

With a small amount of setup, the Cross Updating Preventer provides SaaS teams control over bi‑directional sync. It compares what is about to be sent with what was last received for the same record. If nothing has changed, it stops the loop. And if something has changed, it lets the update flow. The result is a cleaner audit trail, fewer unnecessary writes, and a more predictable task count.

These may also interest you…