# Schedules: ScheduleWorkflowAction.VersioningOverride is stored but never applied to started workflows (V1 scheduler)

**URL:** <https://community.temporal.io/t/schedules-scheduleworkflowaction-versioningoverride-is-stored-but-never-applied-to-started-workflows-v1-scheduler/19831>\
**Category:** Community Support\
**Tags:** server\
**Created:** [September 30, 2026, 2:18pm UTC](https://community.temporal.io/t/schedules-scheduleworkflowaction-versioningoverride-is-stored-but-never-applied-to-started-workflows-v1-scheduler/19831 "2026-09-30T14:18:24Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![jingyu.wang](https://avatars.discourse-cdn.com/v4/letter/j/e19b73/32.png) [@jingyu.wang](https://community.temporal.io/u/jingyu.wang)\
**Post date:** [September 30, 2026, 2:18pm UTC](https://community.temporal.io/t/schedules-scheduleworkflowaction-versioningoverride-is-stored-but-never-applied-to-started-workflows-v1-scheduler/19831/1 "2026-09-30T14:18:25Z")

</div>

### **Expected Behavior**

A Schedule whose action carries a `VersioningOverride` (e.g. a pinned Worker  
Deployment Version) should start its workflows with that override applied, the  
same way a direct `StartWorkflowExecution` with the same override does.

This matters for schedules whose workflow input shape changes between builds: the  
override is the only way to keep a schedule’s declared input and the code that  
receives it on the same Worker Deployment Version.

### **Actual Behavior**

The override is accepted, persisted and readable back via `DescribeSchedule`, but  
it is never applied to the workflows the Schedule starts. The started executions  
have no versioning override at all and are routed to the Current version.

Issue: [Schedules: ScheduleWorkflowAction.VersioningOverride is stored but never applied to started workflows (V1 scheduler) · Issue #12148 · temporalio/temporal · GitHub](https://github.com/temporalio/temporal/issues/12148)