Overall process

Inbound syncing involves less configuration complexity than outbound, since you don't need to define exactly how the data is received by the app. Instead it's pretty simple - you get a Snowflake table per object from the app. For this reason, and to avoid you needing to configure lots of syncs, each sync can support any syncing number of inbound objects from the app.

In keeping with established industry naming conventions, each object within an inbound sync is called a "stream", and each one will have a table per branch of the sync (and the "main" branch).

Inbound strategies

Inbound syncs can operate in one of two strategies:

Full - All data is reloaded every sync

Incremental - Using a watermark, only new changes are pulled

With both strategies, a local table is nominated and created automatically, with all of the available fields for the selected app object.

Inbound storage behaviours

Storage behaviours determine how the fetched data is stored in Snowflake, considering existing sync'd data.

The Full strategy has two behaviours:

  • Replace - The latest copy of the full set of records replaces the existing records

  • Append - The latest copy of the full set of records is added to the existing set of records. Note that this will create duplicates of existing records.

The Incremental strategy has two behaviours:

  • Merge - The new records are matched up to existing records with the same primary key, or inserted if there is no match.

  • Append - The new records are added to the existing set of records. Note that this will result in multiple records with the same primary key.

Records which have already been sync'd previously will have their fields updated by merging on the Primary Key.

Alternatively you can choose to enable Append mode. This means that instead of updating existing records, they will be appended so that you see the full history of changes.

Last updated