After defining the required stages and adding jobs and tasks to them, it is time to configure when the release to a specific stage should be triggered. The steps for this can be seen in the following screenshot:

Note that the following steps need to be carried out for every stage individually:   

1. To trigger a release to a specific stage, click on the button with a lightning bolt and a person icon, to the left of the square that denotes the stage.
2. The first thing to configure here is when a release should propagate to this stage. This can be either upon the availability of the release, after completing another stage, or only upon manual request. The choice you make here will also be reflected in the visual representation of the pipeline.
3. Separate from the trigger, it is possible to define one or more filters that limit which artifacts will trigger a deployment to the stage. There can be one or more include or exclude branch filters for every artifact.
4. It is also possible to redeploy on a fixed schedule.
5. Finally, if the creation of a new release is specified for builds that were started from a pull request, the release can also be allowed to propagate to the current stage using the slider.

Next to these triggers, approvers and gates can be added so that you can configure how to handle deployment queue settings. These settings can be accessed from the tabs below the section for Triggers, as shown in the following screenshot:

The first tab is about approvers. Here, groups or users are specified. They must give their approval before releasing to this stage can begin. Multiple people can be added and if so, an order can be defined in which they have to approve or it can be specified that a single approval is enough. By scrolling down, you will find the following options:

The second tab (on the left) allows you to add one or more gates. Gates are automated checks that have to succeed before the release can continue. Currently, this shows the configuration details for configuring a work item query and a threshold on the number of results, for example, to ensure that there are no open bugs before a release proceeds. There are also gates available that can call in Azure Monitor, Azure Functions, or a RESTful API. This set of gates can be extended using the Azure DevOps extension mechanisms. Some of these extensions also integrate with common change management systems.

The final tab (on the right) allows you to configure how to handle a situation where different versions of the release are ready for deployment to the same stage. Here, it is possible to specify how many releases can run in parallel. If there are even more releases coming in, you can queue them up and deploy them one after the other, or only deploy the latest.