Omnata's sync config branching mode has been thoroughly redesigned in the new UI.

We have made branching concepts more clear and easier to use, plus refined the branching types to be more guided instead of freestyle. This ensures users don't end up with incompatible combinations of changes, and more quickly enables the most common testing scenarios.

What is branching?

To start, what even is branching. In software, Branching is a version control feature that creates separate, parallel lines of development from a main codebase. It allows developers to work on different features, experiments, or bug fixes in isolation without affecting the stable main branch. Each branch maintains its own history of changes and can be merged back into the main codebase once the work is complete and tested. This enables multiple developers to collaborate simultaneously while maintaining code stability and providing a clear development workflow for managing changes.

In the context of Omnata, we're not concerned with multiple developers working on the same code as being able to test changes to a production data pipeline before making a change, and making the change without clicking through a config wizard.

Why do I need it?

Data pipelines inherently have many downstream dependencies, and so robust change management is key. You don't want to break something that people are relying on.

Branching is most important for outbound syncs (or Reverse ETL) from Snowflake to a target system. This is because writing records has a lot more variability and potentially more severe implications in the case of an error.

On the other hand, when ingesting data to Snowflake, or reading records, you're not making any changes to existing records or deleting anything. So, it's inherently less risky.

Common branching use cases for data syncs

Fully separate test and prod environments

This is the most pure form of branching. You have full freedom to test and break whatever you want in the sandbox, and you can put the correct config into production. In the context of syncing data:

• Test and Prod instances are fully separate, but have the same object structure. The data may differ, PII is masked or financial data randomised, etc.

Testing in production

For many applications, you only get one environment, so changes are being applied directly to the production system.
This can be risky, so people make do with some testing workarounds:

• Try out some known test records, or small number of records, before syncing the 'real' records.

• Use test location in your production instance, like a test Slack channel, test object or some other logical segregation, before syncing with the 'real' object.

Omnata's branching modes

Omnata has branching modes to match the common testing scenarios above.

1. Multi-environment branching using fully segregated environments.

2. Single-environment branching via an alternate source of filtered records or alternate tables.

3. Single-environment branching by toggling target location.

Branching modes in detail

Multi-environment branching

When you specify that you have multiple environments, Omnata will default the sync config to enable branching. You can disable branching if you don't want to use it.

Inbound Syncs

Outbound syncs

Single-environment branching

Alternate source; alternate table

Use this when you've already created an alternate source table from the 'real' data, for example, you've limited the record count or applied a where clause.

Alternate source; filtered records

Use then when you have a small number of known test records that can be used for testing.

Single-environment branching; target location toggling

Use this when your target application has a test object, channel, folder or other segregation inside the production instance of the target app.

How to use branching in Omnata

Branching is built into the Omnata UI as a first-class concept. When you configure connections and syncs in Omnata, you can opt in to use branching features.

Creating a connection

When you create a connection, the first question is related to branching.
This is where you tell Omnata what kind of application environments you have and that will determine what type of branching options are available for syncs. If you get this wrong, don’t worry, you can always change it later.

As described above, Multi-Environment Branching is when you have fully segregated instances of your target endpoint for Dev, Test and Prod. Salesforce, for example, readily provide temporary sandboxes and permanent sandboxes to customers. 
So you will answer ‘Yes’, I have multiple environments of this app/database’, then, specify which one this connection is for; a sandbox or Prod.

Conversely, if you only have one environment, then you only have Production, and Omnata will present Single-environment branching options later on.

Creating a sync

Once you’ve created a connection and go to create a sync, Omnata will remind you about what that means for branching.

You can begin your configuration on either connection type. It is most prudent start on test, then merge to Prod. However, you can also configure straight to production too. Any changes you make from that production sync will be created as a branch.

Once the sync is created, a branching enabled sync home page will look different to non-branching one. You have two configs to toggle between, the branch and main, for the one sync. Within the branch, you can have multiple saved ‘branches’, but only one will be active at any one time.

On the left, you can see what type of branching is being used.
Since we have multiple environments, a Salesforce sandbox and prod instance, we can see the connection names that each branch points to. For this outbound sync, you can see the difference in source table between the two branches.

You can run a branch sync in the same way as a regular sync. It can have a schedule, or run manually,
The goal of running these branch syncs is to test the result, so run it as much as you need to get the config correct.

Merge to production

You have created your branch, tested it to your sandbox, and all is OK.
Now it’s time to merge the configuration to your main branch, and thus push data to your production environment.

Diff View (two below)
Shows you the differences between your Branch and Main. If this is the first merge, then everything will be different.
In the example below, this is an outbound sync, and we can see how the field mappings have been modified between the current main branch (in production) and this test branch (the proposed changes).

The lifecycle of branches

To help you visualise the process of branching, here are some different ways that you may move from test to branch and then make changes.

Create & re-open the same branch

This is the most common way to use branching. It uses one test branch to propose changes, and it is re-opened again later. This starts the new change from where the previous change left off, but pulls the latest prod state.

Create new branches for changes

This requires you to begin with a blank branch configuration for each change.

Create, abandon, re-open & rollback

Changes might go back and forth, and you might even break something. We've got you covered.