Edit Mode License required

The visual never writes to your source. It records what you propose and hands you a file — a person, or a flow you control, decides what happens next.

Turning editing on

Editing appears only when the report author enables it in Format visual → Editing → Allow editing. An Edit tab then appears, holding the edit-mode switch and every editing control. Nothing on the other tabs changes.

What you can change

Assigning someone

Select a billet, open Edit, and type into the picker. By default it offers people at this command — anyone whose billet, local attachment, active service, TAD, or other UIC places them here (five ways a person can be tied to a unit at once; see the Field Reference), whether or not they already hold a billet. Reassignment within a unit is normal, so people already assigned are offered too; the unassigned sort first, because taking a billeted person costs another billet.

Tick Search the entire roster to reach beyond the command — civilians filling command billets, other services, someone on temporary duty. Once that box is ticked, a second choice appears: tag the person you pick as TAD or Other, which records that outside tie on their own roster record (so they show up here again on their own next time, without re-picking). Only appears when the person you assign doesn't already belong to this unit's normal candidate pool — assigning someone who was already eligible needs no tag at all.

If the person is not there

Add person… creates a roster entry. The only field that really matters is the identifier: a DoD ID (10 digits) or a FASCN (16 digits). That is what your source joins on, so it is validated rather than accepted freely — a malformed id exports cleanly, joins to nothing, and is not discovered until someone asks why a billet looks empty. A brand-new record has no real billet, local, or active UIC to speak of, so it isn't asked for one — it's tagged Other for this billet's own UIC automatically.

The Unassigned pool

An optional panel showing who is on the books at a command but not filling a billet, grouped into cards. Unlike a billet's own contact details, which category a person falls into is never read from the data — it's computed from their five UICs against the group's own UIC: Billeted local, Billeted non-local, Non-billeted local, Externally billeted, Active-aligned, TAD, or Other. It is derived — roster minus active assignments — so assigning someone removes them from the pool immediately, and ending an assignment puts them back. That is also why it is read-only: it is a view of the roster and the assignments, so the way to change it is to change one of those, or, for a TAD/Other tag specifically, to remove the tag itself from the Recall details editor once it's no longer needed.

Only a TRIAD or COMMAND_LEADERSHIP group gets its own pool, always below that command, spanning the full width of everything under it, even with little content, for visual consistency. The Format pane's Layout setting controls how the categories arrange within that space: Vertical stacks each category's card; Horizontal spreads them side by side, dividing the available width evenly. Each category can be hidden or relabeled independently in the Format pane, in a fixed order; the labels default to the Navy short forms where a command uses one (Local, CAI, IAP, CAO) and plain descriptive text for the rest.

Assignment review

Two independent checks, each its own Format pane toggle, each marking a billet directly with a small corner flag:

• Flag detached assignments — the holder is not on roster (no longer appears in the bound data at all) or has a UIC mismatch (their UICs no longer place them at this command).
• Flag expired assignments — the assignment has an end date, and that date has already passed. A not-yet-started assignment is never flagged this way — not active isn't the same thing as expired.

The visual does not correct either. Only a person can say whether the billet is now gapped or the roster is simply behind, so a flag is an action item rather than an automatic edit.

Overlay flagged assignments adds a second, optional way to see the same flags: a small box listing everything currently flagged within a command, drawn to the left of its own TRIAD or COMMAND_LEADERSHIP group. Unlike the Unassigned pool, it never reflows the chart — it's meant to appear and disappear as things get fixed, and forcing a layout shift every time one clears would be more disruptive than helpful. It has no position setting of its own for the same reason.

Undo

Pending changes accumulate as an ordered list. Undo steps back one at a time and shows how many remain; Undo all drops every pending change and returns the chart to exactly what the source says.

Exporting a changeset

Export changes produces a JSON envelope: the chart id, when it was submitted, the source revision it was built against, your note for the approver, and the ordered list of operations.

{
  "schema_version": "1.0",
  "chart_id": "UNIT_PHX",
  "submitted": "2026-08-31T14:02:11Z",
  "base_revision": "a41f9c…",
  "comment": "Stood up N7; moved the CFL under N4",
  "op_count": 7,
  "changeset": [ … ]
}

Type your note in the box beside the export button before exporting — it travels with the batch so an approver has the reasoning alongside the operations.

Importing someone else's changes

Import changes… takes a changeset exported from another report and applies it here. Operations already reflected in your data are skipped, so importing the same file twice is harmless.

What happens after a refresh

When the source data refreshes, the visual compares each pending change against it. Ones that have landed — because your flow pushed them and the refresh brought them back — are dropped from your draft automatically. Ones that have not stay pending and are re-applied on top.