Automating Workspace-to-Workspace Dependencies with Terraform Cloud Run Triggers

When you split infrastructure into layers — network → platform → app — across multiple workspaces, Run Triggers are what reliably re-plan and re-apply downstream when something upstream changes. You can automate the dependency entirely inside Terraform Cloud without manual operations or external CI.

Note, though, that Run Triggers are a mechanism for sequencing runs. They do not pass values. Read values via remote state and let triggers focus on kicking off runs — that role split is the core design.

Run Triggers: the big picture and use cases

A Run Trigger automatically queues a run in another workspace (within the same organization) whenever a workspace's run reaches a successful apply. You no longer need a VCS commit or UI click to keep upstream → downstream dependencies in sync — Terraform Cloud handles it end-to-end.

You can fan out from one upstream to many downstreams, and you can fan in from multiple upstreams to a single downstream. Cycles are rejected at creation time. Run Triggers themselves never carry values — outputs are read via data.terraform_remote_state. Workspaces with execution mode = local will not execute even when triggered, so remote execution is a prerequisite. Speculative plans (PR plans) and plan-only runs do not trigger downstreams.

• Only available within a single organization
• Successful upstream apply auto-queues the downstream
• Does not pass data (pair with remote state)
• Fan-out / fan-in supported, cycles forbidden
• Downstream must be remote execution; local is unsupported
• Speculative plans and failures do not fire triggers

Example dependency chain across workspaces

Minimal tfe_run_trigger example (A's success triggers B)

provider "tfe" {}

# Resolve existing workspace IDs by name via a data source
data "tfe_workspace" "a" {
  name         = "network-a"
  organization = var.org
}

data "tfe_workspace" "b" {
  name         = "platform-b"
  organization = var.org
}

resource "tfe_run_trigger" "a_to_b" {
  workspace_id  = data.tfe_workspace.b.id       # downstream
  sourceable_id = data.tfe_workspace.a.id       # upstream
}

Outputs via remote state, execution via Run Triggers

The core design rule is a role split. Read outputs (vpc_id, subnet_ids, etc.) through remote state, and use Run Triggers only to auto-queue downstream runs. That setup eliminates human error and forgotten manual runs while keeping the dependency explicit in code.

When you use the remote backend within the same organization, Terraform Cloud injects a token so state is accessible without additional configuration. Sensitive outputs stay sensitive, but design your outputs to minimize exposure regardless.

• Share values only through remote state; avoid passing them as plain variables or injecting them via external CI environment variables
• Add validation in the downstream so it fails safely when remote state lookups fail
• Keep Run Triggers focused on guaranteeing consistent auto-execution
• Keep outputs minimal, name them consistently, and declare types explicitly (map / list / number / string)

Reading upstream outputs via data.terraform_remote_state

terraform {
  backend "remote" {
    organization = var.org
    workspaces {
      name = "app-c"
    }
  }
}

data "terraform_remote_state" "network" {
  backend = "remote"
  config = {
    organization = var.org
    workspaces = { name = "network-a" }
  }
}

data "terraform_remote_state" "platform" {
  backend = "remote"
  config = {
    organization = var.org
    workspaces = { name = "platform-b" }
  }
}

module "app" {
  source  = "./modules/app"
  vpc_id  = data.terraform_remote_state.network.outputs.vpc_id
  subnet_ids = data.terraform_remote_state.platform.outputs.subnet_ids
}

Setup options (UI / API / Terraform Provider) and comparison

You can create Run Triggers via the Terraform Cloud UI, the TFC/TFE API, or the Terraform Provider (tfe). For teams that prize reproducibility, the tfe provider with the tfe_run_trigger resource is the safest bet. The UI is fine for quick experiments, and the API is useful when integrating with existing automation.

Creating or modifying triggers requires at least Maintainer-equivalent permissions on the target workspace. Because the trigger is attached to the downstream workspace, double-check that you have the right permissions on the downstream side.

• UI: Workspace → Settings → Run Triggers to link upstream/downstream
• API: CRUD via the /workspaces/:id/run-triggers endpoint
• IaC: declarative management with tfe_run_trigger (recommended)

Codifying Run Triggers with Terraform (equivalent to the UI setup)

provider "tfe" {}

variable "org" {}

resource "tfe_workspace" "a" {
  name         = "network-a"
  organization = var.org
  execution_mode = "remote"
}

resource "tfe_workspace" "b" {
  name         = "platform-b"
  organization = var.org
  execution_mode = "remote"
}

resource "tfe_run_trigger" "a_to_b" {
  workspace_id  = tfe_workspace.b.id   # downstream
  sourceable_id = tfe_workspace.a.id   # upstream
}

Run lifecycle and failure behavior

When an upstream workspace completes plan → (approval if required) → apply successfully, a run is queued on the downstream workspace. If the downstream has Auto apply disabled, the run pauses for approval after the plan. Policy violations (Sentinel / Run Tasks) or plan failures stop the chain.

When multiple upstreams trigger a single downstream, the downstream follows its workspace queue settings and runs them serially. They cannot run in parallel, but as long as your plans are idempotent that is not an issue. Cycles are blocked at creation time.

• Trigger condition: only on a successful upstream apply
• Plan-only, failed, or canceled runs do not fire
• The downstream's Auto apply setting decides whether manual approval is required
• Fan-in runs execute serially on the downstream (no parallel execution)
• You can verify Reason = run_trigger in the UI Run details

Controlling downstream auto-apply (per-environment example)

resource "tfe_workspace" "app_dev" {
  name           = "app-dev"
  organization   = var.org
  execution_mode = "remote"
  auto_apply     = true   # dev auto-applies
}

resource "tfe_workspace" "app_prod" {
  name           = "app-prod"
  organization   = var.org
  execution_mode = "remote"
  auto_apply     = false  # prod requires approval
}

Security, permissions, and organization boundaries

Run Triggers are scoped to a single organization. Creating or modifying them requires admin-level rights on the target workspace (typically Maintainer or higher). If you need cross-org dependencies, split them at the design stage and add an alternative control plane such as notifications or approvals.

Value sharing via remote state is powerful but watch for over-exposure. Keep outputs minimal, ideally wrap them in an aggregator module, and have downstreams read only the keys they need. Take care that sensitive outputs do not leak into downstream logs or external notifications.

• Triggers work only within the same organization (no cross-org)
• Create permission: Maintainer / Admin equivalent on the target workspace
• Remote state is read safely via the org token (keep outputs minimal)
• Distribute credentials with Variable Sets, never via outputs
• Downstream must run execution_mode = remote (local is unsupported)

Distributing shared credentials via a Variable Set (not via outputs)

resource "tfe_variable_set" "shared_creds" {
  name         = "shared-creds"
  organization = var.org
  description  = "Shared provider credentials for all envs"
}

resource "tfe_variable" "aws_access_key" {
  key             = "AWS_ACCESS_KEY_ID"
  value           = var.aws_access_key_id
  sensitive       = true
  category        = "env"
  variable_set_id = tfe_variable_set.shared_creds.id
}

resource "tfe_workspace_variable_set" "attach" {
  variable_set_id = tfe_variable_set.shared_creds.id
  workspace_id    = data.tfe_workspace.app.id
}

Exam takeaways (Authoring & Operations Pro)

Lead with the role split: Run Triggers are for auto-chaining execution, remote state is for sharing values. Run Triggers are organization-scoped, fire on successful upstream apply, queue downstream runs, do not pass data, and require remote execution downstream. Those are the high-frequency hit points.

You can configure them via UI / Provider / API, but for reproducibility tfe_run_trigger is the model answer. Earn extra credit by tying the design back to downstream Auto apply, policy checks, and serial execution under fan-in.

• Run Triggers do not pass values → read outputs via remote state
• Same-org only; cycles forbidden; fan-out / fan-in supported
• Fires only on successful upstream apply (plan-only does not fire)
• Be able to explain how downstream Auto apply interacts with policy checks
• tfe_run_trigger is the first-choice IaC primitive

Remote backend definition (minimal exam-style example)

terraform {
  backend "remote" {
    organization = var.org
    workspaces {
      name = "platform-b"
    }
  }
}

# Explicitly expose outputs from the upstream workspace
output "subnet_ids" {
  value = module.network.subnet_ids
  sensitive = false
}

Check Your Understanding

Frequently Asked Questions