Build custom planning views with Claude

Resorcerer’s own views cover most planning questions, but sometimes you want a view shaped exactly like your rollout: a board of pods by go-live month, a staffing grid for one programme, a side-by-side of two restructures in your own layout. An AI assistant such as Claude can build that from your real model, and write the changes you settle on back into Resorcerer.

This guide walks the safe path end to end: connect with as little access as the job needs, read the model in one call, build the view, write changes back to a copy you review, and share the result without sending people’s names, titles or notes along with it.

1. Connect

Add Resorcerer to Claude as a connector, using the details from the MCP button in the app header (see Connect AI agents). When Claude sends you to Resorcerer to confirm, set the access for this connection before you approve it:

• Model Access → Selected, then pick only the model the view is about. Choose Read if the view only looks at the model; choose Write only on a model you want changes written to (see Write back, which uses a copy).
• Metadata → No access, unless the view genuinely needs to show who holds each position. Without it, everything the connection reads comes back without names.
• Turn off Allow creating new models unless you want Claude to create them.

The same choices are available on an access token (My Settings → Access Tokens) if you’re connecting something headless instead. A connection is never more privileged than you are, and you can remove it at any time.

2. Read

Ask Claude to read the model with GetModelSnapshotTable. It returns the whole model as one flat table, a row per position in each unit it belongs to, with the unit path, labels, planned dates and rollout state, the position’s role, level, location and company, FILLED or VACANT, open comments and open problems. A model of up to 500 positions comes back in a single call; for a larger one Claude passes nextCursor back as cursor until it is empty. That’s quicker and more reliable than having it walk the units and positions one by one.

Parameter	What it does
modelId	The model to read.
includePeople	true by default. Set it to false for a names-free table: the holder’s name and title are left out.
unitLabelFilter	Only rows in units carrying a label: its value (Pod), Key: Value (Type: Pod) or its id.
cursor	The nextCursor of the previous page, for a model of more than 500 positions.

Pass includePeople = false for anything that will be shared. A connection without access to people always gets the names-free table, whatever it asks for, with a note saying why.

The same table is available without an assistant: the Download model table button on the Slots view saves it as CSV, and Model table without names (CSV) is the version to share.

3. Build

Start with the views Resorcerer already draws in the conversation. In AI apps that can display interactive views, such as Claude on the web and desktop, these tools show a chart or table right in the chat; elsewhere they return the same information as text:

Tool	Shows
ShowRolloutPlan (modelId, optional unitLabelFilter)	The model’s rollout: units by go-live month or quarter, and the ones with vacancies or composition problems.
ShowUnitComposition (modelId, unitId)	One unit’s positions, who holds them or that they’re vacant, and how the unit stands against its composition rules.
ShowScenarioComparison (baseModelId, modelIds)	A starting model against two to five scenarios, side by side.

Like everything else, they show only what the connection may read: without access to people, they leave names out.

When you need something these don’t cover, ask Claude to build a custom view (an artifact) from the table. A few prompts to start from:

Rollout view. Read model Northwind 2027 with GetModelSnapshotTable (includePeople = false, unitLabelFilter = "Type: Pod"). Build a board with a column per go-live month from unitStartDate, a card per pod showing its filled and vacant positions, and a warning badge on any pod with open problems. Put pods with no start date in a “TBD” column.

Pod composition board. Using the same table, build a grid with a row per pod and a column per role. Each cell shows filled / total positions for that role, highlighted when a pod has no filled position in a role the others all have. Let me filter by location.

Scenario comparison. Read Plan A and Plan B (both selected for this connection) with GetModelSnapshotTable (includePeople = false). Compare them by unit: positions added and removed, vacancies, and go-live dates that moved. Lead with a summary table, then the units that changed most.

Keep the view working from the names-free table unless it really needs names, and if it does, see Share safely before it leaves your screen.

4. Write back

Once you’ve settled on changes in the view (move these people to the new pod, push that unit’s go-live to Q3), Claude can write them back with ApplyModelChanges. It takes the modelId, a list of operations run in order (moving a position between units, creating units and positions, renaming, moving and re-dating units, setting a unit’s description, assigning and unassigning people, deleting a position), and dryRun.

Write to a copy, never the model you plan from. A protected or live model refuses these changes outright, and that’s the right outcome for any model that matters:

1. In the app, copy the model with Copy Model. There’s no option to leave people out of the copy, so check the copy’s table: if it lists names, treat the copy as carrying people’s details. To keep names out of what Claude reads, read the copy with includePeople = false. If names must be removed from the copy itself, vacate those positions in the app, or add an unassignPerson operation (with the position’s slotId) to the batch in step 3, and reject those vacancies when you merge in step 5.
2. Give a connection Write on the copy only: remove the connector and connect again, or create a new access token. A connection limited to selected models can’t reach a copy it makes itself, which is why the copy is made in the app.
3. Ask Claude to call ApplyModelChanges on the copy with dryRun = true, which is the default. Nothing is written: you get each operation’s result, the resulting headcount and any new problems, so you can see what the change would do before it happens.
4. When the preview is right, ask for the same call with dryRun = false. Every change is made or none is; if one fails, it is named and nothing is written.
5. Open the copy’s Compare view against the original to review what changed. Then open the original’s Merge view and select the copy as the source: Merge always pulls from the source into the model you open it on. (Merge opened on the copy defaults to the original as its source, and proposes undoing the copy’s changes.) Accept the changes you want, one at a time, and apply.

Each change is recorded in the audit log together with the connection that made it.

5. Share safely

A planning view is easy to pass around, and so is everything that went into it. A view built from a full model table carries real names, job titles, locations and whatever notes and comments people wrote for an internal audience.

• Default to names-free. Read with includePeople = false, or connect without access to people so names are left out whatever is asked. Download Model table without names (CSV) rather than the full table.
• Don’t attach exports or artifacts that contain people’s details to tickets, chats, shared drives or emails. That includes the JSON or CSV a view was built from, and the view itself if it shows names.
• Check the notes column. Position notes are written for whoever plans the model, and can be candid. Ask Claude to leave notes out of anything shared.
• Keep named views private. If a view needs names to be useful, keep it in your own conversation, and send colleagues a link to the model in Resorcerer instead, where the model’s own permissions decide who sees what.
• Remove connections you no longer need. Revoke the access token, or remove the connector, when the work is done.

Related

• Connect AI agents — connecting, scoping access, and every tool an agent can use.
• APIs — the model table’s columns, and the same table over REST.
• Compare and merge — reviewing and merging what an agent changed.
• Models — protected models, which refuse direct edits.