Collaborating with HCP Terraform and Terraform Enterprise
Objects and workflow
HCP Terraform organizes everything under an organization, then projects, then workspaces. A workspace owns state, variables, and run history and can be VCS-driven (runs triggered by commits and pull requests), CLI-driven via the cloud block, or API-driven. The cloud block replaced the old remote backend and takes organization, hostname, and either workspaces { name = ... } or tag-based matching. Runs pass through plan, cost estimation, policy check, and apply; a speculative plan on a pull request never applies.
Collaboration levers
Run triggers queue a downstream workspace run after an upstream run applies successfully - strictly one direction, no cycles. Variable sets share values across workspaces or projects, but a workspace-level variable with the same key wins. Terraform variables and environment variables are separate categories; only environment variables can configure provider credentials. Teams and SSO map to permissions, and state access is per workspace, which is why terraform_remote_state with an explicit hostname and workspace is the sanctioned cross-workspace pattern. Run tasks call external APIs mid-run; agents reach private VCS or network endpoints.
Traps
terraform apply against a VCS-driven workspace does not execute locally - it queues a remote run, so local-only flags and local credentials are irrelevant. terraform state operations on remote workspaces require permission and are logged. Sensitive variables are write-only in the UI but still land in plaintext state, so state access control is the real boundary.
Rule of thumb
Treat workspaces as environments or components, order them with run triggers, and keep shared credentials in project-scoped variable sets rather than duplicating them per workspace.