Branching
Omnata's git-style change management features
Branching for a sync can be opted into throughout the configuration process, depending on how you have configured your connections.
When to use branching
Branching can be use for both inbound and outbound syncs. However, branching is inherently more important for outbound syncs, since you are writing changes to the target endpoint.
On the other hand, branching for inbound syncs is less important as read operations don't materially affect data downstream.
There are two main branching modes:
Multi-environment; where you have separate test and prod instances of the target app or database. When you have multiple environments, branching will be enabled by default, but you can switch it off in the sync configuration.
Single-environment; where you only have one (assumed production) instance of the target app or database. When you have a single environments, branching can be switched on in the sync configuration.
For outbound syncs to single-environments, there are three testing patterns we support;
Alternate source via record filter You can select a small number of test records to push to the target app without creating a derived view or alernate source table.
Alternate source via different table You can select different source tables for test and main branches.
Alternate target location You can push data to a test area of your target endpoint like a folder, channel or dummy object.
For inbound syncs, we don't yet support single environment testing patterns, however, setting a start date based on a timestamp cursor fields is coming soon.
See more in the Branching docs, and read an Overview of Branching on our blog.
Last updated