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.
The shape of it
Section titled “The shape of it”- Protect the model that represents your real organization, so nobody edits it by accident.
- Copy it into a draft —
Reorg Proposal,FY26 Plan. - Change the draft freely. It’s disposable.
- Compare the two to see precisely what you’ve done, and what it costs.
- 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.
Copying
Section titled “Copying”Copy Model copies the model’s units and positions. There’s no choice about
whether people come too, so check the copy before you share it or plan from it: if
positions in the copy are filled, the copy carries those names. For a design exercise
or a hiring plan, where the shape is the question and the names aren’t yet, vacate
the positions in the copy, or leave names out when you read it (an AI agent can read
the model table with includePeople = false). When you later merge the copy back,
reject the vacancies that unassigning created.
A copy remembers its origin, so Compare and Merge default to offering the model it came from. On the copy, that means Merge pulls the original into the copy; to bring the copy’s changes into the original, open the original’s Merge view and select the copy as the source (see Merging). A model that wasn’t copied from another defaults to your live model instead, when the workspace has exactly one; with several live models, or none, you pick.
Comparing
Section titled “Comparing”Open the draft’s Compare view and pick the model to compare against. The picker lists the model’s own snapshots too, under Snapshots of this model, so you can see what has changed since one was taken.
Every change reads from the model you compare against (before) to the model you are viewing (after), and the Unit changes, Changed Units and People moves cards each say so in words, with both model names. The swap button next to the picker reverses the direction.
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, a unit’s planned start and end dates, and its readiness checklist states. Merging a changed unit brings its checklist states across.
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.
How positions are matched
Section titled “How positions are matched”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.
How reshaped units are shown
Section titled “How reshaped units are shown”A restructure rarely keeps every unit as it was. Pods get new names, teams move under a different parent, one team splits in two and two teams fold into one. Compare’s Unit changes card follows each unit from the model you compare against to this one and sorts what happened into:
- Renamed: the same unit under a new name. If it moved as well, both parents are shown.
- Re-parented: the same unit, same name, under a different parent.
- Split: one unit became two or more.
- Merged: two or more units became one.
- Added and Removed: units with nothing before or nothing after them.
A copied unit remembers which unit it was copied from, so a unit you renamed in a draft is still recognized as the same unit. Where that link is missing, Resorcerer falls back to the unit’s name, and then to where its positions went: a new unit that took most of its positions from one existing unit is shown as split off from it, and a removed unit whose positions mostly went to one other unit is shown as merged into it. Those rows are marked by slots.
Each row shows the old and new names, how many positions it held before and after, and the people who moved in or out. Switch to Mapping table for one line per unit in the model you compare against, next to the unit or units it became, and use Export mapping CSV to download it. Its columns are named after the two models, in the table and in the CSV alike.
Who moves where
Section titled “Who moves where”The People moves card answers the question everyone asks after a restructure: who
moves, and where to? It starts with six counts: Moved, Stayed, Moved to bench,
Placed from bench, Left (the structure) and Newly placed. Below them is one row per person who did not
stay, showing the unit they come from and the unit they go to as full paths (for example
Engineering / Platform / Pod A → Engineering / Pod B), plus any change to their role or
level.
A person moves when the set of units their positions sit in changes. Someone in a unit that was only renamed or moved under a new parent stays, because it is the same unit. A person whose position is in two units moves if either of them changes. Someone who is in a unit only in the model you compare against has left the structure, and someone who is in a unit only in this model is newly placed. Someone whose positions are all on the bench (in no unit) is still in the model: they are counted as moved to the bench, or placed from it, rather than as leaving or joining, and their side of the move reads Bench.
Group the list By source unit or By destination unit, pick a Label to see only the people moving into or out of units with that label (only pods, say), and use Export moves CSV to download the rows you are looking at.
Comparing several scenarios
Section titled “Comparing several scenarios”A restructure usually comes with alternatives: a No funding plan and a Funded ask
plan, say, both copied from the same model. Compare shows two models at a time; to see the
alternatives side by side, open the starting model’s Scenarios view.
That model is the base. Pick two to five other models to compare with it. The models copied from the base, and the models copied from the same model as the base, are listed first under Built from the same model, and are already picked when you open the view. Your choice is kept in the page address, so you can share the comparison.
The table has a column for the base and one for each scenario, with each scenario’s difference from the base in brackets:
- Headcount and cost: units, total positions, filled and vacant positions, and total cost. These are the same figures Compare shows for that scenario against the base.
- Units by label: how many units carry each label, such as the number of pods.
- Composition problems: units with too few or too many of a role, and required seats nobody fills yet, as the Problems view counts them.
- People moves from the base: how many people moved, stayed, moved to or were placed from the bench, left and were newly placed, with the same labels as the counts on Compare’s People moves card.
Each scenario’s heading has a Compare link that opens the full comparison of that scenario with the base. On a narrow screen, scroll the table sideways; the metric names stay in view.
Merging
Section titled “Merging”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.
The source can be one of the target’s own snapshots, listed under Snapshots of this model: merge from it to bring back part of an earlier state.
Merging more than once
Section titled “Merging more than once”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.
Proposals from your people directory
Section titled “Proposals from your people directory”A live model is kept current the same way. Whenever your people directory changes — an import, a People Sync run, a change to the rules that derive attributes — a live model recompute works out what that means for each live model and offers it in that model’s Merge view as a sync proposal: the same review list, the same accept and reject, the same Apply. Each live model has its own proposal, driven only by the people in its own scope.
A worked example
Section titled “A worked example”You’re adding a platform team and moving two engineers into it.
Current Orgis protected. Copy it asQ3 Platform.- In the copy: add the
Platformunit, create the positions, move the two engineers across, set their reporting lines. - Compare against
Current Org. One unit added, four positions added, two changed (the moves), cost up by the two new hires. - Open
Current Org’s Merge view and selectQ3 Platformas the source. Accept the new unit and the moves; reject the second new hire, which isn’t funded yet. - Apply.
Current Orgnow has the team and the moves.Q3 Platformkeeps the unfunded position, ready for the next round.
Related
Section titled “Related”- Models — protected, private, and copied models.
- Analyse a model — checking the result.
- Planning over time — keeping successive plans as a dated series.
- Snapshots — read-only copies of a model to compare against or merge from.
- Keep a model live — merging changes from your people directory.