Sync Overview

​

Overview

Sync lets you take the data mapping work you’ve built on one pipeline and move it into another — for example, from a test pipeline into your production pipeline — without rebuilding any of it by hand. A pipeline is a working copy of your data mapping configuration: the entities, the fields on them, where each field comes from, and how they relate to each other. Most firms keep more than one:

• A production pipeline (usually called main) that feeds real reporting.
• One or more test pipelines where new mapping work gets built and validated safely.

Sync solves the last mile. Once you’ve proven a change on a test pipeline, you need the same change in production — and redoing that work by hand is slow and easy to get wrong.

​

Key Terms

​

The Two Directions

Both directions are supported, and both are common:

• Test → main. You built something new on a test pipeline and you want it live.
• Main → test (Sync from main). Your test pipeline has drifted from production and you want to reset it before starting fresh work.

​

Two Scopes

Sync works at two scopes. They are not the same feature at different sizes — they differ in what they can add, what they can remove, and what they check. Start with single-entity sync when you want a surgical change and you know the entity isn’t entangled with others. Use whole-pipeline sync when entities are interrelated, or as your default when you’re syncing a body of work rather than one change.

​

Where to Find Sync

Log in to the Entegrata Admin Portal and open Data Pipelines from the left sidebar. You’ll land on a page listing your pipelines, split into production and test tables.

​

On an entity

Open a pipeline, then open a layer — for example Silver — and click the three-dot menu (⋮) on any entity row:

• Sync — copy just this entity into another pipeline.
• Diff — compare just this entity against another pipeline, changing nothing.

​

On a pipeline

Find the pipeline you want to sync from, click the three-dot menu (⋮) at the right of its row, and hover Manage:

• Duplicate — make an independent copy of this pipeline (not part of Sync).
• Diff — compare this pipeline against another and change nothing.
• Sync — push this pipeline’s mappings into another pipeline.
• Sync from main — the reverse: pull production’s mappings into this pipeline.

​

Publishing After a Sync

Two consequences are worth planning around:

• If a scheduled run fires between your sync and your publish, it runs the old configuration.
• A target that was never published won’t run at all, and may report that it has no pipeline nodes.

You have two ways to handle it:

1. Tick the publish checkbox in the Sync dialog — Publish the target pipeline after syncing (or Publish {target} after committing in the Merge wizard). It’s off by default, and publishes immediately after the sync is saved.
2. Publish manually afterward, using the Publish action on the target pipeline. This is the right choice when you want to sync several changes, verify them together, and publish once.

If the sync succeeds but the publish fails, the sync is still saved — nothing is rolled back. The banner says so, and names the failing entities:

“The sync was saved, but publishing failed.” “{target} still runs the mappings it had before the sync. Publish it again to pick up these changes.”

Publishing again is the fix. You do not need to re-sync. Resolve whatever the failing entities report — usually a validation problem in the mapping itself — and publish the target again.

​

Limits and What Sync Does Not Do

Being explicit so nothing is a surprise:

• Source and target must be in the same firm and environment. You cannot sync across firms.
• The source is never modified. Sync is strictly one-directional per run.
• Data is never moved — only mapping configuration.
• Sync does not publish unless you ask it to.
• Access control entities are never synced. They’re deliberately excluded so a target can’t be left in an inconsistent access state.
• Merge decisions are per item, not per attribute. You accept or reject a whole field, not individual attributes of it.
• Renaming can look like a delete plus an add. Sync matches items by their stable key, so if something was renamed on one side, the comparison sees one item removed and a different one added rather than a rename.
• A batch Merge commit is not all-or-nothing. Entities are committed one at a time, so if one fails partway through, the ones before it stay applied.

​

Best Practices

​

Related Topics