Applying changes

Applying is the only destructive thing Charter does, so it is wrapped in more ceremony than the rest of the tool.

It is not atomic

Azure DevOps has no transaction across processes and projects, and no rollback. Charter writes each resource in turn. If the twelfth write fails, the first eleven have already happened and stay applied.

This is a property of the platform, not a limitation Charter could engineer away. What Charter does instead is make the change visible before it happens and recoverable after.

Before: the blast radius and the summary

Saving shows you what the apply reaches — how many processes, work item types, projects and checks — and a summary of what will change in each.

Read the counts. The number that surprises people is the multiplication: five processes and six projects is not eleven changes, it is five work item type writes plus six check writes, and each one can fail independently.

Where processes have drifted apart the summary says varies by process, because the same configuration produces a different change in each.

At confirmation: two files

Confirming downloads both of these before any write happens.

charter-snapshot-before-<timestamp>.json — the live configuration of exactly the resources about to be changed, in the same format Charter imports. This is your undo: upload it and save.

charter-apply-preview-<date>.md — the full account of the change, process by process and project by project. Which named fields are added, which property of an existing field changes and to what, which rules changed, which checks and webhooks appear. It is the detail the dialog has no room for, and it is the record to attach to a change ticket.

After: the result per resource

Each write is reported separately, with its own errors and warnings. A failure on one project does not stop the others.

Charter then re-reads the live state, so the hub shows what the server actually holds rather than what you asked it to do. If a write silently did not take effect, the refreshed view is where you will notice.

Undoing

Upload the snapshot JSON and save. The caveats are worth understanding:

• It restores what it captured. Anything in the gaps list was never read.
• It cannot un-delete, but then neither can the apply delete — fields and states are never removed, so there is nothing to recover there.
• A layout is rewritten wholesale, so restoring a snapshot restores the previous layout wholesale too.

A habit worth forming

Apply to one process first, check the result, then apply to the rest. The dialog tells you the blast radius precisely so that choosing a smaller one stays easy.