> ## Documentation Index > Fetch the complete documentation index at: https://support.entegrata.com/llms.txt > Use this file to discover all available pages before exploring further. # Sync Overview > How Sync moves data mapping configuration from one pipeline into another, including terminology, scopes, and limits **Sync is a beta release feature.** If you don't see it in your subscription, contact your Entegrata Customer Experience Manager to ask about having it enabled. ## 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. Sync moves **mapping configuration only** — the definitions of your entities and fields. It never moves your data, and it never changes the pipeline you're syncing *from*. ## Key Terms The pipeline the configuration comes **from**. Never modified by a sync. The pipeline the configuration goes **into**. This is the one that changes. How much of the source you bring across, and how much say you get over the details. Three options — see [Sync Strategies](/data/pipeline/sync-strategies). ## 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. | | Single entity | Whole pipeline | | ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | | **What moves** | Only the entity you picked | Every entity in the pipeline | | **Where you start** | Inside a pipeline layer, the **⋮** on an entity row | Pipelines list → **⋮** → **Manage** | | **Strategies** | All three, applied in place. **Merge requires the entity to already exist in both pipelines** | All three. Choosing **Merge** opens the review wizard rather than applying anything | | **Adding an entity the target doesn't have** | Overwrite and Overlay only | Yes — Overwrite and Overlay create it, and Merge offers it as an explicit choice | | **Removing an entity the source doesn't have** | **Never.** Single-entity sync replaces that entity's fields and sources; the entity itself is never deleted | Overwrite deletes it; Overlay leaves it and reports **Skipped**; Merge asks you | | **Entities that reference each other** | Not checked | Move together, so relationships stay consistent | 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. Move just one entity Sync an entire pipeline into another ## Where to Find Sync Log in to the [Entegrata Admin Portal](https://admin.entegrata.com) 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. The main pipeline's own actions menu has no **Manage** submenu. To sync *into* main, start from the pipeline you're syncing *from*. ## Publishing After a Sync **A sync updates mapping configuration. It does not change what your pipeline is currently running.** Until the target pipeline is **published**, it keeps running the mappings it had *before* your sync. The new configuration is saved, safe, and visible in the UI — but it isn't in effect. 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. What publishing does and what it requires Activate a pipeline for scheduled runs ## 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 **Diff Before You Sync** Especially the first few times, and especially before an Overwrite into production. [Comparing Pipelines](/data/pipeline/comparing-pipelines) is completely read-only — use it to answer "what's actually different between test and production right now?" before deciding whether to sync at all. **Match the Strategy to Your Intent** * **Overlay** when you're adding to production and don't intend to remove anything. It's the strategy that can't surprise you. * **Overwrite** for resets — pulling main down onto a drifted test pipeline is exactly what it's for. * **Merge** when both pipelines have moved on. If real work has happened on production *and* on test, neither Overwrite nor Overlay expresses what you want. **Write Reasons a Stranger Could Read** Every sync requires a reason, and it's saved to the target's change history. Write something a colleague would understand in three months: "Syncing new billing-attorney fields validated on test." **Decide About Publishing Before You Click Sync** Sort this out up front rather than discovering it after a scheduled run has already used the old configuration. **Sync Whole Pipelines When Entities Are Interrelated** Single-entity sync is precise but doesn't check the entities that reference the one you're moving. ## Related Topics Overwrite, Overlay, and Merge compared Review differences without changing anything Approve differences one at a time Create an independent copy instead of syncing