The two ways to author a pipeline, how environment approval works, and where long-running work shows up.
Pipelines and jobs
Two ways to author a pipeline
Both write the same thing and behave identically once created — choosing between them is purely a question of how you would rather describe the pipeline.
The guided form ("+ Create pipeline" on Pipelines) is the default. Pick a connection, pick a shape, fill in the references. It covers the common case with far less input.
The visual builder ("Open visual builder") is a full-page drag-and-drop canvas for a pipeline whose shape does not fit the guided form's fixed options.
The builder is a kept, secondary path — not a preview, and not a replacement for the form.
Environments can require two people
Triggering a run against a Production environment does not start it. The run is created as
PENDING_APPROVAL, and a different eligible approver must approve it — the person who triggered
it cannot approve their own run. Eligibility can come from a named person, a named team or the
approve-production-runs permission; it is not tied to the literal admin role.
Production always requires approval. An administrator can also turn approval on for any other environment from Organization → Projects → Manage → Approvals, and can name approvers at the environment or project level. An environment-specific list wins, then the project's list, then anyone in the organization holding the approval permission.
Approving and rejecting are both atomic, so two admins deciding at the same moment cannot double-start a build. A rejection takes a reason, which is kept with the run.
Pipelines lists every deployment awaiting a decision that you are eligible to make, across every project — so an approval never depends on somebody knowing which project to look in. This deployment queue is separate from Approvals, which handles configured approval for other kinds of platform and infrastructure change.
Approvals also raise a notification to every admin. If you never see them, check your per-type notification settings in the bell menu: every type is muted by default and opted into.
Jobs
Anything that might outlive a single request runs as a background job — cross-region copies, disaster-recovery scans, architecture scans, backups and restores, Lambda clones.
Jobs lists all of them with status and kind filters, and refreshes on its own while anything is still running. A job you started notifies you when it finishes, either way.
If a job failed, its detail is the place to look first: the error is the provider's own, kept verbatim, because a provider's error message is usually the useful part.
Runs that never start
A few refusals are worth recognising, since each has a different fix:
"requires approval" — expected on Production. Find an admin who is not you.
A limit refusal — the organization is at a plan ceiling. See Organization, branding, plans and billing.
A role or environment refusal — you can reach the project but not that environment. See Roles and access.
A connection refusal — the stored credential no longer authenticates. Test it from Connectors.