Outbound Sync branching

Outbound syncs have more complex branching needs than inbound syncs. This is because:

1. There are a lot of different environment patterns to support

2. Changing the configuration of a sync can result in complex downstream changes in the behaviour of an app, so there's typically more risk involved

Let's look at the first point in more detail.

Supported environment patterns

Keeping in mind that the main branch is always production, there are a number of ways you can configure a branch.

Different Connection

This is the ideal situation, where you have pristine environment separation. Your branch is pushing data to an entirely different instance of the application, so naturally it has its own Connection.

For most applications, this means that the sync state can be re-initialised.

Choosing Start Empty as the branch record state behaviour means that all records will be resynced from the beginning.

Alternatively if you don't want to fully repopulate the environment, you can choose Fork and ignore current records as the branch record state behaviour. The sync will continue where it left off in production and handle all new records, but updates/deletes to existing records will be ignored.

Finally, some Apps do provide a copy of production data in a non-production environment. If that's the case, So choosing Fork as the branch record state behaviour will cause the branch sync to pick up where the main sync left off and minimise the amount of changes to process.

Shouldn't this be the only pattern?

Ideally yes, but not every App offers non-production environments. So in many real-world cases, the production environment is the only environment you have. We could have just blamed those vendors for not giving you development environments, but we'd rather be pragmatic and help you move the needle on change management with what you've been given. Managing your risks with the best guardrails available is better than not doing anything at all.

Same Connection, different location

Sometimes changes are tested in some other corner of the same environment. For example, you might have a separate Slack channel for testing messages to a limited audience, but it's part of the same Slack Organization. Similarly in Salesforce Marketing Cloud, it's common to use alternate Data Extensions for test data.

To support this pattern, we allow sync parameter changes to be marked as "Branch-only" - in other words, they only exist to divert traffic and aren't part of the change.

Branch-only sync parameters will be remembered for future branches with the same name. This allows for this type of testing to occur in a repeatable way.

With the branch record state behaviour, you have the same options as above.

Same Connection, same location, specific records

This is known commonly as "testing in production" or "yolo", where your branch is applying records to exactly the same location as main.

The challenge here is that you have two sync configurations with a difference in opinion about how the same records in the app should look. For example, say you add a new field in the branch, and a source record is updated. Both the main sync and the branch will want to update the record next time they run, so it'll depend on the run order as to which change survives.

We resolve this with the only trick left in the bag, which is the Share branch record state behaviour. When you choose this option, you have to also nominate a branch record filter to determine which records are handled exclusively by the branch sync.

For example, an app might have a Customer object named Dummy Customer, which by convention is not a real customer. We add its identifier (e.g. "00000001") to the list of branch-owned records when creating the branch, and we modify the record in Snowflake.

When the main sync runs, it will ignore the change and do nothing, because the record is owned by a branch.

When the branch sync runs, it will pick up the change (and ignore all other records) and apply it to the app, using the new branch configuration.

When the branch is merged, the updated record state will be merged into the main sync so that it knows about the change, and won't attempt to apply it again.