terraform reusable variable sets that apply to multiple workspaces You can set variables specifically for each workspace or you can create variable sets to reuse the same variables across multiple workspaces Refer to the variables overview terraform cloud docs workspaces variables documentation for more information about variable types scope and precedence You can also set variable values specifically for each run on the command line Configure Terraform input variables and environment variables and create page title Managing Variables HCP Terraform Managing Variables

Answer:
---
page_title: Managing Variables - HCP Terraform
description: >-
  Configure Terraform input variables and environment variables and create
  reusable variable sets that apply to multiple workspaces.
---

# Managing Variables

You can set variables specifically for each workspace or you can create variable sets to reuse the same variables across multiple workspaces. Refer to the [variables overview](/terraform/cloud-docs/workspaces/variables) documentation for more information about variable types, scope, and precedence. You can also set variable values specifically for each run on the command line.

You can create and edit workspace-specific variables through:

- The HCP Terraform UI, as detailed below.
- The Variables API for [workspace-specific variables](/terraform/cloud-docs/api-docs/workspace-variables) and [variable sets](/terraform/cloud-docs/api-docs/variable-sets).
- The `tfe` provider's [`tfe_variable`](https://registry.terraform.io/providers/hashicorp/tfe/latest/docs/resources/variable) resource, which can be more convenient for bulk management.

## Permissions
You must have [`read variables` permission](/terraform/cloud-docs/users-teams-organizations/permissions#general-workspace-permissions) to view the variables for a particular workspace and to view the variable sets in your organization.

To create new variable sets and apply them to workspaces, you must be part of a team with [manage workspaces](/terraform/cloud-docs/users-teams-organizations/permissions#organization-owners) permissions. To create and edit workspace-specific variables within a workspace, you must have [read and write variables](/terraform/cloud-docs/users-teams-organizations/permissions#general-workspace-permissions) for that workspace.

## Run-Specific Variables

Terraform 1.1 and later lets you set [Terraform variable](/terraform/cloud-docs/workspaces/variables#terraform-variables) values for a particular plan or apply on the command line. These variable values will overwrite workspace-specific and variable set variables with the same key. Refer to the [variable precedence](/terraform/cloud-docs/workspaces/variables#precedence) documentation for more details.

You can set run-specific Terraform variable values by:

- Specifying `-var` and `-var-file` arguments. For example:

  ```
  terraform apply -var="key=value" -var-file="testing.tfvars"
  ```
- Creating local environment variables prefixed with `TF_VAR_`. For example, if you declare a variable called `replicas` in your configuration, you could create a local environment variable called `TF_VAR_replicas` and set it to a particular value. When you use the [CLI Workflow](/terraform/cloud-docs/run/cli), Terraform automatically identifies these environment variables and applies their values to the run.

Refer to the [variables on the command line](/terraform/language/values/variables#variables-on-the-command-line) documentation for more details and examples.

## Workspace-Specific Variables

To view and manage a workspace's variables, go to the workspace and click the **Variables** tab.

The **Variables** page appears, showing all workspace-specific variables and variable sets applied to the workspace. This is where you can add, edit, and delete workspace-specific variables. You can also apply and remove variable sets from the workspace.

The **Variables** page is not available for workspaces configured with `Local` [execution mode](/terraform/cloud-docs/workspaces/settings#execution-mode). HCP Terraform does not evaluate workspace variables or variable sets in local execution mode.

### Add a Variable

To add a variable:

1. Go to the workspace **Variables** page and click **+ Add variable** in the **Workspace Variables** section.

1. Choose a variable category (Terraform or environment), optionally mark the variable as [sensitive](#sensitive-values), and enter a variable key, value, and optional description. For Terraform variables only, you can check the **HCL** checkbox to enter a value in HashiCorp Configuration Language.

   Refer to [variable values and format](#variable-values-and-format) for variable limits, allowable values, and formatting.

1. Click **Save variable**. The variable now appears in the list of the workspace's variables and HCP Terraform will apply it to runs.

### Edit a Variable

To edit a variable:

1. Click the ellipses next to the variable you want to edit and select **Edit**.
1. Make any desired changes and click **Save variable**.

### Delete a Variable

To delete a variable:

1. Click the ellipses next to the variable you want to delete and select **Delete**.
1. Click **Yes, delete variable** to confirm your action.

## Loading Variables from Files

You can set [Terraform variable](/terraform/cloud-docs/workspaces/variables#terraform-variables) values by providing any number of [files ending in `.auto.tfvars`](/terraform/language/values/variables#variable-files) to workspaces that use Terraform 0.10.0 or later. When you trigger a run, Terraform automatically loads and uses the variables defined in these files. If any variable from the workspace has the same key as a variable in the file, the workspace variable overwrites variable from the file.

You can only do this with files ending in `auto.tfvars` or `terraform.tfvars`. You can apply other types of `.tfvars` files [using the command line](#run-specific-variables) for each run.

~> **Note:** HCP Terraform loads variables from files ending in `auto.tfvars` for each Terraform run, but does not automatically persist those variables to the HCP Terraform workspace or display them in the **Variables** section of the workspace UI.

## Variable Sets

> **Hands On:** Try the [Manage Variable Sets in HCP Terraform tutorial](/terraform/tutorials/cloud/cloud-multiple-variable-sets) tutorial.

Only members of the [Owners Team](/terraform/cloud-docs/users-teams-organizations/permissions#organization-owners) or members of a team with the [Manage all projects](/terraform/cloud-docs/users-teams-organizations/permissions#manage-all-projects) or [Manage all workspaces](/terraform/cloud-docs/users-teams-organizations/permissions#manage-all-workspaces) permission can create, update, and delete variable sets.

HCP Terraform does not evaluate variable sets during Terraform runs for workspaces configured with `Local` [execution mode](/terraform/cloud-docs/workspaces/settings#execution-mode).

To view variable sets for your organization, click **Settings**, then click **Variable sets**.

The **Variable sets** page appears, listing all of the organization's variable sets. Click on a variable set to open it and review details about its variables and scoping.

### Create Variable Sets

To create a variable set:

1. Go to the **Variable Sets** page for your organization and click **Create variable set**. The **Create a new variable set** page appears.

1. Choose a descriptive **Name** for the variable set. You can use any combination of numbers, letters, and characters.

1. Write an optional **Description** that tells other users about the purpose of the variable set and what it contains.

1. Choose a variable set scope:
   - **Apply globally:** HCP Terraform will automatically apply this global variable set to all existing and future workspaces.
   - **Apply to specific projects and workspaces:** Use the text fields to search for and select workspaces and/or projects to apply this variable set to. This affects all current and future workspaces for any selected projects. After creation, users can also [add this variable set to their workspaces](#apply-or-remove-variable-sets-from-inside-a-workspace).

1. Add one or more variables: Click **+ Add variable**, choose a variable type (Terraform or environment), optionally mark the variable as [sensitive](#sensitive-values), and enter a variable name, value, and optional description. Then, click **Save variable**.

   Refer to [variable values and format](#variable-values-and-format) for variable limits, allowable values, and formatting.

   ~> **Note:** HCP Terraform will error if you try to declare variables with the same key in multiple global variable sets.

1. Click **Create variable set.** HCP Terraform adds the new variable set to any specified workspaces and displays it on the **Variable Sets** page.

### Edit Variable Sets

To edit or remove a variable set:

1. Go to the organization's settings and then click **Variable Sets**. The **Variable sets** page appears.
1. Click the variable set you want to edit. That specific variable set page appears, where you can change the variable set settings. Refer to [create variable sets](#create-variable-sets) for details.

### Delete Variable Sets

Deleting a variable set can be a disruptive action, especially if the variables are required to execute runs. We recommend informing organization and workspace owners before removing a variable set.

To delete a variable set:

1. Click **Settings**, then click **Variable Sets**. The **Variable sets** page appears.
1. Select **Delete variable set**. Enter the variable set name and click **Delete variable set** to confirm this action. HCP Terraform deletes the variable set and removes it from all workspaces. Runs within those workspaces will no longer use the variables from the variable set.

### Apply or Remove Variable Sets From Inside a Workspace

To apply a variable set to a specific workspace:

1. Navigate to the workspace and click the **Variables** tab. The **Variables** page appears, showing all workspace-specific variables and variable sets applied to the workspace.

1. In the **Variable sets** section, click **Apply Variable Set**. Select the variable set you want to apply to your workspace, and click **Apply variable set**. The variable set appears in the workspace's variable sets list and HCP Terraform will now apply the variables to runs.

To remove a variable set from within a workspace:

1. Navigate to the workspace and click the **Variables** tab. The **Variables** page appears, showing all workspace-specific variables and variable sets applied to the workspace.
1. Click the ellipses button next to the variable set and select **Remove variable set**.
1. Click **Remove variable set** in the dialog box. HCP Terraform removes the variable set from this workspace, but it remains available to other workspaces in the organization.

## Overwrite Variable Sets

You can overwrite variables defined in variable sets within a workspace. For example, you may want to use a different set of provider credentials in a specific workspace.

To overwrite a variable from a variable set, [create a new workspace-specific variable](#workspace-specific-variables) of the same type with the same key. HCP Terraform marks any variables that you overwrite with a yellow **OVERWRITTEN** flag. When you click the overwritten variable, HCP Terraform highlights the variable it will use during runs.

Variables within a variable set can also automatically overwrite variables with the same key in other variable sets applied to the same workspace. Though variable sets are created for the organization, these overwrites occur within each workspace. Refer to [variable precedence](/terraform/cloud-docs/workspaces/variables#precedence) for more details.

## Priority Variable Sets

The values in priority variable sets overwrite any variables with the same key set at more specific scopes. This includes variables set using command line flags, or through`.*auto.tfvars` and `terraform.tfvars` files.

It is still possible for a user to directly modify the Terraform configuration and remove usage of a variable and replace it with a hard coded value. For stricter enforcement, we recommend using policy checks or run tasks.
Refer to [variable precedence](/terraform/cloud-docs/workspaces/variables#precedence-with-priority-variable-sets) for more details.

## Variable Values and Format

The limits, allowable values, and required format are the same for both workspace-specific variables and variable sets.

### Security

HCP Terraform encrypts all variable values securely using [Vault's transit backend](/vault/docs/secrets/transit) prior to saving them. This ensures that no out-of-band party can read these values without proper authorization. However, HCP Terraform stores variable [descriptions](#variable-description) in plain text, so be careful with the information you save in a variable description.

We also recommend passing credentials to Terraform as environment variables instead of Terraform variables when possible, since Terraform runs receive the full text of all Terraform variable values, including [sensitive](#sensitive-values) ones. It may print the values in logs and state files if the configuration sends the value to an output or a resource parameter. Sentinel mocks downloaded from runs will also contain the sensitive values of Terraform variables.

Although HCP Terraform does not store environment variables in state, it can include them in log files if `TF_LOG` is set to `TRACE`.

#### Dynamic Credentials

An alternative to passing static credentials for some providers is to use [dynamic credentials](/terraform/cloud-docs/workspaces/dynamic-provider-credentials).

Dynamic credentials allows for using temporary per-run credentials and eliminates the need to manually rotate secrets.

### Character Limits

The following limits apply to variables:

| Component   | Limit          |
| ----------- | -------------- |
| description | 512 characters |
| key         | 128 characters |
| value       | 256 kilobytes  |

### Multi-Line Text

You can type or paste multi-line text into variable value text fields.

### HashiCorp Configuration Language (HCL)

You can use HCL for Terraform variables, but not for environment variables. The same Terraform version that performs runs in the workspace will interpret the HCL.

Variable values are strings by default. To enter list or map values, click the variable’s **HCL** checkbox (visible when editing) and enter the value with the same HCL syntax you would use when writing Terraform code. For example:

```hcl
{
    us-east-1 = "image-1234"
    us-west-2 = "image-4567"
}
```

### Sensitive Values

!> **Warning:** There are some cases when even sensitive variables are included in logs and state files. Refer to [security](#security) for more information.

Terraform often needs cloud provider credentials and other sensitive information that should not be widely available within your organization. To protect these secrets, you can mark any Terraform or environment variable as sensitive data by clicking its **Sensitive** checkbox that is visible during editing.

Marking a variable as sensitive makes it write-only and prevents all users (including you) from viewing its value in the HCP Terraform UI or reading it through the Variables API endpoint.

Users with permission to read and write variables can set new values for sensitive variables, but other attributes of a sensitive variable cannot be modified. To update other attributes, delete the variable and create a new variable to replace it.

[permissions-citation]: #intentionally-unused---keep-for-maintainers

### Variable Description

!> **Warning:** Variable descriptions are not encrypted, so do not include any sensitive information.

Variable descriptions are optional, and help distinguish between similarly named variables. They are only shown on the **Variables** page and are completely independent from any variable descriptions declared in Terraform CLI.

page title  Managing Variables   HCP Terraform description       Configure Terraform input variables and environment variables and create   reusable variable sets that apply to multiple workspaces         Managing Variables  You can set variables specifically for each workspace or you can create variable sets to reuse the same variables across multiple workspaces  Refer to the  variables overview   terraform cloud docs workspaces variables  documentation for more information about variable types  scope  and precedence  You can also set variable values specifically for each run on the command line   You can create and edit workspace specific variables through     The HCP Terraform UI  as detailed below    The Variables API for  workspace specific variables   terraform cloud docs api docs workspace variables  and  variable sets   terraform cloud docs api docs variable sets     The  tfe  provider s   tfe variable   https   registry terraform io providers hashicorp tfe latest docs resources variable  resource  which can be more convenient for bulk management       Permissions You must have   read variables  permission   terraform cloud docs users teams organizations permissions general workspace permissions  to view the variables for a particular workspace and to view the variable sets in your organization   To create new variable sets and apply them to workspaces  you must be part of a team with  manage workspaces   terraform cloud docs users teams organizations permissions organization owners  permissions  To create and edit workspace specific variables within a workspace  you must have  read and write variables   terraform cloud docs users teams organizations permissions general workspace permissions  for that workspace        Run Specific Variables  Terraform 1 1 and later lets you set  Terraform variable   terraform cloud docs workspaces variables terraform variables  values for a particular plan or apply on the command line  These variable values will overwrite workspace specific and variable set variables with the same key  Refer to the  variable precedence   terraform cloud docs workspaces variables precedence  documentation for more details   You can set run specific Terraform variable values by     Specifying   var  and   var file  arguments  For example           terraform apply  var  key value   var file  testing tfvars          Creating local environment variables prefixed with  TF VAR    For example  if you declare a variable called  replicas  in your configuration  you could create a local environment variable called  TF VAR replicas  and set it to a particular value  When you use the  CLI Workflow   terraform cloud docs run cli   Terraform automatically identifies these environment variables and applies their values to the run   Refer to the  variables on the command line   terraform language values variables variables on the command line  documentation for more details and examples      Workspace Specific Variables  To view and manage a workspace s variables  go to the workspace and click the   Variables   tab   The   Variables   page appears  showing all workspace specific variables and variable sets applied to the workspace  This is where you can add  edit  and delete workspace specific variables  You can also apply and remove variable sets from the workspace   The   Variables   page is not available for workspaces configured with  Local   execution mode   terraform cloud docs workspaces settings execution mode   HCP Terraform does not evaluate workspace variables or variable sets in local execution mode       Add a Variable  To add a variable   1  Go to the workspace   Variables   page and click     Add variable   in the   Workspace Variables   section   1  Choose a variable category  Terraform or environment   optionally mark the variable as  sensitive   sensitive values   and enter a variable key  value  and optional description  For Terraform variables only  you can check the   HCL   checkbox to enter a value in HashiCorp Configuration Language       Refer to  variable values and format   variable values and format  for variable limits  allowable values  and formatting   1  Click   Save variable    The variable now appears in the list of the workspace s variables and HCP Terraform will apply it to runs       Edit a Variable  To edit a variable   1  Click the ellipses next to the variable you want to edit and select   Edit    1  Make any desired changes and click   Save variable         Delete a Variable  To delete a variable   1  Click the ellipses next to the variable you want to delete and select   Delete    1  Click   Yes  delete variable   to confirm your action      Loading Variables from Files  You can set  Terraform variable   terraform cloud docs workspaces variables terraform variables  values by providing any number of  files ending in   auto tfvars    terraform language values variables variable files  to workspaces that use Terraform 0 10 0 or later  When you trigger a run  Terraform automatically loads and uses the variables defined in these files  If any variable from the workspace has the same key as a variable in the file  the workspace variable overwrites variable from the file   You can only do this with files ending in  auto tfvars  or  terraform tfvars   You can apply other types of   tfvars  files  using the command line   run specific variables  for each run        Note    HCP Terraform loads variables from files ending in  auto tfvars  for each Terraform run  but does not automatically persist those variables to the HCP Terraform workspace or display them in the   Variables   section of the workspace UI      Variable Sets      Hands On    Try the  Manage Variable Sets in HCP Terraform tutorial   terraform tutorials cloud cloud multiple variable sets  tutorial   Only members of the  Owners Team   terraform cloud docs users teams organizations permissions organization owners  or members of a team with the  Manage all projects   terraform cloud docs users teams organizations permissions manage all projects  or  Manage all workspaces   terraform cloud docs users teams organizations permissions manage all workspaces  permission can create  update  and delete variable sets   HCP Terraform does not evaluate variable sets during Terraform runs for workspaces configured with  Local   execution mode   terraform cloud docs workspaces settings execution mode    To view variable sets for your organization  click   Settings    then click   Variable sets     The   Variable sets   page appears  listing all of the organization s variable sets  Click on a variable set to open it and review details about its variables and scoping       Create Variable Sets  To create a variable set   1  Go to the   Variable Sets   page for your organization and click   Create variable set    The   Create a new variable set   page appears   1  Choose a descriptive   Name   for the variable set  You can use any combination of numbers  letters  and characters   1  Write an optional   Description   that tells other users about the purpose of the variable set and what it contains   1  Choose a variable set scope         Apply globally    HCP Terraform will automatically apply this global variable set to all existing and future workspaces         Apply to specific projects and workspaces    Use the text fields to search for and select workspaces and or projects to apply this variable set to  This affects all current and future workspaces for any selected projects  After creation  users can also  add this variable set to their workspaces   apply or remove variable sets from inside a workspace    1  Add one or more variables  Click     Add variable    choose a variable type  Terraform or environment   optionally mark the variable as  sensitive   sensitive values   and enter a variable name  value  and optional description  Then  click   Save variable        Refer to  variable values and format   variable values and format  for variable limits  allowable values  and formatting           Note    HCP Terraform will error if you try to declare variables with the same key in multiple global variable sets   1  Click   Create variable set    HCP Terraform adds the new variable set to any specified workspaces and displays it on the   Variable Sets   page       Edit Variable Sets  To edit or remove a variable set   1  Go to the organization s settings and then click   Variable Sets    The   Variable sets   page appears  1  Click the variable set you want to edit  That specific variable set page appears  where you can change the variable set settings  Refer to  create variable sets   create variable sets  for details       Delete Variable Sets  Deleting a variable set can be a disruptive action  especially if the variables are required to execute runs  We recommend informing organization and workspace owners before removing a variable set   To delete a variable set   1  Click   Settings    then click   Variable Sets    The   Variable sets   page appears  1  Select   Delete variable set    Enter the variable set name and click   Delete variable set   to confirm this action  HCP Terraform deletes the variable set and removes it from all workspaces  Runs within those workspaces will no longer use the variables from the variable set       Apply or Remove Variable Sets From Inside a Workspace  To apply a variable set to a specific workspace   1  Navigate to the workspace and click the   Variables   tab  The   Variables   page appears  showing all workspace specific variables and variable sets applied to the workspace   1  In the   Variable sets   section  click   Apply Variable Set    Select the variable set you want to apply to your workspace  and click   Apply variable set    The variable set appears in the workspace s variable sets list and HCP Terraform will now apply the variables to runs   To remove a variable set from within a workspace   1  Navigate to the workspace and click the   Variables   tab  The   Variables   page appears  showing all workspace specific variables and variable sets applied to the workspace  1  Click the ellipses button next to the variable set and select   Remove variable set    1  Click   Remove variable set   in the dialog box  HCP Terraform removes the variable set from this workspace  but it remains available to other workspaces in the organization      Overwrite Variable Sets  You can overwrite variables defined in variable sets within a workspace  For example  you may want to use a different set of provider credentials in a specific workspace   To overwrite a variable from a variable set   create a new workspace specific variable   workspace specific variables  of the same type with the same key  HCP Terraform marks any variables that you overwrite with a yellow   OVERWRITTEN   flag  When you click the overwritten variable  HCP Terraform highlights the variable it will use during runs   Variables within a variable set can also automatically overwrite variables with the same key in other variable sets applied to the same workspace  Though variable sets are created for the organization  these overwrites occur within each workspace  Refer to  variable precedence   terraform cloud docs workspaces variables precedence  for more details      Priority Variable Sets  The values in priority variable sets overwrite any variables with the same key set at more specific scopes  This includes variables set using command line flags  or through   auto tfvars  and  terraform tfvars  files   It is still possible for a user to directly modify the Terraform configuration and remove usage of a variable and replace it with a hard coded value  For stricter enforcement  we recommend using policy checks or run tasks  Refer to  variable precedence   terraform cloud docs workspaces variables precedence with priority variable sets  for more details      Variable Values and Format  The limits  allowable values  and required format are the same for both workspace specific variables and variable sets       Security  HCP Terraform encrypts all variable values securely using  Vault s transit backend   vault docs secrets transit  prior to saving them  This ensures that no out of band party can read these values without proper authorization  However  HCP Terraform stores variable  descriptions   variable description  in plain text  so be careful with the information you save in a variable description   We also recommend passing credentials to Terraform as environment variables instead of Terraform variables when possible  since Terraform runs receive the full text of all Terraform variable values  including  sensitive   sensitive values  ones  It may print the values in logs and state files if the configuration sends the value to an output or a resource parameter  Sentinel mocks downloaded from runs will also contain the sensitive values of Terraform variables   Although HCP Terraform does not store environment variables in state  it can include them in log files if  TF LOG  is set to  TRACE         Dynamic Credentials  An alternative to passing static credentials for some providers is to use  dynamic credentials   terraform cloud docs workspaces dynamic provider credentials    Dynamic credentials allows for using temporary per run credentials and eliminates the need to manually rotate secrets       Character Limits  The following limits apply to variables     Component     Limit                                               description   512 characters     key           128 characters     value         256 kilobytes         Multi Line Text  You can type or paste multi line text into variable value text fields       HashiCorp Configuration Language  HCL   You can use HCL for Terraform variables  but not for environment variables  The same Terraform version that performs runs in the workspace will interpret the HCL   Variable values are strings by default  To enter list or map values  click the variable s   HCL   checkbox  visible when editing  and enter the value with the same HCL syntax you would use when writing Terraform code  For example      hcl       us east 1    image 1234      us west 2    image 4567             Sensitive Values       Warning    There are some cases when even sensitive variables are included in logs and state files  Refer to  security   security  for more information   Terraform often needs cloud provider credentials and other sensitive information that should not be widely available within your organization  To protect these secrets  you can mark any Terraform or environment variable as sensitive data by clicking its   Sensitive   checkbox that is visible during editing   Marking a variable as sensitive makes it write only and prevents all users  including you  from viewing its value in the HCP Terraform UI or reading it through the Variables API endpoint   Users with permission to read and write variables can set new values for sensitive variables  but other attributes of a sensitive variable cannot be modified  To update other attributes  delete the variable and create a new variable to replace it    permissions citation    intentionally unused   keep for maintainers      Variable Description       Warning    Variable descriptions are not encrypted  so do not include any sensitive information   Variable descriptions are optional  and help distinguish between similarly named variables  They are only shown on the   Variables   page and are completely independent from any variable descriptions declared in Terraform CLI


terraform page title Permissions HCP Terraform permissions and what permissions you can grant to users BEGIN TFC only name pnp callout Learn the difference between workspace level and organization level Permissions

Answer:
---
page_title: Permissions - HCP Terraform
description: >-
  Learn the difference between workspace-level and organization-level
  permissions and what permissions you can grant to users.
---

# Permissions

<!-- BEGIN: TFC:only name:pnp-callout -->
-> **Note:** Team management is available in HCP Terraform **Standard** Edition. [Learn more about HCP Terraform pricing here](https://www.hashicorp.com/products/terraform/pricing).
<!-- END: TFC:only name:pnp-callout -->

[permissions-citation]: #intentionally-unused---keep-for-maintainers

> **Hands-on:** Try the [Manage Permissions in HCP Terraform](/terraform/tutorials/cloud/cloud-permissions?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.

HCP Terraform's access model is team-based. In order to perform an action within an HCP Terraform organization, users must belong to a team that has been granted the appropriate permissions.

The permissions model is split into organization-level, project-level, and workspace-level permissions. Additionally, every organization has a special team named "owners", whose members have maximal permissions within the organization.

## Organization Owners

Every organization has a special "owners" team. Members of this team are often referred to as "organization owners".

Organization owners have every available permission within the organization. This includes all organization-level permissions, and the highest level of workspace permissions on every workspace.

There are also some actions within an organization that are only available to owners. These are generally actions that affect the permissions and membership of other teams, or are otherwise fundamental to the organization's security and integrity.

Permissions for the owners team include:

- Manage workspaces (refer to [Organization Permissions][] below; equivalent to admin permissions on every workspace)
- Manage projects (refer to [Organization Permissions][] below; equivalent to admin permissions on every project and workspace)
- Manage policies (refer to [Organization Permissions][] below)
- Manage policy overrides (refer to [Organization Permissions][] below)
- Manage VCS settings (refer to [Organization Permissions][] below)
- Manage the private registry (refer to [Organization Permissions][] below)
- Manage Membership (refer to [Organization Permissions][] below; invite or remove users from the organization itself, and manage the membership of its teams)
- View all secret teams (refer to [Organization Permissions][] below)
- Manage agents (refer to [Organization Permissions][] below)
- Manage organization permissions (refer to [Organization Permissions][] below)
- Manage all organization settings (owners only)
- Manage organization billing (owners only, not applicable to Terraform Enterprise)
- Delete organization (owners only)

This list is not necessarily exhaustive.

[Organization Permissions]: #organization-permissions

## Workspace Permissions

[workspace]: /terraform/cloud-docs/workspaces

Most of HCP Terraform's permissions system is focused on workspaces. In general, administrators want to delegate access to specific collections of infrastructure; HCP Terraform implements this by granting permissions to teams on a per-workspace basis.

There are two ways to choose which permissions a given team has on a workspace: fixed permission sets, and custom permissions. Additionally, there is a special "admin" permission set that grants the highest level of permissions on a workspace.

### Implied Permissions

Some permissions imply other permissions; for example, the run access plan permission also grants permission to read runs.

If documentation or UI text states that an action requires a specific permission, it is also available for any permission that implies that permission.

### General Workspace Permissions

[General Workspace Permissions]: #general-workspace-permissions

The following workspace permissions can be granted to teams on a per-workspace basis. They can be granted via either fixed permission sets or custom workspace permissions.

-> **Note:** Throughout the documentation, we refer to the specific permission an action requires (like "requires permission to apply runs") rather than the fixed permission set that includes that permission (like "requires write access").

- **Run access:**
  - **Read:** — Allows users to view information about remote Terraform runs, including the run history, the status of runs, the log output of each stage of a run (plan, apply, cost estimation, policy check), and configuration versions associated with a run.
  - **Plan:** — _Implies permission to read._ Allows users to queue Terraform plans in a workspace, including both speculative plans and normal plans. Normal plans must be approved by a user with permission to apply runs. This also allows users to comment on runs.
  - **Apply:** — _Implies permission to plan._ Allows users to approve and apply Terraform plans, causing changes to real infrastructure.
- **Variable access:**
  - **No access:** — No access is granted to the values of Terraform variables and environment variables for the workspace.
  - **Read:** — Allows users to view the values of Terraform variables and environment variables for the workspace. Note that variables marked as sensitive are write-only, and can't be viewed by any user.
  - **Read and write:** — _Implies permission to read._ Allows users to edit the values of variables in the workspace.
- **State access:**
  - **No access:** — No access is granted to the state file from the workspace.
  - **Read outputs only:** — Allows users to access values in the workspace's most recent Terraform state that have been explicitly marked as public outputs. Output values are often used as an interface between separate workspaces that manage loosely coupled collections of infrastructure, so their contents can be relevant to people who have no direct responsibility for the managed infrastructure but still indirectly use some of its functions. This permission is required to access the [State Version Outputs](/terraform/cloud-docs/api-docs/state-version-outputs) API endpoint.

    -> **Note:** **Read state versions** permission is required to use the `terraform output` command or the `terraform_remote_state` data source against the workspace.
  - **Read:** — _Implies permission to read outputs only._ Allows users to read complete state files from the workspace. State files are useful for identifying infrastructure changes over time, but often contain sensitive information.
  - **Read and write:** — _Implies permission to read._ Allows users to directly create new state versions in the workspace. Applying a remote Terraform run creates new state versions without this permission, but if the workspace's execution mode is set to "local", this permission is required for performing local runs. This permission is also required to use any of the Terraform CLI's state manipulation and maintenance commands against this workspace, including `terraform import`, `terraform taint`, and the various `terraform state` subcommands.
- **Other controls:**
  - **Download Sentinel mocks:** — Allows users to download data from runs in the workspace in a format that can be used for developing Sentinel policies. This run data is very detailed, and often contains unredacted sensitive information.
  - **Manage Workspace Run Tasks:** — Allows users to associate or dissociate run tasks with the workspace. HCP Terraform creates Run Tasks at the organization level, where you can manually associate or dissociate them with specific workspaces.
  - **Lock/unlock workspace:** — Allows users to manually lock the workspace to temporarily prevent runs. When a workspace's execution mode is set to "local", users must have this permission to perform local CLI runs using the workspace's state.

### Fixed Permission Sets

Fixed permission sets are bundles of specific permissions for workspaces, which you can use to delegate access to workspaces easily.

Each permissions set targets a level of authority and responsibility for a given workspace's infrastructure. A permission set can grant permissions that recipients do not require but offer a balance of simplicity and utility.

#### Workspace Admins

Much like the owners team has full control over an organization, each workspace has a special "admin" permissions level that grants full control over the workspace. Members of a team with admin permissions on a workspace are sometimes called "workspace admins" for that workspace.

Admin permissions include the highest level of general permissions for the workspace. There are also some permissions that are only available to workspace admins, which generally involve changing the workspace's settings or setting access levels for other teams.

Workspace admins have all [General Workspace Permissions](#general-workspace-permissions), as well as the ability to do the following tasks:

- Read and write workspace settings. This includes general settings, notification configurations, run triggers, and more.
- Set or remove workspace permissions for visible teams. Workspace admins cannot view or manage teams with the [**Secret**](/terraform/cloud-docs/users-teams-organizations/teams/manage#team-visibility) visibility option enabled unless they are also organization owners.
- Delete the workspace
  - Depending on the [organization's settings](/terraform/cloud-docs/users-teams-organizations/organizations#general), workspace admins may only be able to delete the workspace if it is not actively managing infrastructure. Refer to [Deleting a Workspace With Resources Under Management](/terraform/cloud-docs/workspaces/settings#deleting-a-workspace-with-resources-under-management) for details.

#### Write

The "write" permission set is for people who do most of the day-to-day work of provisioning and modifying managed infrastructure. Write access grants the following workspace permissions:

- Run access - Apply
- Variable access - Read and write
- State access - Read and write
- Other access - Lock/unlock workspace
- Other access - Download Sentinel mocks

See [General Workspace Permissions][] above for details about specific permissions.

#### Plan

The "plan" permission set is for people who might propose changes to managed infrastructure, but whose proposed changes should be approved before they are applied. Plan access grants the following workspace permissions:

- Run access - Plan
- Variable access - Read
- State access - Read

See [General Workspace Permissions][] above for details about specific permissions.

#### Read

The "read" permission set is for people who need to view information about the status and configuration of managed infrastructure in order to do their jobs, but aren't responsible for maintaining that infrastructure. Read access grants the following workspace permissions:

- Run access - Read
- Variable access - Read
- State access - Read

See [General Workspace Permissions][] above for details about specific permissions.

### Custom Workspace Permissions

Custom permissions let you assign specific, finer-grained permissions to a team than the broader fixed permission sets provide. This enables more task-focused permission sets and tighter control of sensitive information.

You can use custom permissions to assign any of the permissions listed above under [General Workspace Permissions][], with the exception of admin-only permissions.

The minimum custom permissions set for a workspace is the permission to read runs; the only way to grant a team lower access is to not add them to the workspace at all.

Some permissions - such as the runs permission - are tiered: you can assign one permission per category, since higher permissions include all of the capabilities of the lower ones.

## Project Permissions

You can assign project-specific permissions to teams.

### Implied Permissions

Some permissions imply other permissions. For example, permission to update a project also grants permission to read a project.

If an action states that it requires a specific permission level, you can perform that action if your permissions _imply_ the stated permission level.

### General Project Permissions

[General Project Permissions]: #general-project-permissions

You can grant the following project permissions to teams on a per-project basis. You can grant these with either fixed permission sets or custom project permissions.

-> **Note:** Throughout the documentation, we refer to the specific permission an action requires (like "requires permission to apply runs") rather than the fixed permission set that includes that permission (like "requires write access").

- **Project access:**
  - **Read:** — Allows users to view information about the project including the name.
  - **Update:** — _Implies permission to read._ Allows users to update the project name.
  - **Delete:** — _Implies permission to update._ Allows users to delete the project.
  - **Create Workspaces:** — Allow users to create workspaces in the project. This grants read access to all workspaces in the project.
  - **Delete Workspaces:** — Allows users to delete workspaces in the project.
    - Depending on the [organization's settings](/terraform/cloud-docs/users-teams-organizations/organizations#general), workspace admins may only be able to delete the workspace if it is not actively managing infrastructure. Refer to [Deleting a Workspace With Resources Under Management](/terraform/cloud-docs/workspaces/settings#deleting-a-workspace-with-resources-under-management) for details.
  - **Move Workspaces:** — Allows users to move workspaces out of the project. A user _must_ have this permission on both the source _and_ destination project to successfully move a workspace from one project to another.
- **Team management:**
  - **None:** — No access to view teams assigned to the project.
  - **Read:** — Allows users to see teams assigned to the project for visible teams.
  - **Manage:** — _Implies permission to read._ Allows users to set or remove project permissions for visible teams. Project admins can not view or manage [secret teams](/terraform/cloud-docs/users-teams-organizations/teams/manage#team-visibility) unless they are also organization owners.

See [General Workspace Permissions](#general-workspace-permissions)for the complete list of available permissions for a project's workspaces.

### Fixed Permission Sets

Fixed permission sets are bundles of specific permissions for projects, which you can use to delegate access to a project's workspaces easily.

#### Project Admin

Each project has an "admin" permissions level that grants permissions for both the project and the workspaces that belong to that project. Members with admin permissions on a project are dubbed that project's "project admins".

Members of teams with "admin" permissions for a project have [General Workspace Permissions](#general-workspace-permissions) for every workspace in the project, and the ability to:

- Read and update project settings.
- Delete the project.
- Create workspaces in the project.
- Move workspaces into or out of the project. This also requires project admin permissions for the source or destination project.
- Grant or revoke project permissions for visible teams. Project admins **cannot** view or manage access for teams that are are [Secret](/terraform/cloud-docs/users-teams-organizations/teams/manage#team-visibility), unless those admins are also organization owners.

#### Maintain

The "maintain" permission is for people who need to manage existing infrastructure in a single project, while also granting the ability to create new workspaces in that project. Maintain access grants full control of everything in the project, including the following permissions:
- Admin access for all workspaces in this project.
- Create workspaces in this project.
- Read the project name.
- Lock and unlock all workspaces in this project.
- Read and write variables for all workspaces in this project.
- Access state for all workspaces in this project.
- Approve runs for all workspaces in this project.

#### Write

The "write" permission set is for people who do most of the day-to-day work of provisioning and modifying managed infrastructure. Write access grants the following workspace permissions:
- Read the project name.
- Lock and unlock all workspaces in this project.
- Read and write variables for all workspaces in this project.
- Access state for all workspaces in this project.
- Approve runs for all workspaces in this project.

#### Read

The "read" permission set is for people who need to view information about the status and configuration of managed infrastructure for their job function, but are not responsible for maintaining that infrastructure. Read access grants the permissions to:
- Read the project name.
- Read the workspaces in the project.

### Custom Project Permissions

Custom permissions enable you to assign specific and granular permissions to a team. You can use custom permission sets to create task-focused permission sets and control sensitive information.

You can create a set of custom permissions using any of the permissions listed under [General Project Permissions](#general-project-permissions).

Some permissions, such as the project access permission, are tiered. You can only assign one permission per category because higher-level permissions include the capabilities of lower levels.

## Organization Permissions

Separate from project and workspace permissions, you can grant teams permissions to manage or view certain resources or settings across an organization. To set these permissions for a team, go to your organization's **Settings**. Then click **Teams**, and select the team name from the list.

The following organization permissions are available:

### Project permissions

You must select a level of access for projects.

#### None

Members do not have access to projects or workspaces. You can grant permissions to individual projects or workspaces through [Project Permissions](/terraform/cloud-docs/users-teams-organizations/permissions#project-permissions) or [Workspace Permissions](/terraform/cloud-docs/users-teams-organizations/permissions#workspace-permissions).

#### View all projects

Members can view all projects within the organization. This lets users:
- View project names in a given organization.

#### Manage all projects

Members can create and manage all projects and workspaces within the organization. In addition to the permissions granted by [“Manage all workspaces”](/terraform/cloud-docs/users-teams-organizations/permissions#manage-all-workspaces), this also lets users:
- Manage other teams' access to all projects.
- Create, edit, and delete projects (otherwise only available to organization owners).
- Move workspaces between projects.

### Workspace permissions

You must select a level of access for workspaces.

#### None

Members do not have access to projects or workspaces. You can grant permissions to individual projects or workspaces through [Project Permissions](/terraform/cloud-docs/users-teams-organizations/permissions#project-permissions) or [Workspace Permissions](/terraform/cloud-docs/users-teams-organizations/permissions#workspace-permissions).

#### View all workspaces

Members can view all workspaces within the organization. This lets users:
- View information and features relevant to each workspaces (e.g. runs, state versions, variables).

#### Manage all workspaces

Members can create and manage all workspaces within the organization. This lets users:
- Perform any action that requires admin permissions in those workspaces.
- Create new workspaces within the organization's **Default Project**, an action that is otherwise only available to organization owners.
- Create, update, and delete [Variable Sets](/terraform/cloud-docs/workspaces/variables/managing-variables#variable-sets).

### Manage Policies

Allows members to create, edit, read, list and delete the organization's Sentinel policies.

This permission implicitly gives permission to read runs on all workspaces, which is necessary to set enforcement of [policy sets](/terraform/cloud-docs/policy-enforcement/manage-policy-sets).

### Manage Run Tasks

Allows members to create, edit, and delete run tasks on the organization.

### Manage Policy Overrides

Allows members to override soft-mandatory policy checks.

This permission implicitly gives permission to read runs on all workspaces, which is necessary to override policy checks.

### Manage VCS Settings

Allows members to manage the set of [VCS providers](/terraform/cloud-docs/vcs) and [SSH keys](/terraform/cloud-docs/vcs#ssh-keys) available within the organization.

### Manage Agent Pools

Allows members to create, edit, and delete agent pools within their organization.

This permission implicitly grants access to read all workspaces, which is necessary for agent pool management.

### Manage Private Registry

Allows members to publish and delete providers, modules, or both providers and modules in the organization's [private registry](/terraform/cloud-docs/registry). These permissions are otherwise only available to organization owners.

### Team Management Permissions

HCP Terraform has three levels of team management permissions: manage membership, manage teams, and manage organization access. Each permission level grants users the ability to perform specific actions and each progressively requires prerequisite permissions.

For example, to grant a user the manage teams permission, that user must already have manage membership permissions. To grant a user the manage organization access permission, a user must have both manage teams and manage membership permissions.

#### Manage Membership

Allows members to invite users to the organization, remove users from the organization, and add or remove users from teams within the organization.

This permission grants the ability to view the list of users within the organization, and to view the organization access of other visible teams. It does not permit the creation of teams, the ability to modify the settings of existing teams, or the ability to view secret teams.

In order to modify the membership of a team, a user with Manage Membership permissions must have visibility into the team (i.e. the team must be ["Visible"](/terraform/cloud-docs/users-teams-organizations/teams/manage#team-visibility), or the user must be on the team).
In order to remove a user from the organization, the holder of this permission must have visibility into all of the teams which the user is a member of.

~> This permission is intended to allow owners of large organizations to delegate membership management to another trusted team, and should be granted to only teams of trusted users. **Assign with caution:** Users with this permission are able to add themselves to any visible team, and inherit the permissions of any visible team.

#### Manage Teams

Allows members to create, update, and delete teams, and generate, regenerate, and revoke tokens.

This permission grants the ability to update a team's names, SSO IDs, and token management permissions, but does not allow access to organization settings. On its own, this permission does not allow users to create, update, delete, or otherwise access secret teams.

The manage teams permission confers all permissions granted by the manage membership permission.

This permission allows owners of large organizations to delegate team management to another trusted team. You should only grant it to teams of trusted users.

~> **Assign with caution**: Users with this permission can update or delete any visible team. Because this permission also confers the manage membership permission, a user with the manage teams permission can add themselves to any visible team.

#### Manage Organization Access

Allows members to update a team's organization access settings.

On its own, this permission does not allow users to create, update, delete, or otherwise access secret teams. This permission confers all of the permissions granted by the manage teams and manage membership permissions.

This permission allows owners of large organizations to delegate team management to another trusted team. You should only grant it to teams of trusted users.

~> **Assign with caution:** Members with this permission can update all organization access settings for any team visible to them.

### Include Secret Teams

Allows members access to secret teams at the level permitted by that user's team permissions setting.

This permission acts as a modifier to existing team management permissions. Members with this permission can access secret teams up to the level permitted by other team management permissions. For example, if a user has permission to include secret teams and [manage teams](/terraform/cloud-docs/users-teams-organizations/permissions#manage-teams), that user can create secret teams.

### Allow Member Token Management

Allows owners and members with [manage teams](/terraform/cloud-docs/users-teams-organizations/permissions#manage-teams) permissions to enable and disable team token management for team members. This permission defaults to `true`.

When member token management is enabled, members will be able to perform actions on team tokens, including generating and revoking a team token.

When member token management is disabled, members will be unable to perform actions on team tokens, including generating and revoking a team token.

## Permissions Outside HCP Terraform's Scope

This documentation only refers to permissions that are managed by HCP Terraform itself.

Since HCP Terraform integrates with other systems, the permissions models of those systems can also be relevant to the overall security model of your HCP Terraform organization. For example:

- When a workspace is connected to a VCS repository, anyone who can merge changes to that repository's main branch can indirectly queue plans in that workspace, regardless of whether they have explicit permission to queue plans or are even a member of your HCP Terraform organization. (And when auto-apply is enabled, merging changes will indirectly apply runs.)
- If you use HCP Terraform's API to create a Slack bot for provisioning infrastructure, anyone able to issue commands to that Slack bot can implicitly act with that bot's permissions, regardless of their own membership and permissions in the HCP Terraform organization.
- When a run task sends a request to an integrator, it provides an access token that provides access depending on the run task stage:
  - For post-plan, it provides access to the runs plan json and the run task callback
  - All access tokens created for run tasks have a lifetime of 10 minutes

When integrating HCP Terraform with other systems, you are responsible for understanding the effects on your organization's security. An integrated system is able to delegate any level of access that it has been granted, so carefully consider the conditions and events that will cause it to delegate that access.

page title  Permissions   HCP Terraform description       Learn the difference between workspace level and organization level   permissions and what permissions you can grant to users         Permissions       BEGIN  TFC only name pnp callout          Note    Team management is available in HCP Terraform   Standard   Edition   Learn more about HCP Terraform pricing here  https   www hashicorp com products terraform pricing        END  TFC only name pnp callout       permissions citation    intentionally unused   keep for maintainers      Hands on    Try the  Manage Permissions in HCP Terraform   terraform tutorials cloud cloud permissions utm source WEBSITE utm medium WEB IO utm offer ARTICLE PAGE utm content DOCS  tutorial   HCP Terraform s access model is team based  In order to perform an action within an HCP Terraform organization  users must belong to a team that has been granted the appropriate permissions   The permissions model is split into organization level  project level  and workspace level permissions  Additionally  every organization has a special team named  owners   whose members have maximal permissions within the organization      Organization Owners  Every organization has a special  owners  team  Members of this team are often referred to as  organization owners    Organization owners have every available permission within the organization  This includes all organization level permissions  and the highest level of workspace permissions on every workspace   There are also some actions within an organization that are only available to owners  These are generally actions that affect the permissions and membership of other teams  or are otherwise fundamental to the organization s security and integrity   Permissions for the owners team include     Manage workspaces  refer to  Organization Permissions    below  equivalent to admin permissions on every workspace    Manage projects  refer to  Organization Permissions    below  equivalent to admin permissions on every project and workspace    Manage policies  refer to  Organization Permissions    below    Manage policy overrides  refer to  Organization Permissions    below    Manage VCS settings  refer to  Organization Permissions    below    Manage the private registry  refer to  Organization Permissions    below    Manage Membership  refer to  Organization Permissions    below  invite or remove users from the organization itself  and manage the membership of its teams    View all secret teams  refer to  Organization Permissions    below    Manage agents  refer to  Organization Permissions    below    Manage organization permissions  refer to  Organization Permissions    below    Manage all organization settings  owners only    Manage organization billing  owners only  not applicable to Terraform Enterprise    Delete organization  owners only   This list is not necessarily exhaustive    Organization Permissions    organization permissions     Workspace Permissions   workspace    terraform cloud docs workspaces  Most of HCP Terraform s permissions system is focused on workspaces  In general  administrators want to delegate access to specific collections of infrastructure  HCP Terraform implements this by granting permissions to teams on a per workspace basis   There are two ways to choose which permissions a given team has on a workspace  fixed permission sets  and custom permissions  Additionally  there is a special  admin  permission set that grants the highest level of permissions on a workspace       Implied Permissions  Some permissions imply other permissions  for example  the run access plan permission also grants permission to read runs   If documentation or UI text states that an action requires a specific permission  it is also available for any permission that implies that permission       General Workspace Permissions   General Workspace Permissions    general workspace permissions  The following workspace permissions can be granted to teams on a per workspace basis  They can be granted via either fixed permission sets or custom workspace permissions        Note    Throughout the documentation  we refer to the specific permission an action requires  like  requires permission to apply runs   rather than the fixed permission set that includes that permission  like  requires write access         Run access          Read      Allows users to view information about remote Terraform runs  including the run history  the status of runs  the log output of each stage of a run  plan  apply  cost estimation  policy check   and configuration versions associated with a run        Plan       Implies permission to read   Allows users to queue Terraform plans in a workspace  including both speculative plans and normal plans  Normal plans must be approved by a user with permission to apply runs  This also allows users to comment on runs        Apply       Implies permission to plan   Allows users to approve and apply Terraform plans  causing changes to real infrastructure      Variable access          No access      No access is granted to the values of Terraform variables and environment variables for the workspace        Read      Allows users to view the values of Terraform variables and environment variables for the workspace  Note that variables marked as sensitive are write only  and can t be viewed by any user        Read and write       Implies permission to read   Allows users to edit the values of variables in the workspace      State access          No access      No access is granted to the state file from the workspace        Read outputs only      Allows users to access values in the workspace s most recent Terraform state that have been explicitly marked as public outputs  Output values are often used as an interface between separate workspaces that manage loosely coupled collections of infrastructure  so their contents can be relevant to people who have no direct responsibility for the managed infrastructure but still indirectly use some of its functions  This permission is required to access the  State Version Outputs   terraform cloud docs api docs state version outputs  API endpoint            Note      Read state versions   permission is required to use the  terraform output  command or the  terraform remote state  data source against the workspace        Read       Implies permission to read outputs only   Allows users to read complete state files from the workspace  State files are useful for identifying infrastructure changes over time  but often contain sensitive information        Read and write       Implies permission to read   Allows users to directly create new state versions in the workspace  Applying a remote Terraform run creates new state versions without this permission  but if the workspace s execution mode is set to  local   this permission is required for performing local runs  This permission is also required to use any of the Terraform CLI s state manipulation and maintenance commands against this workspace  including  terraform import    terraform taint   and the various  terraform state  subcommands      Other controls          Download Sentinel mocks      Allows users to download data from runs in the workspace in a format that can be used for developing Sentinel policies  This run data is very detailed  and often contains unredacted sensitive information        Manage Workspace Run Tasks      Allows users to associate or dissociate run tasks with the workspace  HCP Terraform creates Run Tasks at the organization level  where you can manually associate or dissociate them with specific workspaces        Lock unlock workspace      Allows users to manually lock the workspace to temporarily prevent runs  When a workspace s execution mode is set to  local   users must have this permission to perform local CLI runs using the workspace s state       Fixed Permission Sets  Fixed permission sets are bundles of specific permissions for workspaces  which you can use to delegate access to workspaces easily   Each permissions set targets a level of authority and responsibility for a given workspace s infrastructure  A permission set can grant permissions that recipients do not require but offer a balance of simplicity and utility        Workspace Admins  Much like the owners team has full control over an organization  each workspace has a special  admin  permissions level that grants full control over the workspace  Members of a team with admin permissions on a workspace are sometimes called  workspace admins  for that workspace   Admin permissions include the highest level of general permissions for the workspace  There are also some permissions that are only available to workspace admins  which generally involve changing the workspace s settings or setting access levels for other teams   Workspace admins have all  General Workspace Permissions   general workspace permissions   as well as the ability to do the following tasks     Read and write workspace settings  This includes general settings  notification configurations  run triggers  and more    Set or remove workspace permissions for visible teams  Workspace admins cannot view or manage teams with the    Secret     terraform cloud docs users teams organizations teams manage team visibility  visibility option enabled unless they are also organization owners    Delete the workspace     Depending on the  organization s settings   terraform cloud docs users teams organizations organizations general   workspace admins may only be able to delete the workspace if it is not actively managing infrastructure  Refer to  Deleting a Workspace With Resources Under Management   terraform cloud docs workspaces settings deleting a workspace with resources under management  for details        Write  The  write  permission set is for people who do most of the day to day work of provisioning and modifying managed infrastructure  Write access grants the following workspace permissions     Run access   Apply   Variable access   Read and write   State access   Read and write   Other access   Lock unlock workspace   Other access   Download Sentinel mocks  See  General Workspace Permissions    above for details about specific permissions        Plan  The  plan  permission set is for people who might propose changes to managed infrastructure  but whose proposed changes should be approved before they are applied  Plan access grants the following workspace permissions     Run access   Plan   Variable access   Read   State access   Read  See  General Workspace Permissions    above for details about specific permissions        Read  The  read  permission set is for people who need to view information about the status and configuration of managed infrastructure in order to do their jobs  but aren t responsible for maintaining that infrastructure  Read access grants the following workspace permissions     Run access   Read   Variable access   Read   State access   Read  See  General Workspace Permissions    above for details about specific permissions       Custom Workspace Permissions  Custom permissions let you assign specific  finer grained permissions to a team than the broader fixed permission sets provide  This enables more task focused permission sets and tighter control of sensitive information   You can use custom permissions to assign any of the permissions listed above under  General Workspace Permissions     with the exception of admin only permissions   The minimum custom permissions set for a workspace is the permission to read runs  the only way to grant a team lower access is to not add them to the workspace at all   Some permissions   such as the runs permission   are tiered  you can assign one permission per category  since higher permissions include all of the capabilities of the lower ones      Project Permissions  You can assign project specific permissions to teams       Implied Permissions  Some permissions imply other permissions  For example  permission to update a project also grants permission to read a project   If an action states that it requires a specific permission level  you can perform that action if your permissions  imply  the stated permission level       General Project Permissions   General Project Permissions    general project permissions  You can grant the following project permissions to teams on a per project basis  You can grant these with either fixed permission sets or custom project permissions        Note    Throughout the documentation  we refer to the specific permission an action requires  like  requires permission to apply runs   rather than the fixed permission set that includes that permission  like  requires write access         Project access          Read      Allows users to view information about the project including the name        Update       Implies permission to read   Allows users to update the project name        Delete       Implies permission to update   Allows users to delete the project        Create Workspaces      Allow users to create workspaces in the project  This grants read access to all workspaces in the project        Delete Workspaces      Allows users to delete workspaces in the project        Depending on the  organization s settings   terraform cloud docs users teams organizations organizations general   workspace admins may only be able to delete the workspace if it is not actively managing infrastructure  Refer to  Deleting a Workspace With Resources Under Management   terraform cloud docs workspaces settings deleting a workspace with resources under management  for details        Move Workspaces      Allows users to move workspaces out of the project  A user  must  have this permission on both the source  and  destination project to successfully move a workspace from one project to another      Team management          None      No access to view teams assigned to the project        Read      Allows users to see teams assigned to the project for visible teams        Manage       Implies permission to read   Allows users to set or remove project permissions for visible teams  Project admins can not view or manage  secret teams   terraform cloud docs users teams organizations teams manage team visibility  unless they are also organization owners   See  General Workspace Permissions   general workspace permissions for the complete list of available permissions for a project s workspaces       Fixed Permission Sets  Fixed permission sets are bundles of specific permissions for projects  which you can use to delegate access to a project s workspaces easily        Project Admin  Each project has an  admin  permissions level that grants permissions for both the project and the workspaces that belong to that project  Members with admin permissions on a project are dubbed that project s  project admins    Members of teams with  admin  permissions for a project have  General Workspace Permissions   general workspace permissions  for every workspace in the project  and the ability to     Read and update project settings    Delete the project    Create workspaces in the project    Move workspaces into or out of the project  This also requires project admin permissions for the source or destination project    Grant or revoke project permissions for visible teams  Project admins   cannot   view or manage access for teams that are are  Secret   terraform cloud docs users teams organizations teams manage team visibility   unless those admins are also organization owners        Maintain  The  maintain  permission is for people who need to manage existing infrastructure in a single project  while also granting the ability to create new workspaces in that project  Maintain access grants full control of everything in the project  including the following permissions    Admin access for all workspaces in this project    Create workspaces in this project    Read the project name    Lock and unlock all workspaces in this project    Read and write variables for all workspaces in this project    Access state for all workspaces in this project    Approve runs for all workspaces in this project        Write  The  write  permission set is for people who do most of the day to day work of provisioning and modifying managed infrastructure  Write access grants the following workspace permissions    Read the project name    Lock and unlock all workspaces in this project    Read and write variables for all workspaces in this project    Access state for all workspaces in this project    Approve runs for all workspaces in this project        Read  The  read  permission set is for people who need to view information about the status and configuration of managed infrastructure for their job function  but are not responsible for maintaining that infrastructure  Read access grants the permissions to    Read the project name    Read the workspaces in the project       Custom Project Permissions  Custom permissions enable you to assign specific and granular permissions to a team  You can use custom permission sets to create task focused permission sets and control sensitive information   You can create a set of custom permissions using any of the permissions listed under  General Project Permissions   general project permissions    Some permissions  such as the project access permission  are tiered  You can only assign one permission per category because higher level permissions include the capabilities of lower levels      Organization Permissions  Separate from project and workspace permissions  you can grant teams permissions to manage or view certain resources or settings across an organization  To set these permissions for a team  go to your organization s   Settings    Then click   Teams    and select the team name from the list   The following organization permissions are available       Project permissions  You must select a level of access for projects        None  Members do not have access to projects or workspaces  You can grant permissions to individual projects or workspaces through  Project Permissions   terraform cloud docs users teams organizations permissions project permissions  or  Workspace Permissions   terraform cloud docs users teams organizations permissions workspace permissions         View all projects  Members can view all projects within the organization  This lets users    View project names in a given organization        Manage all projects  Members can create and manage all projects and workspaces within the organization  In addition to the permissions granted by   Manage all workspaces    terraform cloud docs users teams organizations permissions manage all workspaces   this also lets users    Manage other teams  access to all projects    Create  edit  and delete projects  otherwise only available to organization owners     Move workspaces between projects       Workspace permissions  You must select a level of access for workspaces        None  Members do not have access to projects or workspaces  You can grant permissions to individual projects or workspaces through  Project Permissions   terraform cloud docs users teams organizations permissions project permissions  or  Workspace Permissions   terraform cloud docs users teams organizations permissions workspace permissions         View all workspaces  Members can view all workspaces within the organization  This lets users    View information and features relevant to each workspaces  e g  runs  state versions  variables         Manage all workspaces  Members can create and manage all workspaces within the organization  This lets users    Perform any action that requires admin permissions in those workspaces    Create new workspaces within the organization s   Default Project    an action that is otherwise only available to organization owners    Create  update  and delete  Variable Sets   terraform cloud docs workspaces variables managing variables variable sets        Manage Policies  Allows members to create  edit  read  list and delete the organization s Sentinel policies   This permission implicitly gives permission to read runs on all workspaces  which is necessary to set enforcement of  policy sets   terraform cloud docs policy enforcement manage policy sets        Manage Run Tasks  Allows members to create  edit  and delete run tasks on the organization       Manage Policy Overrides  Allows members to override soft mandatory policy checks   This permission implicitly gives permission to read runs on all workspaces  which is necessary to override policy checks       Manage VCS Settings  Allows members to manage the set of  VCS providers   terraform cloud docs vcs  and  SSH keys   terraform cloud docs vcs ssh keys  available within the organization       Manage Agent Pools  Allows members to create  edit  and delete agent pools within their organization   This permission implicitly grants access to read all workspaces  which is necessary for agent pool management       Manage Private Registry  Allows members to publish and delete providers  modules  or both providers and modules in the organization s  private registry   terraform cloud docs registry   These permissions are otherwise only available to organization owners       Team Management Permissions  HCP Terraform has three levels of team management permissions  manage membership  manage teams  and manage organization access  Each permission level grants users the ability to perform specific actions and each progressively requires prerequisite permissions    For example  to grant a user the manage teams permission  that user must already have manage membership permissions  To grant a user the manage organization access permission  a user must have both manage teams and manage membership permissions        Manage Membership  Allows members to invite users to the organization  remove users from the organization  and add or remove users from teams within the organization   This permission grants the ability to view the list of users within the organization  and to view the organization access of other visible teams  It does not permit the creation of teams  the ability to modify the settings of existing teams  or the ability to view secret teams   In order to modify the membership of a team  a user with Manage Membership permissions must have visibility into the team  i e  the team must be   Visible    terraform cloud docs users teams organizations teams manage team visibility   or the user must be on the team   In order to remove a user from the organization  the holder of this permission must have visibility into all of the teams which the user is a member of      This permission is intended to allow owners of large organizations to delegate membership management to another trusted team  and should be granted to only teams of trusted users    Assign with caution    Users with this permission are able to add themselves to any visible team  and inherit the permissions of any visible team        Manage Teams  Allows members to create  update  and delete teams  and generate  regenerate  and revoke tokens   This permission grants the ability to update a team s names  SSO IDs  and token management permissions  but does not allow access to organization settings  On its own  this permission does not allow users to create  update  delete  or otherwise access secret teams   The manage teams permission confers all permissions granted by the manage membership permission   This permission allows owners of large organizations to delegate team management to another trusted team  You should only grant it to teams of trusted users        Assign with caution    Users with this permission can update or delete any visible team  Because this permission also confers the manage membership permission  a user with the manage teams permission can add themselves to any visible team        Manage Organization Access  Allows members to update a team s organization access settings   On its own  this permission does not allow users to create  update  delete  or otherwise access secret teams  This permission confers all of the permissions granted by the manage teams and manage membership permissions   This permission allows owners of large organizations to delegate team management to another trusted team  You should only grant it to teams of trusted users         Assign with caution    Members with this permission can update all organization access settings for any team visible to them       Include Secret Teams  Allows members access to secret teams at the level permitted by that user s team permissions setting   This permission acts as a modifier to existing team management permissions  Members with this permission can access secret teams up to the level permitted by other team management permissions  For example  if a user has permission to include secret teams and  manage teams   terraform cloud docs users teams organizations permissions manage teams   that user can create secret teams       Allow Member Token Management  Allows owners and members with  manage teams   terraform cloud docs users teams organizations permissions manage teams  permissions to enable and disable team token management for team members  This permission defaults to  true    When member token management is enabled  members will be able to perform actions on team tokens  including generating and revoking a team token   When member token management is disabled  members will be unable to perform actions on team tokens  including generating and revoking a team token      Permissions Outside HCP Terraform s Scope  This documentation only refers to permissions that are managed by HCP Terraform itself   Since HCP Terraform integrates with other systems  the permissions models of those systems can also be relevant to the overall security model of your HCP Terraform organization  For example     When a workspace is connected to a VCS repository  anyone who can merge changes to that repository s main branch can indirectly queue plans in that workspace  regardless of whether they have explicit permission to queue plans or are even a member of your HCP Terraform organization   And when auto apply is enabled  merging changes will indirectly apply runs     If you use HCP Terraform s API to create a Slack bot for provisioning infrastructure  anyone able to issue commands to that Slack bot can implicitly act with that bot s permissions  regardless of their own membership and permissions in the HCP Terraform organization    When a run task sends a request to an integrator  it provides an access token that provides access depending on the run task stage      For post plan  it provides access to the runs plan json and the run task callback     All access tokens created for run tasks have a lifetime of 10 minutes  When integrating HCP Terraform with other systems  you are responsible for understanding the effects on your organization s security  An integrated system is able to delegate any level of access that it has been granted  so carefully consider the conditions and events that will cause it to delegate that access