Bring your towel and join one of the fastest growing data communities. Welcome to our second-generation open source orchestration platform, a completely rethought approach to dataflow automation.

Prefect Community

Hello, we are a Cloud client migrating from Agents to Workers. We previously used `Deployment.build_from_flow()` to apply deployments. Now, we’ve transitioned to `flow.deploy()`.

However, we’re having issues with schedules. When we set a schedule in the UI for a deployed flow, the next time we run `flow.deploy()` (with no schedule parameters) applied to that same deployment, the schedule is wiped out. With `Deployment.build_from_flow()` , when a schedule didn’t exist as a parameter, the schedule persisted on the server.

CC <@U03H2FJBWQL>

`Deployment.build_from_flow()` has a default = `True` boolean parameter:
```load_existing: if True, load any settings that may already be configured for
                the named deployment server-side (e.g., schedules, default parameter
                values, etc.)```
whereas `flow.deploy()` has no such discernible functionality.

This means to me that schedules must be maintained in the codebase in order to be persisted after an environment deploy. Unless I’m incorrect (very possible, and happy to be), this seems like a step in the wrong direction.

Hey Garren - we've heard a few reports of this issue not meeting user expectations so are looking into a resolution ASAP; `.deploy` is currently a workflows-as-code approach (designed with CI/CD in mind) that ensures your workflow state is exactly as it is defined in code.  That being said, we realize some folks take a different approach so are discussing our most viable and maintainable options

Thanks Chris. So is your short-term recommendation to check schedules in? For our org, which prefers to manage scheduling outside of code/releases - would we expect a long term solution similar to that of `Deployment.build_from_flow()` and when in your best estimate would we see such a solution?

You can understand that I will have to sell this to the org, which hasn’t habituated involving engineering to make minor scheduling adjustments.

I expect us to have a resolution to this within the next two weeks, it's high priority for us after the initial 3.0 GA.

Honestly, given that we hope to have a resolution in a short timeframe, you could continue to use your current setup and then migrate off of agents after the change is released.

Ok, thanks. Final question - can you provide a link to the issue we can follow?

Yup, this issue should track what you're looking for: <https://github.com/PrefectHQ/prefect/issues/14973>