Compare and Merge Projects

Compare lets you see exactly what differs between two projects and, for the parts that can be safely copied, merge selected changes from one into the other. It’s built for two everyday situations:

• Promote changes between environments — review what’s different between a QA (development) project and its Production counterpart, then move just the changes you want into Production.
• Review against an earlier snapshot or copy — compare a project to a copy of itself (for example, a month-over-month clone) to see what changed.

You stay in control the whole way: nothing is written until you select specific items and apply them, and you can validate first with a dry run.

Matched item by item (by id for copies, by name for independent projects), each difference is marked changed, added, or same. You pick which to merge — nothing lands in Production until you apply.

How Matching Works

To compare two projects, PlaidCloud has to decide which item on the left corresponds to which item on the right. It picks the strategy automatically:

• Copies and snapshots of the same project are matched by their internal id (a clone keeps the same ids), so even renamed items line up precisely.
• Independent projects — such as a QA project and a separately built Production project — share no ids, so they’re matched by name. When this happens, items are tagged (name-matched).

Name matching is what makes a QA-to-Production comparison useful, since the two projects were built separately. It also has limits: items with duplicate names can’t always be paired one-to-one, and an item flagged ambiguous match means more than one candidate shared the same name — review those by hand before merging.

There is a third way to match, used when one project was built by copying from the other: pairing by that recorded copy lineage, so a renamed copy still lines up with its original. It isn’t picked automatically — you ask for it with Re-sync Into…, covered in Re-syncing From the Project You Copied From.

Opening a Comparison

1. Open Analyze
2. Select Projects from the top menu bar
3. Right-click the project you want to start from (or use its actions menu) and choose Compare to…
4. In the Compare Projects window, the project you started from is filled in as the Source
5. Choose the Target project from the dropdown — the project you want to compare against
6. Click Compare

Note

Use Swap to reverse the Source and Target before comparing — the direction matters, because a merge copies from Source into Target.

Both projects must be in the same workspace.

Reading the Comparison

The left side groups every difference under its category: Workflows (with their Steps nested underneath), Variables, Dimensions, Editors, UDFs, Views, and Tables.

Each item is badged with its status:

• Added — present in Source but not in Target (it would be created in Target)
• Modified — present in both, but the configuration differs
• Deleted — present in Target but not in Source
• Unchanged — identical on both sides (hidden by default)

Select a changed item to see its details on the right: a Field / Source / Target table of what changed, with the full Config diff beneath it. If an item’s diff is very large it’s truncated — click Expand full diff to load the complete version.

Focusing the List

• Filter by name or path narrows the tree to matching items.
• The status checkboxes show or hide Added, Modified, Deleted, and Unchanged items.
• Needs manual attention shows only the changes that can’t be merged automatically (see below).

What Can Be Merged

Not every difference can be safely copied between projects. The comparison labels each item so you always know what’s mergeable:

• Workflows, Steps, and Variables can be merged.
• Dimensions, Editors, UDFs, Views, and Tables are view-only — they appear in the comparison so you can review them, but you copy them across using their own dedicated tools, not from here.

Some individual changes are also marked manual (with a lock) even in a mergeable category, because applying them automatically wouldn’t be safe. The detail pane explains why and what to do instead. The most common cases:

• Steps in a name-matched (QA vs Production) comparison are review-only — a step’s configuration can reference environment-specific connections and agents, so it’s copied by hand. Use the diff to see precisely what to change in the Target.
• Variable deletion isn’t applied for you — remove the variable in the Target project by hand.

The summary line tells you the split at a glance, for example “12 mergeable · 5 view-only” and “3 need manual attention.”

Merging Changes

1. Select the items you want to copy from Source into Target. Use Select all to pick every mergeable item currently shown, or multi-select individual rows. View-only and manual items can’t be selected.
2. Click Dry run to validate the selection without writing anything. PlaidCloud reports how many operations would apply (new vs. updated) and flags any that would fail.
3. When the dry run looks right, click Apply (either from the dry-run result or the footer).
4. Confirm the operation in the Confirm merge dialog.

Merged items keep their identity in the Target, so you can run the comparison again later and merge further changes without creating duplicates.

Caution

A merge copies into the Target project and changes it. Review the diff and run a dry run first, and make sure Source and Target are the right way around.

If Something Goes Wrong

• Target changed — if someone else modified the Target after you loaded the comparison, the merge stops to avoid overwriting their work. Refresh the comparison and reapply.
• Merge partially applied — if one operation fails partway through, the rest are reported as remaining. Fix the cause and choose Retry remaining, or cancel and refresh.

Re-syncing From the Project You Copied From

Comparing works between any two projects in a workspace. But when the Target was built by copying from the Source — with Copy Project into an existing project — PlaidCloud remembers which object in the Target came from which object in the Source. Re-sync uses that memory to compare the two the way they are actually related, rather than by guessing from ids and names.

This is what lets one tenant hold Dev, QA, and Production as separate projects and promote changes forward between them. You copy Dev into QA once; from then on, re-syncing QA against Dev shows only what changed in Dev since, and lets you move the pieces you choose into QA — then QA into Production the same way. No export, no archive, no second workspace.

Why It Matters

An ordinary comparison of two independently built projects has to pair items by name, because they share no ids. That works until the copy renamed something. When Copy Project lands an object whose name or id already existed in the Target, it gives the incoming one a new identity ( copy appended) — so a plain comparison sees the renamed copy as unrelated to its Source original: the Source item reads Added and its own copy in the Target reads Deleted, side by side. You’d be looking at two halves of the same object with no way to line them up.

Re-sync pairs them by descent instead — the recorded copy lineage — so a renamed or re-numbered object still lines up with the one it came from, and only genuine changes show as differences.

Running a Re-sync

1. Open Analyze
2. Select Projects
3. Right-click the project you copied from — the Source, e.g. Dev — or use its actions menu, and choose Re-sync Into…
4. Choose the Target you copied into earlier — e.g. QA
5. Click Re-sync

The window is the same Compare Projects window, and everything in Reading the Comparison, What Can Be Merged and Merging Changes applies unchanged. The one difference is how items are paired.

Note

You stand on the Source and re-sync into the Target, so the direction is already correct — a merge still copies from Source into Target, exactly as in an ordinary comparison.

When There’s No Lineage to Use

Re-sync needs a recorded copy between the two projects. If you re-sync a pair that was never connected by Copy Project — or only partly was — PlaidCloud tells you rather than pretending:

• No lineage at all — a banner says the comparison fell back to ordinary pairing and is not a re-sync. It behaves exactly like a normal comparison, including the Added/Deleted split for anything an earlier copy would have renamed. This is what you see if you re-sync two unrelated projects, or a project pair connected by an archive import rather than Copy Project.
• Partial lineage — if the copy covered only some categories, a banner names the ones that fell back. Those categories are then paired by name, which merges the same safe subset a QA-vs-Production comparison does — variables and workflow record changes go across, while steps and newly added workflows become review-only (see What Can Be Merged).

Either way the pairing you actually got is what the window shows and merges — a re-sync never silently downgrades to a name match while telling you it matched on lineage.

Related

• Manage projects — versioning and point-in-time tracking within a single project
• Archive a project — capture a point-in-time snapshot you can compare against later
• Workflows — the automation primitive a comparison merges between projects