Documentation

Configuring work item types

Fields, states, rules and form layout, applied across any number of inherited processes.

The Processes tab configures inherited work item types. Select the processes you want to target and the work item type to configure, and Charter applies one definition to all of them.

This is the heart of the tool. Azure DevOps scopes a work item type to a single process, so keeping the same type consistent across five processes normally means five identical passes through the same screens.

Fields

Add a field to the type, set whether it is required, give it a default value, and place it in a group on the form.

Charter distinguishes between a field being on the type and a field being on the form. Removing a control from the layout hides it; the field itself, and any data already captured in it, remains.

Charter never deletes a field from a work item type. A field that exists on the type but is absent from your configuration is left exactly as it is. If you genuinely need a field gone, delete it in Azure DevOps directly — that is a destructive, irreversible operation and it is deliberately not something a bulk tool does across fifteen projects on your behalf.

Inherited system fields — Title, State, Reason, Area Path and the rest — are not managed by Charter and are not listed in its configuration. They are unaffected by anything you do here.

States

Add states to the type and set their category. As with fields, states are never deleted by an apply.

Rules

Rules are conditions and actions: when the state becomes Doing, make Assigned To required. Charter configures them alongside everything else so a rule travels with the type rather than being reapplied by hand per process.

A rule changed in place — same name, different condition — is reported in the apply preview, not just a change in the number of rules.

Layout

The form layout is written as a whole: sections, groups, and the order of controls within them. This is the one part of a work item type that Charter rewrites rather than adds to, which is why the apply summary calls it out separately as layout rewritten.

If a process has had its form arranged by hand, applying a Charter layout to it will replace that arrangement. The snapshot taken before the apply contains the previous layout.

Drift between processes

Processes targeted together rarely start in the same state — reconciling that is usually the point. The apply summary says varies by process when they differ, and the downloaded preview document breaks it down process by process, naming which fields each one gains.