When enabled, Batch Control watches changes to jobs:

• job creation, configuration, deletion, rename and move are recorded in the change history, with a diff of config.xml for configuration changes (this recording is also enabled by Enable run control);
• a user who does not hold the standing permission to create or configure a job can ask for a temporary permission window instead. A window adds Item/Create, Item/Configure or Item/Delete on the one job or folder it names to whatever the user already has, for as long as it lasts; it never takes anything away, and it imposes nothing on someone who already holds the permission standing;
• deleting is the one exception to that: while this switch is on, deleting a job needs an active DELETE window even for a user whose standing permissions would allow it (administrators are not vetoed). No window confers Item/Delete on a folder, a multibranch project or an organization folder, because deleting one deletes everything inside it, so only an administrator can delete one of those;
• a folder, a multibranch project or an organization folder can be moved only by an administrator or a user with standing Item/Delete on it (and Item/Create at the destination), since no window confers Delete on it;
• no window allows renaming a job or folder of any kind: neither a Configure window nor Delete and Create windows together. A rename needs an administrator, or the user's own standing permissions: Item/Configure on the item, or Item/Delete on it plus Item/Create in its parent. A rename that only a window would have allowed is refused and recorded. A window follows its item when an administrator (or a user with their own permissions) renames or moves it, and ends when the item is deleted;
• an administrative monitor reports accounts that hold standing Create, Configure or Delete permissions outside the permission-window flow;
• the Grants screen is open, and the sidebar of each job and folder offers Request Change Permission, which opens the window request form with that item filled in.

A window confers its permissions only when both this switch is on and a Batch Control authorization strategy — Batch Control: Project-based Matrix Authorization Strategy or Batch Control: Role-Based Strategy — is selected under Manage Jenkins → Security → Authorization. Selecting one of those strategies is the step most easily missed: without it, windows get approved and then have no effect at all. An administrative monitor detects the mismatch and offers to install the matching strategy in place of a plain matrix-auth or role-strategy configuration.

Turning this switch off is a kill switch, and it is abrupt. While it is off no window confers anything, so every permission decision is the installed strategy's own logic alone, exactly as before the plugin was installed. Turning it off also revokes every window that is open at that moment, writing one revocation record per closure naming the account that flipped it, so anyone part-way through a change loses the permission to finish and needs a new window once the control is back on. No new window can be requested or approved while it is off either, and the Grants screen is closed, so nothing is left to take effect unreviewed when it is turned back on.

Nothing is removed from the audit trail. The Change Records and History screens keep showing the windows that existed and the changes made under them whether this switch is on or off.