Skip to content

Compare and merge

This is the workflow Resorcerer is built around. Rather than editing your live structure and hoping, you copy it, change the copy, look at the difference, and merge back only what you want.

  1. Protect the model that represents your real organization, so nobody edits it by accident.
  2. Copy it into a draft — Reorg Proposal, FY26 Plan.
  3. Change the draft freely. It’s disposable.
  4. Compare the two to see precisely what you’ve done, and what it costs.
  5. Merge the changes back, accepting and rejecting them one at a time.

A protected model still accepts merges. That’s the point: edits are blocked, reviewed changes are not, so there’s exactly one way in.

When you copy, decide whether the people come too:

  • With assignments — a faithful snapshot. Right for “next quarter, starting from where we are”.
  • Without assignments — the same structure, every position vacant. Right for a design exercise or a hiring plan, where the shape is the question and the names aren’t yet.

A copy remembers its origin, so Compare and Merge default to offering the model it came from.

Open the draft’s Compare view and pick the model to compare against.

Differences are classified as added, removed, changed, or unchanged, for both units and positions, and you can filter to a change type or a particular part of the tree. Opening a changed item shows the before and after of each attribute that differs — role, level, location, company, occupant, units, reporting line.

Alongside that is the number the conversation usually turns on: total positions, filled positions, and total cost for each model, and the delta between them.

To say a position changed rather than was deleted and another added, Resorcerer has to recognize the same position in both models. It matches on the strongest available signal:

Signal Confidence
The same person is assigned to it High
Same attributes and the same reporting line High
Same attributes and the same unit Medium
Same attributes Low

Anything left unmatched is reported as an addition or a removal. This works well when changes are incremental, and gets less certain the more you rewrite at once — if a comparison looks stranger than expected, that’s usually why. Copying from the model you intend to merge into keeps the matching on its strongest footing.

Open the target model’s Merge view and select the source. Resorcerer works out the operations needed to bring one to the other — add, remove, or update, for units and positions — and presents them for review. A change that would replace newer work in the target with an older value from the source is flagged as a revert, and the review list can be filtered to show only reverts or hide them entirely, alongside filtering by change type or by unit.

Go through them and accept or reject each. Rejecting isn’t deferral; it means that change doesn’t happen. Where both models have moved on the same item, you get an explicit conflict with the choice of keeping what’s there, taking what’s incoming, or skipping it.

Apply commits everything you accepted, and reports what it did.

Merging isn’t one-shot. Keep working in the draft after a merge and the next merge shows only what’s changed since — already-merged items come through as no change. A long-running plan can feed into the live model in stages.

You’re adding a platform team and moving two engineers into it.

  1. Current Org is protected. Copy it, with assignments, as Q3 Platform.
  2. In the copy: add the Platform unit, create the positions, move the two engineers across, set their reporting lines.
  3. Compare against Current Org. One unit added, four positions added, two changed (the moves), cost up by the two new hires.
  4. Merge into Current Org. Accept the new unit and the moves; reject the second new hire, which isn’t funded yet.
  5. Apply. Current Org now has the team and the moves. Q3 Platform keeps the unfunded position, ready for the next round.