> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/use-continuous-delivery/manage-deployments/control-resource-usage-with-queue-steps.md).
# Control resource usage with Queue steps
This topic describes how to use the Queue step to control the access order to the resources Harness requests during a deployment and prevent multiple Pipelines from requesting the same resources at th
This topic describes how to use the **Queue** step to control the access order to the resources Harness requests during a deployment and prevent multiple pipelines from requesting the same resources at the same time.
For example, two Pipelines might be deploying artifacts to a single Kubernetes namespace simultaneously. To avoid collisions and queue deployments, you add a Queue step to each Pipeline.
When the first Pipeline completes, it releases the lock, and the second Pipeline can continue.
## What you will learn from this topic
* How to [add a Queue step](#add-queue-steps) to a stage
* How to configure [advanced settings](#advanced-settings) on a Queue step
* How the Queue step [scope](#queue-step-scope) applies across an account
* How Queue steps compare to [Barriers and Resource Constraints](#barriers-resource-constraints-and-queue-steps)
* How to decide [when to add a Queue step](#when-to-queue) to protect a resource
## Before you begin
* Go to [Controlling resource usage with barriers, resource constraints, and queue steps](/continuous-delivery/use-continuous-delivery/manage-deployments/controlling-deployments-with-barriers-resource-constraints-and-queue-steps.md) to review the other options Harness provides for controlling resource usage and protecting capacity limits.
### Add Queue steps
1. In the **Execution** stage, determine where you want to queue deployments, then click **Add Step**.
2. In **Flow Control**, click **Queue**.
3. Enter a name and a timeout for the Queue step.
4. In **Resource Key**, enter a unique key. This is the same key you will add to the Queue steps in other Pipelines.
5. The **Resource Key** supports Fixed Values, Runtime Inputs, and Expressions. Go to [Fixed Values, Runtime Inputs, and Expressions](https://developer.harness.io/harness-platform/use-harness-platform/variables-and-expressions/runtime-inputs) for more information.
6. In **Run next queued execution after completion of**, select one of the following:
* **Pipeline**: The entire Pipeline must be completed before the queued Pipelines can deploy.
* **Stage**: The current Stage must be completed before the queued Pipelines can deploy.
Queue steps can be used on different Pipelines or even multiple executions of the same Pipeline.
### Advanced settings
In **Advanced**, you can use the following options:
* [Delegate Selector](https://developer.harness.io/harness-platform/use-harness-platform/delegates/delegate/manage-delegates/select-delegates-with-selectors)
* [Conditional Execution](https://developer.harness.io/harness-platform/use-harness-platform/pipelines/step-skip-condition-settings)
* [Failure Strategy](https://developer.harness.io/harness-platform/use-harness-platform/pipelines/failure-handling/define-a-failure-strategy-on-stages-and-steps)
* [Looping Strategy](https://developer.harness.io/harness-platform/use-harness-platform/pipelines/looping-strategies/looping-strategies-matrix-repeat-and-parallelism)
* [Policy Enforcement](https://developer.harness.io/harness-platform/use-harness-platform/governance/policy-as-code/harness-governance-overview)
### Test
This is a simple example to show how Queue steps work.
Here is the YAML for the Pipeline that contains a Custom Stage with a Queue Step, followed by a [Shell Script step](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/utilities/shell-script-step.md) that runs a Bash script `sleep 30`.
You can copy it and paste it into your Harness Project. You need to update the `projectIdentifier` and `orgIdentifier` settings to match your current [Project and Org](https://developer.harness.io/harness-platform/new-to-harness-platform/overview#organizations-and-projects).
```yaml
pipeline:
name: Queue
identifier: Queue
projectIdentifier: queuesteptest
orgIdentifier: default
tags: {}
stages:
- stage:
name: Queue
identifier: Queue
description: ""
type: Custom
spec:
execution:
steps:
- step:
type: Queue
name: Queue
identifier: Queue
spec:
key: "123"
scope: Pipeline
timeout: 10m
- step:
type: ShellScript
name: Sleep
identifier: Sleep
spec:
shell: Bash
onDelegate: true
source:
type: Inline
spec:
script: sleep 30
environmentVariables: []
outputVariables: []
executionTarget: {}
timeout: 10m
tags: {}
```
When you are done, the Pipeline looks like this:
Open the **Queue** step.
You can see **Run next queued execution after completion of** is set to **Pipeline**. That means that the Pipeline must finish deploying before any other queued Pipeline executions can proceed.
Now run this Pipeline twice in a row quickly.
The first run of the Pipeline runs without queuing, but the second run is queued until the first is complete.
Here is the first run of the Pipeline. It shows the Pipeline execution running (**Running**) and the other Pipeline execution queued.
You can click the name of the queued Pipeline to jump to its execution.
Here is the second run of the Pipeline:
You can see the Pipeline execution that is queued (**Current**) and the Pipeline execution that is running.
This example used multiple executions of the same Pipeline, but if a Queue step is added to another Pipeline and uses the same Resource Key, the same queuing process is applied to that Pipeline.
Here is another Pipeline in **queue 2** with the same Queue step Resource Key. You can see it waiting for the **Queue** Pipeline to complete.
### Queue step scope
Queue steps are account-wide. This ensures that if a Queue step is placed in one Pipeline, it prevents any other Pipeline in the account from using resources until it is safe to do so.
### Barriers, resource constraints, and queue steps
Harness offers several ways to control deployments and resource usage. Understanding their differences is important.
Go to [Controlling resource usage with barriers, resource constraints, and queue steps](/continuous-delivery/use-continuous-delivery/manage-deployments/controlling-deployments-with-barriers-resource-constraints-and-queue-steps.md) to understand the differences between these options.
### When to queue
Queue steps can be added anywhere in your Stage, so add them whenever the resource you want to protect is being used.
For example, if Pipeline A will perform some Terraform provisioning and Pipeline B will deploy to the provisioned infrastructure, you will want to place the Queue step before the [Terraform Apply](/continuous-delivery/use-continuous-delivery/provision-infrastructure/terraform-infra/run-a-terraform-plan-with-the-terraform-apply-step.md) step in Pipeline A, and before the deployment step in Pipeline B (such as a Kubernetes [Rolling step](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-rolling-deployment.md)).
## Next steps
* Go to [Controlling resource usage with barriers, resource constraints, and queue steps](/continuous-delivery/use-continuous-delivery/manage-deployments/controlling-deployments-with-barriers-resource-constraints-and-queue-steps.md) to compare Queue steps with Barriers and Resource Constraints.
{% @harness-feedback/feedback %}