Keep a model live

Your people directory changes constantly — someone joins, someone leaves, a manager changes. Rather than editing the models that describe your real organization by hand every time, make them live: Resorcerer watches your people directory and turns each change that affects a live model into a reviewable sync proposal for that model.

Any number of models can be live at once, and each one is configured on its own — its own people, its own groups, its own review rules. A company-wide org chart can be live alongside one model per region or business unit, each paying attention only to the people it covers.

Turning a model live

There are two ways in:

From the model’s Live button. Open any model, press the Live button (the radio icon in its header, next to Copy and Edit) to open the Live sync dialog, and turn on the Live switch. Turning it on protects the model for you, since a live model has to be protected and not archived — the same combination Compare and merge already asks for, because a sync proposal is reviewed the same way a merge is.
When you generate a model from your people. In Create Model, pick Your people as the starting point and tick Keep this model live. The new model is generated, protected and made live in one step, with everything on this page set from the Create Model dialog itself: its unit source and groups are the ones you generated from, whether that was departments, managers or groups (a model generated with no units is kept live without unit sync — see Unit source), its people in scope are the people you generated from, and its review settings are the ones you ticked. You land on the finished model; the Live sync dialog is there whenever you want to change something.

Only organization admins can turn a model live, change its live settings, or turn it off. Anyone who can open the model can open its Live sync dialog and see its settings and pending changes, and anyone who can edit the model can review and apply them.

A live model shows a Live badge on its header and everywhere models are listed, and the models list has a Live filter to show only live models. The header’s Live button is filled while the model is live and carries the number of pending changes.

While a model is live it can’t be un-protected, archived, or moved to the trash — turn off the Live switch in its Live sync dialog first. Turning it off discards the pending proposal; the model itself, and everything already applied to it, stays exactly as it is.

What gets proposed

Resorcerer compares your current people directory against each live model and proposes:

Upstream change	Proposal
A new active person, matching exactly one vacant position (role, level, location, company — and in the right unit, when units are synced)	Fill that position, clearing any placeholder, hiring stage, and requisition it had
A new active person, with no single matching vacant position	Add a new position — in the matching unit, or, when units aren’t synced, in their manager’s unit (see Unit source)
A person deactivated, or past their end date	Unassign them — the position stays, keeping its attributes, unit, and reporting line, just vacant
Role, level, location, or company changed	Update the position’s attribute — but only where the position and the person were previously in agreement. A deliberate difference you set up on purpose is never proposed away.
Manager changed	Update the reporting line
Unit changed (department, or the group a person directly belongs to — see Unit source)	Move the position to the matching unit, creating it if none exists yet (only when units are synced)
A group renamed upstream (Groups unit source only)	Rename the matching unit in place — the position stays put, nothing moves
A group re-parented upstream (Groups unit source only)	Re-parent the matching unit under its new parent’s unit — the position stays put

The last three rows only apply when units are synced — a model whose unit source is Don’t sync units never proposes a move, a rename or a re-parent, and never creates a unit for a move. The last two apply only with the Groups unit source: a group’s identity is tracked directly, so renaming or re-parenting it never looks like a departure and a new hire — it’s proposed as what it actually is, a structural change to the unit itself. A group that’s deleted or emptied upstream proposes nothing; the unit it produced is left exactly where it is.

A position or a unit is never deleted by a proposal — Resorcerer only ever proposes changes a person in your directory actually caused, and only for people in scope (see below). A person who falls out of scope while already in the model is left exactly where they are — they’re never proposed as a leaver just for leaving scope.

Configuring a live model

Everything about how a model stays current is in its Live sync dialog — press Live in the model header — in six sections. Every live model has its own copy of each setting, so changing one model’s scope or review rules never affects another.

Live

The Live switch itself — on to keep the model current from your people directory, off to stop.

Status

When the model last recomputed, how many changes are pending (with a Review in Merge link straight into this model’s proposal), a Recompute now button, and the last-run status of every connected People Sync provider.

Unit source

Whether the model’s units are kept in sync at all, and if so what drives them. Four choices:

Don’t sync units — positions are filled, added, vacated and updated, but units are never created, moved or renamed. Use this when you manage the structure yourself and only want the people in it kept current. A new person still fills a matching vacant position — in any unit, since units aren’t the model’s concern — and when there isn’t exactly one match they’re added as a new position in their manager’s unit, or in no unit when their manager has none in the model.
Department field — one unit per distinct department, matched by name; a change of department is proposed as a move, creating the unit if the model has none by that name.
Managers — one unit per manager with direct reports, nested by the reporting chain. A change of manager is proposed as a move, a new manager gets a unit, and a manager’s rename or own change of manager is proposed as a change to their unit. To cover only part of the organization, set Reports up to in People in scope.
Groups — one unit per group in the tree, from the deepest group each person directly belongs to (once groups are set up). Pick any number of root groups to cover just their subtrees, or leave it empty to cover every top-level group; the Groups in scope section narrows the tree further. A group’s renames and re-parents are proposed as changes to its unit.

When units are synced, a person the unit source can’t place — someone with no department, or someone who isn’t directly in any group under the roots — is simply left out of the proposal until the directory can place them. The model never grows a holding unit full of positions you didn’t ask for.

Switching between these changes what counts as a move — and turning unit sync off drops every pending move, rename and re-parent from the proposal — so the dialog warns you before you save a change here. The root groups and groups in scope only apply to the Groups choice; they’re kept, but ignored, under the others.

People in scope

Which people the model pays attention to. A structured filter — department, reporting line (a person and everyone under them, at any depth), direct manager, role, level, location, company, title keywords, and group membership (transitive: a parent group includes everyone in its sub-groups) — with a live “N of M people in scope” count that updates as you edit. Leave every field empty and everyone in your people directory is in scope; Clear (everyone) gets you back there.

The scope is a live-sync setting and nothing more. Only in-scope people ever produce proposals — someone outside scope never appears as a joiner, even if they’d otherwise match a vacant position — but the scope never hides anyone: every person is still offered for assignment and still listed in the model’s People view, and a person already assigned who falls out of scope is left exactly where they are.

Groups in scope

When the unit source is Groups, include/exclude name patterns and a maximum depth limiting which groups become units, with a live groups-in-scope count. The section is hidden for the other unit sources, where groups play no part in the structure.

The same section sets how the units are named. By default a unit carries its group’s name. To change that, enter a regular expression to match in the group name and what to replace each match with, where $1 is the first capture group. For example, matching ^SG-(.+)-Team$ and replacing with $1 names the unit for the group SG-Platform-Team Platform. Leave the replacement empty to simply remove the matched text. A group the expression doesn’t match keeps its name, and matching ignores upper and lower case. The include and exclude patterns always look at the group’s own name, not the unit’s. When you add or change the naming on a model that’s already live, the existing units arrive as Rename proposals on the next sync. Lookarounds and backreferences aren’t supported in the expression. An expression that is not valid is flagged as soon as you leave the field, with what is wrong and how to fix it (for example a missing )), and cannot be saved.

When exactly one group is picked as the root, you can also choose Leave out the root group. The group you picked then gets no unit of its own, and the groups directly under it become the top-level units. Say you pick a group called Company: its departments become the top of your hierarchy instead of sitting under a single Company unit. People who belong only to the root group itself have no unit in the model, so they’re left out. With no group or several groups picked the option is unavailable, and a maximum depth still counts levels from the group you picked. Turning it on for a model that’s already live shows up as changes to review on the next sync.

People in several groups decides what happens to someone who is directly in more than one group under the roots. A group that contains another of their groups doesn’t count: someone in both EMEA and EMEA Sales still lands only in EMEA Sales, while someone in the sibling groups Sales and Marketing lands in both. One slot in the deepest group, the default, gives them a single slot in the deepest of their groups, with a tie between groups at the same depth going to the first by name. One slot shared by every unit gives them a single slot that sits in each of the units their groups become. One slot per unit gives them a separate slot in each of those units, and the Problems page then only flags a person’s slots that collide in the same unit, not the ones spread across units on purpose. Changing it on a model that’s already live shows up as changes to review on the next sync.

Auto-accept settings

Which kinds of change apply without a review — see Auto-accept below. Everything is off until you switch it on; with every switch off, every change waits for you in Merge.

When proposals update

Every live model’s proposal is recomputed when your people directory changes — a CSV import, a People Sync run or provisioning from an integration, or a change to the rules that derive attributes. A burst of changes is gathered into one recompute per model rather than one per change, so after a large import a proposal can take a minute to catch up.

Each live model recomputes independently. Recompute now in a model’s Live sync dialog recomputes just that model; Recompute live models on the People page recomputes all of them.

Reviewing

Open the live model’s Merge view — the banner on the model and the Review in Merge link in its Live sync dialog both go straight there, with the proposal already selected. The proposal is the difference between the model and the changes waiting to land, shown exactly like any other merge: filter by change type or by unit, open an item to see what’s changing, and accept or reject each one.

Rejecting isn’t deferral — that specific value won’t be proposed again until it changes once more upstream. If a manager change you rejected is later corrected in your people directory to something else, it comes back as a fresh proposal. A rejection belongs to the model you made it on: rejecting a change on one live model doesn’t hide it from another.

Apply commits what you accepted straight to the live model, the same write path as an ordinary merge. There’s no second way to change it.

Auto-accept

For changes you don’t need to review by hand, turn on auto-accept per kind — joiners, leavers, attribute changes, manager changes, moves (when units are synced), and structure changes (renames and re-parents, Groups unit source only) — from the Auto-accept section of the model’s Live sync dialog. Auto-accepted changes are applied automatically and recorded in the audit log with a system source, distinct from changes a person reviewed and accepted themselves.

Auto-accept is set per live model, so a regional model can take joiners automatically while the company-wide model still reviews every one.

Snapshots

When you Apply, Resorcerer asks whether to Save a snapshot first. Leave it ticked and it keeps a read-only snapshot of the model as it was just before, so you can look back at what the changes replaced. Snapshots don’t count toward your plan’s model limit.

Under it, Place on the timeline (ticked by default) decides whether the snapshot also becomes a point on the model’s timeline. Untick it and the snapshot is still saved and dated, on the model’s Snapshots tab, without adding a point; you can place it there later.

A snapshot you place on the timeline needs a date to sit at. By default it’s dated when the model last changed — the state being saved has been true since then, not since you clicked Apply, so a model that sat untouched for a month gets a snapshot from a month ago. Pick Today instead if you’d rather mark the moment of the sync, or Custom to choose any date up to today. A snapshot left off the timeline takes the model’s own effective date, or the day it last changed if it has none.

It’s asked each time rather than set once, because whether a particular set of changes is worth keeping a “before” of depends on the changes. Auto-accepted changes are never snapshotted — there’s nobody to ask.

For a history that doesn’t depend on anyone clicking Apply, turn on automatic snapshots in the Schedule card on the model’s Snapshots tab: a snapshot is taken on a schedule whenever the model has changed, which covers auto-accepted changes too.

Several live models

Because scope, unit source and review rules belong to each model, the natural way to keep separate parts of the organization current is one live model per part — typically one per group.

Say your people are organized into an EMEA group and an Americas group:

Create Model → Your people, units By groups, root group EMEA, and tick Keep this model live. Name it EMEA Org.
Press Live on EMEA Org and, under People in scope, pick the EMEA group and save. The model now pays attention to everyone in EMEA and its sub-groups, and nobody else — while still offering the whole company for manual assignment.
Do the same with Americas, as Americas Org.

When someone joins EMEA, only EMEA Org gets a proposal — Americas Org shows nothing pending, and applying, rejecting or auto-accepting on one never touches the other.

If two live models’ scopes overlap — a company-wide model and a regional one, say — a change to someone in both produces a proposal on both, and each is reviewed independently, just as two separate models always are.

When you Compare or Merge a model that wasn’t copied from another, Resorcerer offers your live model as the default counterpart — but only if there’s exactly one. With several live models it leaves the choice to you.

Update a model once

Not every model should follow your people directory forever. A planning scenario, a copy you are reshaping, or a model you simply want to refresh can be brought up to date once instead: press Live on a model that is not live and use Update from people.

You choose the same things a live model is configured with — what drives units (departments, managers, groups or none), the root groups and group filter, and who is in scope — plus which kinds of change to include: joiners, leavers, attribute changes, manager changes, moves and structure changes. Build update then produces a sync proposal that you review and apply in Merge exactly like a live model’s, change by change. Applying part of it leaves just what you have not applied yet; applying all of it clears the update. Rebuild refreshes it against the current directory and Discard drops it.

Two things differ from live sync:

It has no memory. Live sync leaves a deliberate override alone and never re-proposes a change you rejected. A one-time update knows nothing of the kind: every difference within the chosen scope and kinds is proposed, so untick the changes you want to keep when you review.
It is an editor’s action. Anyone who can edit the model can request, rebuild or discard an update; the model is not protected and no organization admin is needed. A live model cannot have one — its live settings already decide what it syncs from.

Over the API the same update is PUT, GET and DELETE on /models/{id}/sync-request, and over MCP it is RequestModelSync, GetModelSyncRequest and DiscardModelSyncRequest; the proposal itself is read and applied through the live-sync proposal routes and tools.

Models — the Live badge and the protected/archived rules.
Compare and merge — the review mechanics a sync proposal reuses.
Snapshots — the copies Save a snapshot first and a schedule keep.
Import people — one of the ways your people directory changes.
Integrations — keep your people directory current automatically.
Connect AI agents — listing live models and reviewing their proposals over MCP.