Publishing or refactoring an automation/workflow can change workflow state IDs. Any downstream dependency that references those states then breaks, even when the logical workflow behavior did not change.
Problem
Workflow state IDs are not stable across publish/refactor. When a workflow is republished, existing states/tasks can receive new IDs. Anything depending on those state IDs is then invalidated.
This is especially risky for dependencies between workflow pieces, generated/exported config, Terraform/OpenTofu resources, or any integration that stores references to workflow states.
Expected behavior
- Publishing should preserve stable state IDs for existing workflow states/tasks whenever the logical state still exists.
- Refactors that do not semantically replace a state should not invalidate downstream dependencies.
- New state IDs should only be created for genuinely new states.
- Removed states should be deleted explicitly, not recreated under new IDs as part of a normal publish.
- If a publish must replace a state ID, it should be surfaced as an explicit breaking change before apply/publish completes.
Actual behavior
- Publishing/refactoring an automation/workflow can change state IDs.
- Existing dependencies that reference those IDs break after publish.
- The breakage is easy to miss until dependent workflow/configuration behavior fails.
Impact
This is a huge blocker for safely iterating on automations/workflows. We cannot confidently publish workflow changes if doing so may silently invalidate dependencies.
Suggested direction
The publish path should reconcile workflow states against an existing published workflow using a stable authoring identity/key, then preserve the existing platform state ID for matching states. Only unmatched new states should get new IDs, and unmatched old states should be treated as deletions.
Related but distinct issue: https://github.com/elementumltd/fde-tf-cli-old/issues/97 tracks exported elementum_workflow_publish missing depends_on; this issue is specifically about state ID stability across publish/refactor.
Publishing or refactoring an automation/workflow can change workflow state IDs. Any downstream dependency that references those states then breaks, even when the logical workflow behavior did not change.
Problem
Workflow state IDs are not stable across publish/refactor. When a workflow is republished, existing states/tasks can receive new IDs. Anything depending on those state IDs is then invalidated.
This is especially risky for dependencies between workflow pieces, generated/exported config, Terraform/OpenTofu resources, or any integration that stores references to workflow states.
Expected behavior
Actual behavior
Impact
This is a huge blocker for safely iterating on automations/workflows. We cannot confidently publish workflow changes if doing so may silently invalidate dependencies.
Suggested direction
The publish path should reconcile workflow states against an existing published workflow using a stable authoring identity/key, then preserve the existing platform state ID for matching states. Only unmatched new states should get new IDs, and unmatched old states should be treated as deletions.
Related but distinct issue: https://github.com/elementumltd/fde-tf-cli-old/issues/97 tracks exported
elementum_workflow_publishmissingdepends_on; this issue is specifically about state ID stability across publish/refactor.