Difference in pipeline scheduling between DEV and PROD causes confusion during deployment

[Corujo]

Hi everyone,

I’m currently implementing a data pipeline that is deployed from a DEV workspace to a PROD workspace in Microsoft Fabric.

In my setup, I want the pipeline to run daily only in PROD, but not in DEV (since DEV is used just for testing and development). However, when I set up the daily schedule in the PROD environment, this creates a difference between the DEV and PROD versions of the pipeline.

As a result, when I compare or deploy changes, Fabric shows differences in the pipeline configuration, which makes it confusing — it looks like the pipelines are out of sync, even though the only intended difference is the scheduling configuration.

Has anyone else faced this situation?

How do you handle environment-specific configurations like pipeline triggers or schedules between DEV and PROD in Fabric?

Thanks in advance for your insights!

Best regards,

Carlo

[v-sshirivolu]

Hi @Corujo ,

This is a common scenario when managing Microsoft Fabric pipelines across different environments. It’s best to handle scheduling as environment-specific, rather than embedding it in the pipeline itself. You can keep the pipeline design consistent in both DEV and PROD, but manage the schedule separately in each workspace.

For your situation, consider removing the daily schedule from the DEV pipeline and only setting it up in the PROD workspace after deployment. This keeps the pipeline design in sync across environments, with scheduling as the only difference. You can do this manually or automate it using PowerShell or the Fabric API.

Alternatively, you could create a small orchestrator pipeline in PROD to run the main pipeline on a schedule, while in DEV you run it manually for testing. If you’re using Deployment Pipelines, you can set rules to keep schedules disabled in DEV and active in PROD. In general, separating schedules from the main pipeline helps keep DEV and PROD aligned and avoids confusion during deployment.

[Corujo]

I have several master Data Pipelines that orchestrate different isolated processes, each with its own schedule. I don’t like the idea of creating additional pipelines in production just for the purpose of scheduling the execution of these other pipelines, since they are already designed as masters themselves.

For now, I think I’ll leave it as it is: I’ll remove the schedule in DEV and enable it only in PROD, even though I don’t like seeing schema differences when deploying elements because it can be confusing.

I hope that in the future it will be possible to create deployment rules for this kind of scenario, as I believe it’s a common use case in real-world implementations. In the end, we all want to clearly understand which elements have actually changed between DEV and PROD to improve efficiency.

[v-sshirivolu]

Hi @Corujo ,

I agree, the deployment pipeline comparison in Fabric does include scheduling details such as triggers as part of the pipeline definition. That’s why you’re noticing differences between DEV (no schedule) and PROD (daily trigger). Until environment specific deployment rules are available, you might consider documenting the expected schedule differences in your deployment checklist or workspace documentation to make reviews and comparisons easier. Alternatively, you can automate trigger setup after deployment, for example, if you’re using the API or PowerShell, include a step to re-enable or update the PROD trigger once deployment is complete. This helps keep environments consistent while ensuring that the production schedule continues to run as intended.

It would also be helpful to share this feedback through Microsoft’s official feedback channels, such as Microsoft Fabric Ideas -

https://community.fabric.microsoft.com/t5/Fabric-Ideas/idb-p/fbc_ideas/ideas/search-ideas

Feedback submitted through these channels is frequently reviewed by the product teams and can contribute to meaningful improvements.

Best regards,
Sreeteja

[v-sshirivolu]

Hi @Corujo ,

I hope the above details help you fix the issue. If you still have any questions or need more help, feel free to reach out. We’re always here to support you