Control Schedule Activation per Environment in Deployment Pipelines

[frithjof_v]

Currently, with the new multiple scheduler feature, we can define multiple run schedules for a Fabric item. However, when using deployment pipelines, there’s no way to control which schedules are active in Dev, Test, or Prod. This means schedules intended only for Prod must also run in Dev, consuming unnecessary compute.

It would be very useful to allow using the Variable Library or deployment rules to set the active/inactive state of each schedule per environment, making deployments more efficient and flexible.

[PedroMorais]

Just a suggestion, If we look at the 'schedule; file we can see on the content:

{
  "$schema": "https://developer.microsoft.com/json-schemas/fabric/gitIntegration/schedules/1.0.0/schema.json",
  "schedules": [
    {
      "enabled": true,
      "jobType": "Execute",
      "configuration": {
        "type": "Daily",
        "startDateTime": "2025-10-10T00:00:00",
        "endDateTime": "2029-12-31T23:59:00",
        "localTimeZoneId": "GMT Standard Time",
        "times": [
          "05:00"
        ]
      }
    }
  ]
}

I think that just adding the WorkspaceId or Workspace to the schedule entry would be enough. No need to change the deployment pipeline, it would just have multiple entries, one for each workspace where we need the notebook to run.

[hedeencharles]

@zhaya I am excited for this feature to be implemented! Being able to assign a variable from a variable library to the schedule would be huge. Currently, we set the schedule file to 'true' to run in production and manually disable schedules in dev and test environments via the UI.

[zhaya]

We are planning for a work to allow users control the Scheudler On/Off state with variable library. The ETA would be March 2026. Thank you all for your feedback!

[hedeencharles]

Thank you for the update @zhaya !

[fpvmorais1]

Thanks for the update and for telling us we will get a way of dealing with this.

[zhaya]

The release of this feature has been moved from March to June due to additional design considerations and corner cases. This change allows us to deliver a more reliable solution. Thank you for your understanding!