Triggers (a job's header button) chains jobs by outcome: "when this job reaches status X, run that job." Pick a target job and a status (Succeeded by default), click Add -- the target job starts the moment the source job actually reaches that status, through the same queue a manual Run click uses. The dialog also lists incoming triggers -- other jobs already set up to start this one, so you can see both directions from either job.

What counts as "finishes"

Only a real, completed job run fires a trigger -- never an ad-hoc "Run Selected" single-step test. A job can have any number of outgoing triggers, each watching for a different status (Succeeded, Failed, and so on), and any number of jobs can each independently trigger the same downstream job.

Avoid a cycle

Chaining several jobs together works fine, but nothing detects a cycle -- Job A triggering Job B triggering Job A on the same status would just keep re-firing. Nothing stops you from wiring that up, so don't.

Not the same as a Job-Status Gate

A Job Trigger starts a new run of a different job once one job finishes. A Job-Status gate instead pauses or stops an already-running job/step while it waits on a different job's most recent outcome -- see Gates. One starts something new, the other blocks something already in progress.

See also: Glossary for related terms.