Sync types and modes

When configuring a sync there are two key settings that determine the basic behavior of your sync:

• Sync type
• Sync mode

The options for both vary depending on the destination. Refer to the specific destination documentation for more information about its supported sync types and mdoes.

Sync types

The sync type refers to what you are syncing in a destination. These are the most common types:

• Objects: such as customers, accounts, organizations, catalog items, and the objects' associated attributes or metadata
• Events, Actions, and Activities: such as conversion events
• Segments, Audiences, and Lists, : such as subscription or campaign lists, specifically user membership in these lists

When syncing to CRM type destinations, it's commonly to object type records. When syncing to advertising or marketing platforms, it's commonly to objects, events, or lists.

For some destinations, you can also manage journeys, trigger campaigns, or merge anonymous and known users by syncing data. Check out a destination's dedicated docs to learn its supported sync types.

Sync modes

Depending on your sync type, you may have to select your sync mode. For example, if you're updating contacts, you might have the option to Insert, Update, or Upsert them.

Also called update mode, this configuration describes how you want to update records in your destination based on your model's query results. For example, if your model queries a Users table and rows in that table change, your sync mode determines how those changes should translate to your destination.

Depending on the destination and sync type, the supported sync modes could include:

• Update: only update existing records in your destination
• Insert: only insert new records without touching existing records
• Upsert: update existing records and insert new ones
• Add: add records, usually user records in a segment, list, or journey
• Remove: remove records, usually user records in a segment, list, or journey
• Archive: archive all records that appear in your model's query results (only for Mailchimp, Intercom, and Salesforce destinations)
• All: overwrites all existing records in your destination with the results of your model query; sometimes called Mirror mode
• Snapshot: creates a new file on each sync run with the full results set of your model query
• Diff: creates three new files on each sync run—one for rows added, one for rows changed, and another for rows removed since the last sync

Some sync types such as triggering campaigns, merging users, or sending messages don't require you to select a mode since the sync applies an action rather than updates records. Other sync types, such as events, have only one sync mode option.

Sync modes and change data capture

Change data capture (CDC) is a process that captures changes made to your source data and that records those changes. Specifically, CDC tracks rows that were added to, changed, or removed from your model's query results since the last sync run.

Your sync mode determines how Hightouch acts on observed changes:

• In update mode, Hightouch only acts on changes to existing rows.
• In insert mode, Hightouch only syncs new rows—those whose primary key wasn't present in the previous sync run.
• In upsert mode, Hightouch acts on existing and new rows rows.
• Archive and all modes don't perform change data capture and don't store requests in the live debugger.

Sync mode is separate from delete behavior, which determines how to treat removed rows—those that leave your model's query results.

Sync type and mode combinations

Certain destination types tend to support certain sync modes.

Check out Hightouch's integration catalog for a complete list of destinations and categories.

Event syncs

Event syncs are insert only, meaning that you can't update previously synced events or activities. Hightouch follows this convention because events tend to be part of fact tables rather than dimension tables. Fact tables store transactions as rows that shouldn't change.

Recall that in insert mode, Hightouch syncs rows whose primary key wasn't present in the previous sync run. If the event sync's associated model has a primary key that appears in multiple events—for example, user_id—syncs will omit some events.

To ensure syncs include all events, select a truly unique column, for example a unique eventID. If your events data doesn't contain an inherently unique column, define a composite primary key during model creation.