If checked — and while Enable run control is on globally — a person cannot start this job directly. The build button, /build, /buildWithParameters, the CLI build command, Pipeline Replay, Rebuild and a clicked Retry are all refused unless an approved run request is being used; the request form is on this job's sidebar as Request Run for users who hold Batch Control/Request and Job/Read on the job. Job/Build is not needed to request; the approver sees when the requester lacks it.

This box governs manual runs only. Unattended runs — cron (timer), upstream, SCM, automatic retries and runs started by scripts — are decided by the job's activation, whatever this box says: while run control is on, an unattended run starts only if the job is activated, and then only as far as Block cron (timer) triggers and Block upstream triggers below allow. Unchecking this box, unchecking those switches or removing Batch Control from the job never puts a job into service; an approved activation request does. The job page shows whether the job is activated and links to the activation request form.

A job created while run control is on starts not activated, with this box and both trigger switches on and the allowed-upstream list empty, whoever created it and however (web form, config.xml POST, CLI create-job, Job DSL seed or a copy). To put it into service, request its activation from the job page; to let its cron or upstream triggers through as well, uncheck the matching switch. Jobs that already existed when run control was turned on were recorded as activated and keep their schedule.

A build that is already running is never interrupted; refusal happens when a run is queued. Changing this box is a recorded configuration change and, with change control on, needs a permission window.