diff --git a/doc/ci/pipelines/downstream_pipelines.md b/doc/ci/pipelines/downstream_pipelines.md
index 224b171625fc20632d95afb5bd4f646ab3f9d458..d92a632fce3cece6f67d568e1c0e7241d0032901 100644
--- a/doc/ci/pipelines/downstream_pipelines.md
+++ b/doc/ci/pipelines/downstream_pipelines.md
@@ -51,15 +51,162 @@ Multi-project pipelines:
 In the [pipeline graph view](index.md#view-full-pipeline-graph), downstream pipelines display
 as a list of cards on the right of the graph.
 
-### Cancel or retry downstream pipelines from the graph view
+### Retry a downstream pipeline
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/354974) in GitLab 15.0 [with a flag](../../administration/feature_flags.md) named `downstream_retry_action`. Disabled by default.
-> - [Generally available and feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/357406) in GitLab 15.1.
+> - Retry from graph view [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/354974) in GitLab 15.0 [with a flag](../../administration/feature_flags.md) named `downstream_retry_action`. Disabled by default.
+> - Retry from graph view [generally available and feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/357406) in GitLab 15.1.
 
-To cancel a downstream pipeline that is still running, select **Cancel** (**{cancel}**)
-on the pipeline's card.
+To retry a completed downstream pipeline, select **Retry** (**{retry}**):
 
-To retry a failed downstream pipeline, select **Retry** (**{retry}**)
-on the pipeline's card.
+- From the downstream pipeline's details page.
+- On the pipeline's card in the [pipeline graph view](index.md#view-full-pipeline-graph).
 
-![downstream pipeline actions](img/downstream_pipeline_actions.png)
+### Cancel a downstream pipeline
+
+> - Retry from graph view [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/354974) in GitLab 15.0 [with a flag](../../administration/feature_flags.md) named `downstream_retry_action`. Disabled by default.
+> - Retry from graph view [generally available and feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/357406) in GitLab 15.1.
+
+To cancel a downstream pipeline that is still running, select **Cancel** (**{cancel}**):
+
+- From the downstream pipeline's details page.
+- On the pipeline's card in the [pipeline graph view](index.md#view-full-pipeline-graph).
+
+### Mirror the status of a downstream pipeline in the trigger job
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/11238) in GitLab Premium 12.3.
+> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
+
+You can mirror the pipeline status from the triggered pipeline to the source trigger job
+by using [`strategy: depend`](../yaml/index.md#triggerstrategy). For example:
+
+```yaml
+trigger_job:
+  trigger:
+    project: my/project
+    strategy: depend
+```
+
+## Pass CI/CD variables to a downstream pipeline
+
+You can pass CI/CD variables to a downstream pipeline with a few different methods,
+based on where the variable is created or defined.
+
+### Pass YAML-defined CI/CD variables
+
+You can use the `variables` keyword to pass CI/CD variables to a downstream pipeline,
+just like you would for any other job.
+
+For example, in a [multi-project pipeline](multi_project_pipelines.md):
+
+```yaml
+rspec:
+  stage: test
+  script: bundle exec rspec
+
+staging:
+  variables:
+    ENVIRONMENT: staging
+  stage: deploy
+  trigger: my/deployment
+```
+
+The `ENVIRONMENT` variable is passed to every job defined in a downstream
+pipeline. It is available as a variable when GitLab Runner picks a job.
+
+In the following configuration, the `MY_VARIABLE` variable is passed to the downstream pipeline
+that is created when the `trigger-downstream` job is queued. This is because `trigger-downstream`
+job inherits variables declared in global variables blocks, and then we pass these variables to a downstream pipeline.
+
+```yaml
+variables:
+  MY_VARIABLE: my-value
+
+trigger-downstream:
+  variables:
+    ENVIRONMENT: something
+  trigger: my/project
+```
+
+### Prevent global variables from being passed
+
+You can stop global variables from reaching the downstream pipeline by using the [`inherit:variables` keyword](../yaml/index.md#inheritvariables).
+For example, in a [multi-project pipeline](multi_project_pipelines.md):
+
+```yaml
+variables:
+  MY_GLOBAL_VAR: value
+
+trigger-downstream:
+  inherit:
+    variables: false
+  variables:
+    MY_LOCAL_VAR: value
+  trigger: my/project
+```
+
+In this example, the `MY_GLOBAL_VAR` variable is not available in the triggered pipeline.
+
+### Pass a predefined variable
+
+You might want to pass some information about the upstream pipeline using predefined variables.
+To do that, you can use interpolation to pass any variable. For example,
+in a [multi-project pipeline](multi_project_pipelines.md):
+
+```yaml
+downstream-job:
+  variables:
+    UPSTREAM_BRANCH: $CI_COMMIT_REF_NAME
+  trigger: my/project
+```
+
+In this scenario, the `UPSTREAM_BRANCH` variable with the value of the upstream pipeline's
+`$CI_COMMIT_REF_NAME` is passed to `downstream-job`. It is available in the
+context of all downstream builds.
+
+You cannot use this method to forward [job-level persisted variables](../variables/where_variables_can_be_used.md#persisted-variables)
+to a downstream pipeline, as they are not available in trigger jobs.
+
+Upstream pipelines take precedence over downstream ones. If there are two
+variables with the same name defined in both upstream and downstream projects,
+the ones defined in the upstream project take precedence.
+
+### Pass dotenv variables created in a job **(PREMIUM)**
+
+You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](../variables/index.md#pass-an-environment-variable-to-another-job)
+and [`needs:project`](../yaml/index.md#needsproject).
+
+For example, in a [multi-project pipeline](multi_project_pipelines.md):
+
+1. Save the variables in a `.env` file.
+1. Save the `.env` file as a `dotenv` report.
+1. Trigger the downstream pipeline.
+
+   ```yaml
+   build_vars:
+     stage: build
+     script:
+       - echo "BUILD_VERSION=hello" >> build.env
+     artifacts:
+       reports:
+         dotenv: build.env
+
+   deploy:
+     stage: deploy
+     trigger: my/downstream_project
+   ```
+
+1. Set the `test` job in the downstream pipeline to inherit the variables from the `build_vars`
+   job in the upstream project with `needs`. The `test` job inherits the variables in the
+   `dotenv` report and it can access `BUILD_VERSION` in the script:
+
+   ```yaml
+   test:
+     stage: test
+     script:
+       - echo $BUILD_VERSION
+     needs:
+       - project: my/upstream_project
+         job: build_vars
+         ref: master
+         artifacts: true
+   ```
diff --git a/doc/ci/pipelines/img/downstream_pipeline_actions.png b/doc/ci/pipelines/img/downstream_pipeline_actions.png
deleted file mode 100644
index 4c4384bab57b76c79410f7e67350c45ee3a2e45d..0000000000000000000000000000000000000000
Binary files a/doc/ci/pipelines/img/downstream_pipeline_actions.png and /dev/null differ
diff --git a/doc/ci/pipelines/multi_project_pipelines.md b/doc/ci/pipelines/multi_project_pipelines.md
index e7d5e3e102a6fb88c8cd61213cba48da2026bafd..3fb720cfb814e6a9c3fe93b6f17396703b6f07de 100644
--- a/doc/ci/pipelines/multi_project_pipelines.md
+++ b/doc/ci/pipelines/multi_project_pipelines.md
@@ -10,7 +10,7 @@ type: reference
 > [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
 
 You can set up [GitLab CI/CD](../index.md) across multiple projects, so that a pipeline
-in one project can trigger a pipeline in another project. You can visualize the entire pipeline
+in one project can trigger a [downstream](downstream_pipelines.md) pipeline in another project. You can visualize the entire pipeline
 in one place, including all cross-project interdependencies.
 
 For example, you might deploy your web application from three different projects in GitLab.
@@ -69,7 +69,7 @@ GitLab then creates a downstream pipeline in the
 `staging` job succeeds. The full path to the project is `my/deployment`.
 
 You can view the status for the pipeline, or you can display
-[the downstream pipeline's status instead](#mirror-status-of-a-triggered-pipeline-in-the-trigger-job).
+[the downstream pipeline's status instead](downstream_pipelines.md#mirror-the-status-of-a-downstream-pipeline-in-the-trigger-job).
 
 The user that creates the upstream pipeline must be able to create pipelines in the
 downstream project (`my/deployment`) too. If the downstream project is not found,
@@ -124,117 +124,6 @@ of the user that ran the trigger job in the upstream project. If the user does n
 have permission to run CI/CD pipelines against the protected branch, the pipeline fails. See
 [pipeline security for protected branches](index.md#pipeline-security-on-protected-branches).
 
-#### Pass CI/CD variables to a downstream pipeline by using the `variables` keyword
-
-Sometimes you might want to pass CI/CD variables to a downstream pipeline.
-You can do that by using the `variables` keyword, just like you would for any other job.
-
-```yaml
-rspec:
-  stage: test
-  script: bundle exec rspec
-
-staging:
-  variables:
-    ENVIRONMENT: staging
-  stage: deploy
-  trigger: my/deployment
-```
-
-The `ENVIRONMENT` variable is passed to every job defined in a downstream
-pipeline. It is available as a variable when GitLab Runner picks a job.
-
-In the following configuration, the `MY_VARIABLE` variable is passed to the downstream pipeline
-that is created when the `trigger-downstream` job is queued. This is because `trigger-downstream`
-job inherits variables declared in global variables blocks, and then we pass these variables to a downstream pipeline.
-
-```yaml
-variables:
-  MY_VARIABLE: my-value
-
-trigger-downstream:
-  variables:
-    ENVIRONMENT: something
-  trigger: my/project
-```
-
-You can stop global variables from reaching the downstream pipeline by using the [`inherit:variables` keyword](../yaml/index.md#inheritvariables).
-In this example, the `MY_GLOBAL_VAR` variable is not available in the triggered pipeline:
-
-```yaml
-variables:
-  MY_GLOBAL_VAR: value
-
-trigger-downstream:
-  inherit:
-    variables: false
-  variables:
-    MY_LOCAL_VAR: value
-  trigger: my/project
-```
-
-You might want to pass some information about the upstream pipeline using, for
-example, predefined variables. In order to do that, you can use interpolation
-to pass any variable. For example:
-
-```yaml
-downstream-job:
-  variables:
-    UPSTREAM_BRANCH: $CI_COMMIT_REF_NAME
-  trigger: my/project
-```
-
-In this scenario, the `UPSTREAM_BRANCH` variable with the value of the upstream pipeline's
-`$CI_COMMIT_REF_NAME` is passed to `downstream-job`. It is available in the
-context of all downstream builds.
-
-You cannot use this method to forward [job-level persisted variables](../variables/where_variables_can_be_used.md#persisted-variables)
-to a downstream pipeline, as they are not available in trigger jobs.
-
-Upstream pipelines take precedence over downstream ones. If there are two
-variables with the same name defined in both upstream and downstream projects,
-the ones defined in the upstream project take precedence.
-
-#### Pass CI/CD variables to a downstream pipeline by using variable inheritance **(PREMIUM)**
-
-You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](../variables/index.md#pass-an-environment-variable-to-another-job) and [`needs:project`](../yaml/index.md#needsproject).
-
-In the upstream pipeline:
-
-1. Save the variables in a `.env` file.
-1. Save the `.env` file as a `dotenv` report.
-1. Trigger the downstream pipeline.
-
-   ```yaml
-   build_vars:
-     stage: build
-     script:
-       - echo "BUILD_VERSION=hello" >> build.env
-     artifacts:
-       reports:
-         dotenv: build.env
-
-   deploy:
-     stage: deploy
-     trigger: my/downstream_project
-   ```
-
-1. Set the `test` job in the downstream pipeline to inherit the variables from the `build_vars`
-   job in the upstream project with `needs`. The `test` job inherits the variables in the
-   `dotenv` report and it can access `BUILD_VERSION` in the script:
-
-   ```yaml
-   test:
-     stage: test
-     script:
-       - echo $BUILD_VERSION
-     needs:
-       - project: my/upstream_project
-         job: build_vars
-         ref: master
-         artifacts: true
-   ```
-
 #### Pass artifacts to a downstream pipeline
 
 You can pass artifacts to a downstream pipeline by using [`needs:project`](../yaml/index.md#needsproject).
@@ -287,7 +176,7 @@ pass this variable to the downstream pipeline using variable inheritance:
 
 1. In a job in the upstream pipeline, save the artifacts using the [`artifacts`](../yaml/index.md#artifacts) keyword.
 1. In the job that triggers the downstream pipeline, pass the `$CI_MERGE_REQUEST_REF_PATH` variable by using
-   [variable inheritance](#pass-cicd-variables-to-a-downstream-pipeline-by-using-the-variables-keyword):
+   [variable inheritance](downstream_pipelines.md#pass-yaml-defined-cicd-variables):
 
    ```yaml
    build_artifacts:
@@ -336,21 +225,6 @@ is `pipeline` for all its jobs.
 If you use [`only/except`](../yaml/index.md#only--except) to control job behavior, use the
 [`pipelines`](../yaml/index.md#onlyrefs--exceptrefs) keyword.
 
-#### Mirror status of a triggered pipeline in the trigger job
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/11238) in GitLab Premium 12.3.
-> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
-
-You can mirror the pipeline status from the triggered pipeline to the source trigger job
-by using [`strategy: depend`](../yaml/index.md#triggerstrategy). For example:
-
-```yaml
-trigger_job:
-  trigger:
-    project: my/project
-    strategy: depend
-```
-
 ### Create multi-project pipelines by using the API
 
 > [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/31573) to GitLab Free in 12.4.
@@ -370,7 +244,7 @@ When using:
 - [`only/except`](../yaml/index.md#only--except) to control job behavior, use the
   `pipelines` keyword.
 
-## Trigger a pipeline when an upstream project is rebuilt **(PREMIUM)**
+### Trigger a pipeline when an upstream project is rebuilt **(PREMIUM)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9045) in GitLab 12.8.
 
@@ -409,11 +283,3 @@ In [pipeline mini graphs](index.md#pipeline-mini-graphs), the downstream pipelin
 displays to the right of the mini graph.
 
 ![Multi-project pipeline mini graph](img/pipeline_mini_graph_v15_0.png)
-
-## Retry or cancel multi-project pipelines
-
-If you have permission to trigger pipelines in the downstream project, you can
-retry or cancel multi-project pipelines:
-
-- [In the main graph view](downstream_pipelines.md#view-a-downstream-pipeline).
-- From the downstream pipeline's details page.
diff --git a/doc/ci/pipelines/parent_child_pipelines.md b/doc/ci/pipelines/parent_child_pipelines.md
index 2d36aaac1f761ffd58fbc303a5ab8ac0c7779f00..ede90178a3500b8ed217f8d95e015aabfae64a4e 100644
--- a/doc/ci/pipelines/parent_child_pipelines.md
+++ b/doc/ci/pipelines/parent_child_pipelines.md
@@ -26,7 +26,7 @@ YAML is dynamically generated.
 ![Parent pipeline graph expanded](img/parent_pipeline_graph_expanded_v14_3.png)
 
 Similarly to [multi-project pipelines](multi_project_pipelines.md), a pipeline can trigger a
-set of concurrently running child pipelines, but within the same project:
+set of concurrently running [downstream](downstream_pipelines.md) child pipelines, but in the same project:
 
 - Child pipelines still execute each of their jobs according to a stage sequence, but
   would be free to continue forward through their stages without waiting for unrelated
@@ -89,8 +89,9 @@ microservice_a:
 
 The maximum number of entries that are accepted for `trigger:include` is three.
 
-Similar to [multi-project pipelines](multi_project_pipelines.md#mirror-status-of-a-triggered-pipeline-in-the-trigger-job),
-we can set the parent pipeline to depend on the status of the child pipeline upon completion:
+Similar to [multi-project pipelines](multi_project_pipelines.md), we can set the
+parent pipeline to [depend on the status](downstream_pipelines.md#mirror-the-status-of-a-downstream-pipeline-in-the-trigger-job)
+of the child pipeline upon completion:
 
 ```yaml
 microservice_a:
@@ -214,15 +215,7 @@ For an overview, see [Nested Dynamic Pipelines](https://youtu.be/C5j3ju9je2M).
 
 ## Pass CI/CD variables to a child pipeline
 
-You can pass CI/CD variables to a downstream pipeline using the same methods as
-multi-project pipelines:
+You can pass variables to a downstream pipeline:
 
-- [By using the `variable` keyword](multi_project_pipelines.md#pass-cicd-variables-to-a-downstream-pipeline-by-using-the-variables-keyword).
-- [By using variable inheritance](multi_project_pipelines.md#pass-cicd-variables-to-a-downstream-pipeline-by-using-variable-inheritance).
-
-## Retry or cancel child pipelines
-
-You can retry or cancel child pipelines:
-
-- [In the main graph view](downstream_pipelines.md#view-a-downstream-pipeline).
-- In the child pipeline's details page.
+- [By using the `variables` keyword](downstream_pipelines.md#pass-yaml-defined-cicd-variables).
+- [By using dotenv variable inheritance](downstream_pipelines.md#pass-dotenv-variables-created-in-a-job).
diff --git a/doc/ci/variables/index.md b/doc/ci/variables/index.md
index 72df8d5681571d773bf8bee9526ae3e4fbd9bc79..e9d4fd8549c1e6cd11e82821db0e387934d1c802 100644
--- a/doc/ci/variables/index.md
+++ b/doc/ci/variables/index.md
@@ -647,7 +647,7 @@ deploy_five:
     artifacts: false
 ```
 
-[Multi-project pipelines](../pipelines/multi_project_pipelines.md#pass-cicd-variables-to-a-downstream-pipeline-by-using-variable-inheritance)
+[Multi-project pipelines](../pipelines/downstream_pipelines.md#pass-dotenv-variables-created-in-a-job)
 can also inherit variables from their upstream pipelines.
 
 ## CI/CD variable precedence
@@ -695,8 +695,8 @@ You can override the value of a variable when you:
 1. Run a job manually in the UI.
 1. Use [push options](../../user/project/push_options.md#push-options-for-gitlab-cicd).
 1. Trigger a pipeline by using [the API](../triggers/index.md#pass-cicd-variables-in-the-api-call).
-1. Pass variables to a downstream pipeline [by using the `variable` keyword](../pipelines/multi_project_pipelines.md#pass-cicd-variables-to-a-downstream-pipeline-by-using-the-variables-keyword)
-   or [by using variable inheritance](../pipelines/multi_project_pipelines.md#pass-cicd-variables-to-a-downstream-pipeline-by-using-variable-inheritance).
+1. Pass variables to a downstream pipeline [by using the `variable` keyword](../pipelines/downstream_pipelines.md#pass-cicd-variables-to-a-downstream-pipeline)
+   or [by using variable inheritance](../pipelines/downstream_pipelines.md#pass-dotenv-variables-created-in-a-job).
 
 The pipeline variables declared in these events take [priority over other variables](#cicd-variable-precedence).
 
diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md
index bbd27a3f070ec585f73956809b961c73f1b4388f..32600a73c0a712d0756c7e8c95c5f957a59e02a4 100644
--- a/doc/ci/yaml/index.md
+++ b/doc/ci/yaml/index.md
@@ -3884,7 +3884,7 @@ test:
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/8997) in GitLab Premium 11.8.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
 
-Use `trigger` to start a downstream pipeline that is either:
+Use `trigger` to start a [downstream pipeline](../pipelines/downstream_pipelines.md) that is either:
 
 - [A multi-project pipeline](../pipelines/multi_project_pipelines.md).
 - [A child pipeline](../pipelines/parent_child_pipelines.md).