> ## Documentation Index
> Fetch the complete documentation index at: https://docs.envzero.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Terraform provider settings for sub-environments

> How sub_environment_configuration in the env zero Terraform provider interacts with env0.workflow.yaml: storage, which deployments honor it, and precedence.

A workflow environment can be configured from two places: the `sub_environment_configuration` block of the [`env0_environment` resource](https://registry.terraform.io/providers/env0/env0/latest/docs/resources/environment) in the env zero Terraform provider, and the [`env0.workflow.yaml` file](/guides/admin-guide/workflows/workflow-file-reference). Settings that exist in both do not always behave the same way.

## Field reference

| Field | Where the value is stored | Which deployments honor it | Which surface wins |
| - | - | - | - |
| `alias` | Not stored. Must match the key of the sub-environment under `environments` in the workflow file. | All | The workflow file defines the aliases. |
| `approve_plan_automatically` | Every deployment that Terraform triggers saves it on the sub-environment as its approval setting, and so does create, even when `prevent_auto_deploy` is `true`. The provider does not read it back into state. | All, as the last fallback. See [How approval is resolved](#how-approval-is-resolved). | Terraform for the deployment it triggers, ahead of the workflow file. For every other deployment, its own request value when it sets one, then the workflow file when it sets `requiresApproval`, otherwise the saved setting. |
| `configuration` | Environment-scoped variables on the sub-environment. The provider reads them back into state, so changes made in the UI or API show as drift, except the values of sensitive variables. The API redacts those, so the provider keeps the state value and a changed secret is not detected. | All | Terraform. The workflow file has no variables section. |
| `workspace` | The sub-environment's workspace name, set once when env zero creates the sub-environment. | All | Terraform over the workflow file's `workspace`, at creation only. Changing it after creation does not change the workspace. It triggers a deployment unless `prevent_auto_deploy` is `true`. |
| `revision` (deprecated) | Not stored. The provider sends it as an override for a single deployment. | Deployments that Terraform triggers only. | Terraform for the deployment it triggers. The workflow file's `revision` for every other deployment. Set `revision` in the workflow file instead. |
| `id` | Computed. The sub-environment's environment ID. | n/a | n/a |

## How approval is resolved

For each sub-environment, a deployment resolves approval in this order: the value in the deployment request, then the workflow file's `requiresApproval`, then the saved setting. These are steps 3 to 5 of the [approval priority order](/guides/admin-guide/workflows/create-a-new-workflow#approval-priority-order).

The provider sends `approve_plan_automatically` in the deployment request, so for the deployment Terraform triggers it wins over the workflow file, and env zero saves it on the sub-environment. The field defaults to `true`, so a block that omits it still sends "no approval required", and that overrides a `requiresApproval: true` in the workflow file for that deployment.

A deployment started from the UI, the API, a VCS push, or a schedule does not carry Terraform's value. For each sub-environment it uses the value in its own request when one is set, then the workflow file's `requiresApproval` when set, and otherwise the saved setting. The deploy dialog's **Approve automatically** checkbox and the API's `subEnvironments.<alias>.userRequiresApproval` field set a request value. VCS pushes and schedules do not.

<Warning>
  When the workflow file sets `requiresApproval`, that value replaces the saved setting on the next deployment that Terraform did not trigger. Terraform state keeps showing the value you configured, because the provider does not read the saved setting back, so no drift is reported.

  To require approval regardless of what triggers the deployment, set both values: `approve_plan_automatically = false` in the Terraform block and `requiresApproval: true` in the workflow file. A deployment request that sets its own approval value, such as the deploy dialog's **Approve automatically** checkbox, still overrides both for that deployment.
</Warning>

```hcl main.tf theme={null}
resource "env0_environment" "workflow" {
  name        = "my-workflow"
  project_id  = "<YOUR_PROJECT_ID>"
  template_id = "<YOUR_WORKFLOW_TEMPLATE_ID>"

  sub_environment_configuration {
    alias                      = "kubernetes-cluster"
    approve_plan_automatically = false
  }
}
```

```yaml env0.workflow.yaml theme={null}
environments:
  kubernetes-cluster:
    name: "Kubernetes Cluster"
    templateName: "eks"
    requiresApproval: true
```

## Updates with `prevent_auto_deploy`

With `prevent_auto_deploy = true`, an update to the resource writes only `configuration` changes to env zero. The provider sends `approve_plan_automatically` and `workspace` only as part of a deployment it triggers, so Terraform records changes to them in state, but they never reach env zero. On create, `approve_plan_automatically`, `workspace`, and `configuration` take effect, and `revision` has no deployment to apply to.

## Next steps

* [Approval policies](/guides/policies-governance/approval-policies) - Require approval by policy, evaluated before the request and workflow file values.
* [Partial workflow deployment](/guides/admin-guide/workflows/workflow-partial-deployment) - Deploy or destroy a subset of the workflow graph.
* [Managing workflow variables](/guides/admin-guide/variables/workflow-variables) - Configure variables and output passing at the template level.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.