diff --git a/doc/api/pipeline_triggers.md b/doc/api/pipeline_triggers.md
index 8db071bf811479b5a61b41b7b95d76e7271c4dc7..9f3120bd5d713aa755bcc59b08011752334c5f4b 100644
--- a/doc/api/pipeline_triggers.md
+++ b/doc/api/pipeline_triggers.md
@@ -155,7 +155,7 @@ or a [CI/CD job token](../ci/jobs/ci_job_token.md) for authentication.
 
 With a CI/CD job token, the [triggered pipeline is a multi-project pipeline](../ci/jobs/ci_job_token.md#trigger-a-multi-project-pipeline-by-using-a-cicd-job-token).
 The job that authenticates the request becomes associated with the upstream pipeline,
-which is visible on the [pipeline graph](../ci/pipelines/multi_project_pipelines.md#multi-project-pipeline-visualization).
+which is visible on the [pipeline graph](../ci/pipelines/downstream_pipelines.md#view-multi-project-pipelines-in-pipeline-graphs).
 
 If you use a trigger token in a job, the job is not associated with the upstream pipeline.
 
diff --git a/doc/ci/environments/deployment_safety.md b/doc/ci/environments/deployment_safety.md
index 5b2e2045bdc50f5af3ed89f0192e3608ce81644b..788061b29558f72d5b7571c3284e5f8bd07167cc 100644
--- a/doc/ci/environments/deployment_safety.md
+++ b/doc/ci/environments/deployment_safety.md
@@ -131,7 +131,7 @@ All users with the Maintainer role for the project have access to production sec
 that can deploy to a production environment, you can create a separate project and configure a new
 permission model that isolates the CD permissions from the original project and prevents the
 original users with the Maintainer role for the project from accessing the production secret and CD configuration. You can
-connect the CD project to your development projects by using [multi-project pipelines](../pipelines/multi_project_pipelines.md).
+connect the CD project to your development projects by using [multi-project pipelines](../pipelines/downstream_pipelines.md#multi-project-pipelines).
 
 ## Protect `.gitlab-ci.yml` from change
 
diff --git a/doc/ci/jobs/job_control.md b/doc/ci/jobs/job_control.md
index b45929fd78f4dcdd65c52db349f66af38d1311c7..217d12e4c267f2e53832ce7d51872ee2a9138580 100644
--- a/doc/ci/jobs/job_control.md
+++ b/doc/ci/jobs/job_control.md
@@ -244,7 +244,7 @@ check the value of the `$CI_PIPELINE_SOURCE` variable:
 | `external_pull_request_event` | When an external pull request on GitHub is created or updated. See [Pipelines for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests).                                            |
 | `merge_request_event`         | For pipelines created when a merge request is created or updated. Required to enable [merge request pipelines](../pipelines/merge_request_pipelines.md), [merged results pipelines](../pipelines/merged_results_pipelines.md), and [merge trains](../pipelines/merge_trains.md). |
 | `parent_pipeline`             | For pipelines triggered by a [parent/child pipeline](../pipelines/parent_child_pipelines.md) with `rules`. Use this pipeline source in the child pipeline configuration so that it can be triggered by the parent pipeline.                |
-| `pipeline`                    | For [multi-project pipelines](../pipelines/multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../pipelines/multi_project_pipelines.md#create-multi-project-pipelines-by-using-the-api), or the [`trigger`](../yaml/index.md#trigger) keyword. |
+| `pipeline`                    | For [multi-project pipelines](../pipelines/downstream_pipelines.md#multi-project-pipelines) created by [using the API with `CI_JOB_TOKEN`](../pipelines/downstream_pipelines.md#trigger-a-multi-project-pipeline-by-using-the-api), or the [`trigger`](../yaml/index.md#trigger) keyword. |
 | `push`                        | For pipelines triggered by a `git push` event, including for branches and tags.                                                                                                                                                  |
 | `schedule`                    | For [scheduled pipelines](../pipelines/schedules.md).                                                                                                                                                                            |
 | `trigger`                     | For pipelines created by using a [trigger token](../triggers/index.md#configure-cicd-jobs-to-run-in-triggered-pipelines).                                                                                                                                           |
diff --git a/doc/ci/pipelines/downstream_pipelines.md b/doc/ci/pipelines/downstream_pipelines.md
index d92a632fce3cece6f67d568e1c0e7241d0032901..4fc7adfaae3c199f2cfa59ba5f4905a5d2a1b3ac 100644
--- a/doc/ci/pipelines/downstream_pipelines.md
+++ b/doc/ci/pipelines/downstream_pipelines.md
@@ -11,7 +11,7 @@ A downstream pipeline can be either:
 
 - A [parent-child pipeline](parent_child_pipelines.md), which is a downstream pipeline triggered
   in the same project as the first pipeline.
-- A [multi-project pipeline](multi_project_pipelines.md), which is a downstream pipeline triggered
+- A [multi-project pipeline](#multi-project-pipelines), which is a downstream pipeline triggered
   in a different project than the first pipeline.
 
 Parent-child pipelines and multi-project pipelines can sometimes be used for similar purposes,
@@ -46,6 +46,132 @@ Multi-project pipelines:
   that happened to be triggered by an external project. They are all visible on the pipeline index page.
 - Are independent, so there are no nesting limits.
 
+## Multi-project pipelines
+
+> [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 downstream 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.
+Each project has its own build, test, and deploy process. With multi-project pipelines you can
+visualize the entire pipeline, including all build and test stages for all three projects.
+
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+For an overview, see the [Multi-project pipelines demo](https://www.youtube.com/watch?v=g_PIwBM1J84).
+
+Multi-project pipelines are also useful for larger products that require cross-project interdependencies, like those
+with a [microservices architecture](https://about.gitlab.com/blog/2016/08/16/trends-in-version-control-land-microservices/).
+Learn more in the [Cross-project Pipeline Triggering and Visualization demo](https://about.gitlab.com/learn/)
+at GitLab@learn, in the Continuous Integration section.
+
+If you trigger a pipeline in a downstream private project, on the upstream project's pipelines page,
+you can view:
+
+- The name of the project.
+- The status of the pipeline.
+
+If you have a public project that can trigger downstream pipelines in a private project,
+make sure there are no confidentiality problems.
+
+### Trigger a multi-project pipeline from a job in your `.gitlab-ci.yml` file
+
+> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
+
+When you use the [`trigger`](../yaml/index.md#trigger) keyword to create a multi-project
+pipeline in your `.gitlab-ci.yml` file, you create what is called a *trigger job*. For example:
+
+```yaml
+rspec:
+  stage: test
+  script: bundle exec rspec
+
+staging:
+  variables:
+    ENVIRONMENT: staging
+  stage: deploy
+  trigger: my/deployment
+```
+
+In this example, after the `rspec` job succeeds in the `test` stage,
+the `staging` trigger job starts. The initial status of this
+job is `pending`.
+
+GitLab then creates a downstream pipeline in the
+`my/deployment` project and, as soon as the pipeline is created, 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-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,
+or the user does not have [permission](../../user/permissions.md) to create a pipeline there,
+the `staging` job is marked as _failed_.
+
+#### Specify a downstream pipeline branch
+
+You can specify a branch name for the downstream pipeline to use.
+GitLab uses the commit on the head of the branch to
+create the downstream pipeline.
+
+```yaml
+rspec:
+  stage: test
+  script: bundle exec rspec
+
+staging:
+  stage: deploy
+  trigger:
+    project: my/deployment
+    branch: stable-11-2
+```
+
+Use:
+
+- The `project` keyword to specify the full path to a downstream project.
+  In [GitLab 15.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/367660), variable expansion is
+  supported.
+- The `branch` keyword to specify the name of a branch in the project specified by `project`.
+  In [GitLab 12.4 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/10126), variable expansion is
+  supported.
+
+Pipelines triggered on a protected branch in a downstream project use the [role](../../user/permissions.md)
+of the user that ran the trigger job in the upstream project. If the user does not
+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).
+
+#### Use `rules` or `only`/`except` with multi-project pipelines
+
+You can use CI/CD variables or the [`rules`](../yaml/index.md#rulesif) keyword to
+[control job behavior](../jobs/job_control.md) for multi-project pipelines. When a
+downstream pipeline is triggered with the [`trigger`](../yaml/index.md#trigger) keyword,
+the value of the [`$CI_PIPELINE_SOURCE` predefined variable](../variables/predefined_variables.md)
+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.
+
+### Trigger a multi-project pipeline by using the API
+
+> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/31573) to GitLab Free in 12.4.
+
+When you use the [`CI_JOB_TOKEN` to trigger pipelines](../jobs/ci_job_token.md),
+GitLab recognizes the source of the job token. The pipelines become related,
+so you can visualize their relationships on pipeline graphs.
+
+These relationships are displayed in the pipeline graph by showing inbound and
+outbound connections for upstream and downstream pipeline dependencies.
+
+When using:
+
+- CI/CD variables or [`rules`](../yaml/index.md#rulesif) to control job behavior, the value of
+  the [`$CI_PIPELINE_SOURCE` predefined variable](../variables/predefined_variables.md) is
+  `pipeline` for multi-project pipeline triggered through the API with `CI_JOB_TOKEN`.
+- [`only/except`](../yaml/index.md#only--except) to control job behavior, use the
+  `pipelines` keyword.
+
 ## View a downstream pipeline
 
 In the [pipeline graph view](index.md#view-full-pipeline-graph), downstream pipelines display
@@ -86,6 +212,108 @@ trigger_job:
     strategy: depend
 ```
 
+### View multi-project pipelines in pipeline graphs **(PREMIUM)**
+
+When you trigger a multi-project pipeline, the downstream pipeline displays
+to the right of the [pipeline graph](index.md#visualize-pipelines).
+
+![Multi-project pipeline graph](img/multi_project_pipeline_graph_v14_3.png)
+
+In [pipeline mini graphs](index.md#pipeline-mini-graphs), the downstream pipeline
+displays to the right of the mini graph.
+
+![Multi-project pipeline mini graph](img/pipeline_mini_graph_v15_0.png)
+
+## Pass artifacts to a downstream pipeline
+
+You can pass artifacts to a downstream pipeline by using [`needs:project`](../yaml/index.md#needsproject).
+
+1. In a job in the upstream pipeline, save the artifacts using the [`artifacts`](../yaml/index.md#artifacts) keyword.
+1. Trigger the downstream pipeline with a trigger job:
+
+   ```yaml
+   build_artifacts:
+     stage: build
+     script:
+       - echo "This is a test artifact!" >> artifact.txt
+     artifacts:
+       paths:
+         - artifact.txt
+
+   deploy:
+     stage: deploy
+     trigger: my/downstream_project
+   ```
+
+1. In a job in the downstream pipeline, fetch the artifacts from the upstream pipeline
+   by using `needs:project`. Set `job` to the job in the upstream pipeline to fetch artifacts from,
+   `ref` to the branch, and `artifacts: true`.
+
+   ```yaml
+   test:
+     stage: test
+     script:
+       - cat artifact.txt
+     needs:
+       - project: my/upstream_project
+         job: build_artifacts
+         ref: main
+         artifacts: true
+   ```
+
+### Pass artifacts from a Merge Request pipeline
+
+When you use `needs:project` to [pass artifacts to a downstream pipeline](#pass-artifacts-to-a-downstream-pipeline),
+the `ref` value is usually a branch name, like `main` or `development`.
+
+For merge request pipelines, the `ref` value is in the form of `refs/merge-requests/<id>/head`,
+where `id` is the merge request ID. You can retrieve this ref with the [`CI_MERGE_REQUEST_REF_PATH`](../variables/predefined_variables.md#predefined-variables-for-merge-request-pipelines)
+CI/CD variable. Do not use a branch name as the `ref` with merge request pipelines,
+because the downstream pipeline attempts to fetch artifacts from the latest branch pipeline.
+
+To fetch the artifacts from the upstream `merge request` pipeline instead of the `branch` pipeline,
+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-yaml-defined-cicd-variables):
+
+   ```yaml
+   build_artifacts:
+     stage: build
+     script:
+       - echo "This is a test artifact!" >> artifact.txt
+     artifacts:
+       paths:
+         - artifact.txt
+
+   upstream_job:
+     variables:
+       UPSTREAM_REF: $CI_MERGE_REQUEST_REF_PATH
+     trigger:
+       project: my/downstream_project
+       branch: my-branch
+   ```
+
+1. In a job in the downstream pipeline, fetch the artifacts from the upstream pipeline
+   by using `needs:project`. Set the `ref` to the `UPSTREAM_REF` variable, and `job`
+   to the job in the upstream pipeline to fetch artifacts from:
+
+   ```yaml
+   test:
+     stage: test
+     script:
+       - cat artifact.txt
+     needs:
+       - project: my/upstream_project
+         job: build_artifacts
+         ref: UPSTREAM_REF
+         artifacts: true
+   ```
+
+This method works for fetching artifacts from a regular merge request parent pipeline,
+but fetching artifacts from [merge results](merged_results_pipelines.md) pipelines is not supported.
+
 ## Pass CI/CD variables to a downstream pipeline
 
 You can pass CI/CD variables to a downstream pipeline with a few different methods,
@@ -96,7 +324,7 @@ based on where the variable is created or defined.
 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):
+For example, in a [multi-project pipeline](#multi-project-pipelines):
 
 ```yaml
 rspec:
@@ -130,7 +358,7 @@ trigger-downstream:
 ### 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):
+For example, in a [multi-project pipeline](#multi-project-pipelines):
 
 ```yaml
 variables:
@@ -150,7 +378,7 @@ In this example, the `MY_GLOBAL_VAR` variable is not available in the triggered
 
 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):
+in a [multi-project pipeline](#multi-project-pipelines):
 
 ```yaml
 downstream-job:
@@ -175,7 +403,7 @@ the ones defined in the upstream project take precedence.
 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):
+For example, in a [multi-project pipeline](#multi-project-pipelines):
 
 1. Save the variables in a `.env` file.
 1. Save the `.env` file as a `dotenv` report.
diff --git a/doc/ci/pipelines/index.md b/doc/ci/pipelines/index.md
index 0b43eff3d2c76fa9039de48420982a3f2278b2ad..59ad47765b1c461ca5843d3cb2015b1562d25a6b 100644
--- a/doc/ci/pipelines/index.md
+++ b/doc/ci/pipelines/index.md
@@ -60,7 +60,7 @@ Pipelines can be configured in many different ways:
 - [Parent-child pipelines](parent_child_pipelines.md) break down complex pipelines
   into one parent pipeline that can trigger multiple child sub-pipelines, which all
   run in the same project and with the same SHA. This pipeline architecture is commonly used for mono-repos.
-- [Multi-project pipelines](multi_project_pipelines.md) combine pipelines for different projects together.
+- [Multi-project pipelines](downstream_pipelines.md#multi-project-pipelines) combine pipelines for different projects together.
 
 ## Configure a pipeline
 
@@ -382,8 +382,8 @@ You can group the jobs by:
 - [Job dependencies](#view-job-dependencies-in-the-pipeline-graph), which arranges
   jobs based on their [`needs`](../yaml/index.md#needs) dependencies.
 
-[Multi-project pipeline graphs](multi_project_pipelines.md#multi-project-pipeline-visualization) help
-you visualize the entire pipeline, including all cross-project inter-dependencies. **(PREMIUM)**
+[Multi-project pipeline graphs](downstream_pipelines.md#view-multi-project-pipelines-in-pipeline-graphs) help
+you visualize the entire pipeline, including all cross-project inter-dependencies.
 
 If a stage contains more than 100 jobs, only the first 100 jobs are listed in the
 pipeline graph. The remaining jobs still run as normal. To see the jobs:
diff --git a/doc/ci/pipelines/multi_project_pipelines.md b/doc/ci/pipelines/multi_project_pipelines.md
index 1664c62f98fc00e412f0470a8f0b724dcbc8417d..824f1445818cc020f0e0cc86d632d7e5ba99bf00 100644
--- a/doc/ci/pipelines/multi_project_pipelines.md
+++ b/doc/ci/pipelines/multi_project_pipelines.md
@@ -1,257 +1,11 @@
 ---
-stage: Verify
-group: Pipeline Authoring
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-type: reference
+redirect_to: 'downstream_pipelines.md'
+remove_date: '2022-11-31'
 ---
 
-# Multi-project pipelines **(FREE)**
+This document was moved to [another location](downstream_pipelines.md).
 
-> [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 [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.
-Each project has its own build, test, and deploy process. With multi-project pipelines you can
-visualize the entire pipeline, including all build and test stages for all three projects.
-
-<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
-For an overview, see the [Multi-project pipelines demo](https://www.youtube.com/watch?v=g_PIwBM1J84).
-
-Multi-project pipelines are also useful for larger products that require cross-project interdependencies, like those
-with a [microservices architecture](https://about.gitlab.com/blog/2016/08/16/trends-in-version-control-land-microservices/).
-Learn more in the [Cross-project Pipeline Triggering and Visualization demo](https://about.gitlab.com/learn/)
-at GitLab@learn, in the Continuous Integration section.
-
-If you trigger a pipeline in a downstream private project, on the upstream project's pipelines page,
-you can view:
-
-- The name of the project.
-- The status of the pipeline.
-
-If you have a public project that can trigger downstream pipelines in a private project,
-make sure there are no confidentiality problems.
-
-## Create multi-project pipelines
-
-To create multi-project pipelines, you can:
-
-- [Define them in your `.gitlab-ci.yml` file](#define-multi-project-pipelines-in-your-gitlab-ciyml-file).
-- [Use the API](#create-multi-project-pipelines-by-using-the-api).
-
-### Define multi-project pipelines in your `.gitlab-ci.yml` file
-
-> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
-
-When you use the [`trigger`](../yaml/index.md#trigger) keyword to create a multi-project
-pipeline in your `.gitlab-ci.yml` file, you create what is called a *trigger job*. For example:
-
-```yaml
-rspec:
-  stage: test
-  script: bundle exec rspec
-
-staging:
-  variables:
-    ENVIRONMENT: staging
-  stage: deploy
-  trigger: my/deployment
-```
-
-In this example, after the `rspec` job succeeds in the `test` stage,
-the `staging` trigger job starts. The initial status of this
-job is `pending`.
-
-GitLab then creates a downstream pipeline in the
-`my/deployment` project and, as soon as the pipeline is created, 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](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,
-or the user does not have [permission](../../user/permissions.md) to create a pipeline there,
-the `staging` job is marked as _failed_.
-
-#### Trigger job configuration limitations
-
-Trigger jobs can use only a limited set of the GitLab CI/CD [configuration keywords](../yaml/index.md).
-The keywords available for use in trigger jobs are:
-
-- [`trigger`](../yaml/index.md#trigger)
-- [`stage`](../yaml/index.md#stage)
-- [`allow_failure`](../yaml/index.md#allow_failure)
-- [`rules`](../yaml/index.md#rules)
-- [`only` and `except`](../yaml/index.md#only--except)
-- [`when`](../yaml/index.md#when) (only with a value of `on_success`, `on_failure`, or `always`)
-- [`extends`](../yaml/index.md#extends)
-- [`needs`](../yaml/index.md#needs), but not [`needs:project`](../yaml/index.md#needsproject)
-
-Trigger jobs cannot use [job-level persisted variables](../variables/where_variables_can_be_used.md#persisted-variables).
-
-#### Specify a downstream pipeline branch
-
-You can specify a branch name for the downstream pipeline to use.
-GitLab uses the commit on the head of the branch to
-create the downstream pipeline.
-
-```yaml
-rspec:
-  stage: test
-  script: bundle exec rspec
-
-staging:
-  stage: deploy
-  trigger:
-    project: my/deployment
-    branch: stable-11-2
-```
-
-Use:
-
-- The `project` keyword to specify the full path to a downstream project.
-  In [GitLab 15.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/367660), variable expansion is
-  supported.
-- The `branch` keyword to specify the name of a branch in the project specified by `project`.
-  In [GitLab 12.4 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/10126), variable expansion is
-  supported.
-
-Pipelines triggered on a protected branch in a downstream project use the [role](../../user/permissions.md)
-of the user that ran the trigger job in the upstream project. If the user does not
-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 artifacts to a downstream pipeline
-
-You can pass artifacts to a downstream pipeline by using [`needs:project`](../yaml/index.md#needsproject).
-
-1. In a job in the upstream pipeline, save the artifacts using the [`artifacts`](../yaml/index.md#artifacts) keyword.
-1. Trigger the downstream pipeline with a trigger job:
-
-   ```yaml
-   build_artifacts:
-     stage: build
-     script:
-       - echo "This is a test artifact!" >> artifact.txt
-     artifacts:
-       paths:
-         - artifact.txt
-
-   deploy:
-     stage: deploy
-     trigger: my/downstream_project
-   ```
-
-1. In a job in the downstream pipeline, fetch the artifacts from the upstream pipeline
-   by using `needs:project`. Set `job` to the job in the upstream pipeline to fetch artifacts from,
-   `ref` to the branch, and `artifacts: true`.
-
-   ```yaml
-   test:
-     stage: test
-     script:
-       - cat artifact.txt
-     needs:
-       - project: my/upstream_project
-         job: build_artifacts
-         ref: main
-         artifacts: true
-   ```
-
-#### Pass artifacts to a downstream pipeline from a Merge Request pipeline
-
-When you use `needs:project` to [pass artifacts to a downstream pipeline](#pass-artifacts-to-a-downstream-pipeline),
-the `ref` value is usually a branch name, like `main` or `development`.
-
-For merge request pipelines, the `ref` value is in the form of `refs/merge-requests/<id>/head`,
-where `id` is the merge request ID. You can retrieve this ref with the [`CI_MERGE_REQUEST_REF_PATH`](../variables/predefined_variables.md#predefined-variables-for-merge-request-pipelines)
-CI/CD variable. Do not use a branch name as the `ref` with merge request pipelines,
-because the downstream pipeline attempts to fetch artifacts from the latest branch pipeline.
-
-To fetch the artifacts from the upstream `merge request` pipeline instead of the `branch` pipeline,
-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](downstream_pipelines.md#pass-yaml-defined-cicd-variables):
-
-   ```yaml
-   build_artifacts:
-     stage: build
-     script:
-       - echo "This is a test artifact!" >> artifact.txt
-     artifacts:
-       paths:
-         - artifact.txt
-
-   upstream_job:
-     variables:
-       UPSTREAM_REF: $CI_MERGE_REQUEST_REF_PATH
-     trigger:
-       project: my/downstream_project
-       branch: my-branch
-   ```
-
-1. In a job in the downstream pipeline, fetch the artifacts from the upstream pipeline
-   by using `needs:project`. Set the `ref` to the `UPSTREAM_REF` variable, and `job`
-   to the job in the upstream pipeline to fetch artifacts from:
-
-   ```yaml
-   test:
-     stage: test
-     script:
-       - cat artifact.txt
-     needs:
-       - project: my/upstream_project
-         job: build_artifacts
-         ref: UPSTREAM_REF
-         artifacts: true
-   ```
-
-This method works for fetching artifacts from a regular merge request parent pipeline,
-but fetching artifacts from [merge results](merged_results_pipelines.md) pipelines is not supported.
-
-#### Use `rules` or `only`/`except` with multi-project pipelines
-
-You can use CI/CD variables or the [`rules`](../yaml/index.md#rulesif) keyword to
-[control job behavior](../jobs/job_control.md) for multi-project pipelines. When a
-downstream pipeline is triggered with the [`trigger`](../yaml/index.md#trigger) keyword,
-the value of the [`$CI_PIPELINE_SOURCE` predefined variable](../variables/predefined_variables.md)
-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.
-
-### Create multi-project pipelines by using the API
-
-> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/31573) to GitLab Free in 12.4.
-
-When you use the [`CI_JOB_TOKEN` to trigger pipelines](../jobs/ci_job_token.md),
-GitLab recognizes the source of the job token. The pipelines become related,
-so you can visualize their relationships on pipeline graphs.
-
-These relationships are displayed in the pipeline graph by showing inbound and
-outbound connections for upstream and downstream pipeline dependencies.
-
-When using:
-
-- CI/CD variables or [`rules`](../yaml/index.md#rulesif) to control job behavior, the value of
-  the [`$CI_PIPELINE_SOURCE` predefined variable](../variables/predefined_variables.md) is
-  `pipeline` for multi-project pipeline triggered through the API with `CI_JOB_TOKEN`.
-- [`only/except`](../yaml/index.md#only--except) to control job behavior, use the
-  `pipelines` keyword.
-
-## Multi-project pipeline visualization **(PREMIUM)**
-
-When your pipeline triggers a downstream pipeline, the downstream pipeline displays
-to the right of the [pipeline graph](index.md#visualize-pipelines).
-
-![Multi-project pipeline graph](img/multi_project_pipeline_graph_v14_3.png)
-
-In [pipeline mini graphs](index.md#pipeline-mini-graphs), the downstream pipeline
-displays to the right of the mini graph.
-
-![Multi-project pipeline mini graph](img/pipeline_mini_graph_v15_0.png)
+<!-- This redirect file can be deleted after <2022-11-31>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/ci/pipelines/parent_child_pipelines.md b/doc/ci/pipelines/parent_child_pipelines.md
index ede90178a3500b8ed217f8d95e015aabfae64a4e..56c51d7b119b046718ae9c453693c9a4edf2ebd5 100644
--- a/doc/ci/pipelines/parent_child_pipelines.md
+++ b/doc/ci/pipelines/parent_child_pipelines.md
@@ -25,7 +25,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
+Similarly to [multi-project pipelines](downstream_pipelines.md#multi-project-pipelines), a pipeline can trigger a
 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
@@ -89,7 +89,7 @@ microservice_a:
 
 The maximum number of entries that are accepted for `trigger:include` is three.
 
-Similar to [multi-project pipelines](multi_project_pipelines.md), we can set the
+Similar to [multi-project pipelines](downstream_pipelines.md#multi-project-pipelines), 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:
 
diff --git a/doc/ci/triggers/index.md b/doc/ci/triggers/index.md
index 2c916ba092cebb97f5932b5f68710145e7475857..7df5c91ce385dfec97cd83c5a133831956780b32 100644
--- a/doc/ci/triggers/index.md
+++ b/doc/ci/triggers/index.md
@@ -13,7 +13,7 @@ to the [pipeline triggers API endpoint](../../api/pipeline_triggers.md).
 When authenticating with the API, you can use:
 
 - A [trigger token](#create-a-trigger-token) to trigger a branch or tag pipeline.
-- A [CI/CD job token](../jobs/ci_job_token.md) to trigger a [multi-project pipeline](../pipelines/multi_project_pipelines.md#create-multi-project-pipelines-by-using-the-api).
+- A [CI/CD job token](../jobs/ci_job_token.md) to [trigger a multi-project pipeline](../pipelines/downstream_pipelines.md#trigger-a-multi-project-pipeline-by-using-the-api).
 
 ## Create a trigger token
 
@@ -169,7 +169,7 @@ To [configure when to run jobs](../jobs/job_control.md) in triggered pipelines:
 | `$CI_PIPELINE_SOURCE` value | `only`/`except` keywords | Trigger method      |
 |-----------------------------|--------------------------|---------------------|
 | `trigger`                   | `triggers`               | In pipelines triggered with the [pipeline triggers API](../../api/pipeline_triggers.md) by using a [trigger token](#create-a-trigger-token). |
-| `pipeline`                  | `pipelines`              | In [multi-project pipelines](../pipelines/multi_project_pipelines.md#create-multi-project-pipelines-by-using-the-api) triggered with the [pipeline triggers API](../../api/pipeline_triggers.md) by using the [`$CI_JOB_TOKEN`](../jobs/ci_job_token.md), or by using the [`trigger`](../yaml/index.md#trigger) keyword in the CI/CD configuration file. |
+| `pipeline`                  | `pipelines`              | In [multi-project pipelines](../pipelines/downstream_pipelines.md#trigger-a-multi-project-pipeline-by-using-the-api) triggered with the [pipeline triggers API](../../api/pipeline_triggers.md) by using the [`$CI_JOB_TOKEN`](../jobs/ci_job_token.md), or by using the [`trigger`](../yaml/index.md#trigger) keyword in the CI/CD configuration file. |
 
 Additionally, the `$CI_PIPELINE_TRIGGERED` predefined CI/CD variable is set to `true`
 in pipelines triggered with a trigger token.
diff --git a/doc/ci/troubleshooting.md b/doc/ci/troubleshooting.md
index 287594902b22f7db03e40982e5226d2992200721..34bd0602ca55cd764ca7c222edac66935bb26f4a 100644
--- a/doc/ci/troubleshooting.md
+++ b/doc/ci/troubleshooting.md
@@ -87,7 +87,7 @@ and [templates](examples/index.md#cicd-templates).
 Some pipeline types have their own detailed usage guides that you should read
 if you are using that type:
 
-- [Multi-project pipelines](pipelines/multi_project_pipelines.md): Have your pipeline trigger
+- [Multi-project pipelines](pipelines/downstream_pipelines.md#multi-project-pipelines): Have your pipeline trigger
   a pipeline in a different project.
 - [Parent/child pipelines](pipelines/parent_child_pipelines.md): Have your main pipeline trigger
   and run separate pipelines in the same project. You can also
diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md
index 6f6ac2421ec847c6e45abd1dd3fad9a97e1c3a8c..a5d881b6864d5a0fb7f584c5ad01234817a7d8a5 100644
--- a/doc/ci/yaml/index.md
+++ b/doc/ci/yaml/index.md
@@ -2469,7 +2469,7 @@ when to add jobs to pipelines.
   | `external`               | When you use CI services other than GitLab. |
   | `external_pull_requests` | When an external pull request on GitHub is created or updated (See [Pipelines for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests)). |
   | `merge_requests`         | For pipelines created when a merge request is created or updated. Enables [merge request pipelines](../pipelines/merge_request_pipelines.md), [merged results pipelines](../pipelines/merged_results_pipelines.md), and [merge trains](../pipelines/merge_trains.md). |
-  | `pipelines`              | For [multi-project pipelines](../pipelines/multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../pipelines/multi_project_pipelines.md#create-multi-project-pipelines-by-using-the-api), or the [`trigger`](#trigger) keyword. |
+  | `pipelines`              | For [multi-project pipelines](../pipelines/downstream_pipelines.md#multi-project-pipelines) created by [using the API with `CI_JOB_TOKEN`](../pipelines/downstream_pipelines.md#trigger-a-multi-project-pipeline-by-using-the-api), or the [`trigger`](#trigger) keyword. |
   | `pushes`                 | For pipelines triggered by a `git push` event, including for branches and tags. |
   | `schedules`              | For [scheduled pipelines](../pipelines/schedules.md). |
   | `tags`                   | When the Git reference for a pipeline is a tag. |
@@ -3877,18 +3877,31 @@ 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](../pipelines/downstream_pipelines.md) that is either:
+Use `trigger` to declare that a job is a "trigger job" which starts a
+[downstream pipeline](../pipelines/downstream_pipelines.md) that is either:
 
-- [A multi-project pipeline](../pipelines/multi_project_pipelines.md).
+- [A multi-project pipeline](../pipelines/downstream_pipelines.md#multi-project-pipelines).
 - [A child pipeline](../pipelines/parent_child_pipelines.md).
 
+Trigger jobs can use only a limited set of the GitLab CI/CD configuration keywords.
+The keywords available for use in trigger jobs are:
+
+- [`trigger`](#trigger).
+- [`stage`](#stage).
+- [`allow_failure`](#allow_failure).
+- [`rules`](#rules).
+- [`only` and `except`](#only--except).
+- [`when`](#when) (only with a value of `on_success`, `on_failure`, or `always`).
+- [`extends`](#extends).
+- [`needs`](#needs), but not [`needs:project`](#needsproject).
+
 **Keyword type**: Job keyword. You can use it only as part of a job.
 
 **Possible inputs**:
 
 - For multi-project pipelines, path to the downstream project. CI/CD variables
   [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file)
-  in GitLab 15.3 and later.
+  in GitLab 15.3 and later, but not [job-level persisted variables](../variables/where_variables_can_be_used.md#persisted-variables).
 - For child pipelines, path to the child pipeline CI/CD configuration file.
 
 **Example of `trigger` for multi-project pipeline**:
@@ -3913,9 +3926,6 @@ trigger_job:
 
 **Additional details**:
 
-- Jobs with `trigger` can only use a [limited set of keywords](../pipelines/multi_project_pipelines.md#define-multi-project-pipelines-in-your-gitlab-ciyml-file).
-  For example, you can't run commands with [`script`](#script), [`before_script`](#before_script),
-  or [`after_script`](#after_script). Also, [`environment`](#environment) is not supported with `trigger`.
 - You [cannot use the API to start `when:manual` trigger jobs](https://gitlab.com/gitlab-org/gitlab/-/issues/284086).
 - In [GitLab 13.5 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/201938), you
   can use [`when:manual`](#when) in the same job as `trigger`. In GitLab 13.4 and
@@ -3931,7 +3941,7 @@ trigger_job:
 
 **Related topics**:
 
-- [Multi-project pipeline configuration examples](../pipelines/multi_project_pipelines.md#define-multi-project-pipelines-in-your-gitlab-ciyml-file).
+- [Multi-project pipeline configuration examples](../pipelines/downstream_pipelines.md#trigger-a-multi-project-pipeline-from-a-job-in-your-gitlab-ciyml-file).
 - [Child pipeline configuration examples](../pipelines/parent_child_pipelines.md#examples).
 - To run a pipeline for a specific branch, tag, or commit, you can use a [trigger token](../triggers/index.md)
   to authenticate with the [pipeline triggers API](../../api/pipeline_triggers.md).
@@ -3978,7 +3988,7 @@ successfully complete before starting.
 
 Use `trigger:forward` to specify what to forward to the downstream pipeline. You can control
 what is forwarded to both [parent-child pipelines](../pipelines/parent_child_pipelines.md)
-and [multi-project pipelines](../pipelines/multi_project_pipelines.md).
+and [multi-project pipelines](../pipelines/downstream_pipelines.md#multi-project-pipelines).
 
 **Possible inputs**:
 
diff --git a/doc/development/documentation/review_apps.md b/doc/development/documentation/review_apps.md
index 8cb9e6437b810faff31fa694a9a8975119684ed5..a50efceb307de2dfda410edca74f45e8eeabf3cb 100644
--- a/doc/development/documentation/review_apps.md
+++ b/doc/development/documentation/review_apps.md
@@ -57,7 +57,7 @@ If you want to know the in-depth details, here's what's really happening:
 The following GitLab features are used among others:
 
 - [Manual jobs](../../ci/jobs/job_control.md#create-a-job-that-must-be-run-manually)
-- [Multi project pipelines](../../ci/pipelines/multi_project_pipelines.md)
+- [Multi project pipelines](../../ci/pipelines/downstream_pipelines.md#multi-project-pipelines)
 - [Review Apps](../../ci/review_apps/index.md)
 - [Artifacts](../../ci/yaml/index.md#artifacts)
 - [Specific runner](../../ci/runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects)