Expose Workflow Version Metadata in Expressions and Execution Context

Feature Requests
1

The idea is:

n8n workflows support versioning internally, but the workflow that is executing cannot determine which workflow version/revision is currently running.

Today we can access metadata such as workflow ID and workflow name, but there doesn’t appear to be a way to retrieve the workflow version or revision identifier from expressions, Code nodes, or execution context.

This creates challenges for:

  • Audit logging
  • Release tracking
  • Deployment validation
  • Debugging production incidents
  • Sub-workflow version tracking
  • Compliance and change management

My use case:

1. Audit Logs

Include workflow version information in execution logs:

{
  "workflowId": "...",
  "workflowName": "...",
  "workflowVersion": "..."
}

2. Deployment Verification

Send a Slack notification after deployment that includes the exact workflow version currently active.

3. Production Troubleshooting

When reviewing an execution from several days ago, determine exactly which workflow revision produced the result.

4. Sub-workflow Traceability

Parent workflows can record which sub-workflow version was invoked during execution.

I think it would be beneficial to add this because:

  • Improved observability
  • Easier debugging
  • Better deployment confidence
  • More complete audit trails
  • Better support for enterprise governance and compliance requirements

Since n8n already appears to maintain workflow version identifiers internally, this seems like a relatively small API-surface enhancement that would provide significant operational value.

Any resources to support this?

N/A

Are you willing to work on this?

Yes, absolutely! If we can agree on the design, I will happily contribute this.

Proposed Solution

Expose workflow version metadata similarly to existing workflow metadata.

Possible APIs:

$workflow.versionId

$workflow.revision

or

$execution.workflowVersionId

Expected Behaviour

  • The value should represent the exact workflow version used for that execution.
  • Historical executions should preserve the version identifier that actually ran.
  • The metadata should be available in:
    • Expressions
    • Code nodes
    • Execution data
    • Error workflows
    • Sub-workflow executions
2

Voted - this gap is real, especially in error workflows where you need to know which version caused the failure. As a workaround right now, I inject a version constant via a Set node at the top of each workflow (e.g. workflow_version: "1.4.2") and reference it in logs and error payloads - manual but it works until something native is available.