Question for the Frappe Community 
@ejaaz @ankush @NCP
When managing Workflows in Frappe/ERPNext, what do you prefer: Fixtures or Patches?
For example, when creating or updating Workflow States, Workflow Actions, and Workflow Transitions, should we manage them through fixtures or use patches?
What is the best practice for maintaining these changes across development, staging, and production environments?
I’d love to hear how experienced Frappe developers handle this in real-world projects.
I use both, for different jobs.
Fixtures are what I use to ship the workflow itself (states, actions, transitions). They live in git and sync on every migrate, so dev, staging and production stay identical. One catch: migrate overwrites the workflow every time, so if someone edits it from the UI in production, those changes get lost. Also filter your export to only your workflows, and don’t forget to export the Workflow States and Action Masters too, or the migrate will fail on missing links.
Patches are what I use when a change also touches existing data. For example, if you rename a state, the documents already sitting in the old state need to be updated, and a fixture won’t do that. A patch runs once per site and can fix both the workflow and the documents together.
So my rule is that fixtures define the workflow and patches handle data changes. If you rename a state, do both: update the fixture and add a patch to move the existing documents.
If the client’s admins keep tweaking workflows on live, a fixture will keep resetting their changes. In that case, go with patches onl
I agree but for fixture while migration we can use bench --site <site_name> migrate --skip-fixture like commands to skip fixtures while every migration.
but when we install the app first time i notice that Patches will not execute. it execute while migration and if again we want to execute same patch then we have to delete Patch log and migrate.
Patches are mostly used to migrate or transform data from one version to another when schema-level changes occur, ensuring existing clients’ data remains compatible with the updated schema.
Yeah, totally agree with both points.
--skip-fixtures is a handy flag. I checked and it exists in the current Frappe migrate command. It’s useful when you don’t want a migrate to overwrite a workflow that someone tweaked on production. The only downside is that you have to remember to run a normal migrate when you actually want the fixture to sync.
You’re also right about patches on a fresh install. Frappe marks all the patches as done and doesn’t run them, because a new site already has the latest schema and no old data to fix. So anything a new site needs should be in a fixture or after_install, not in a patch. To re-run a patch you have to delete its Patch Log entry, or just call it with bench execute. Writing patches so they’re safe to run twice also helps.
I see patches the same way you do: for moving existing data after a schema change, so old clients stay compatible. For workflows, that means fixtures for the definition and a patch only when existing documents need updating, like a renamed state.
Thanks for the explanation! This is a useful distinction between fixtures and patches.
One question: if we manage Workflows through fixtures, how do we handle changes to existing Workflow States or Transitions in production, especially when those changes affect documents that are already using the old state?
Would you recommend combining fixtures with a patch to migrate existing documents safely, or is there a better approach for handling such changes across multiple environments?
Patches all the way, always. You can manage workflows with patches, since that’s what earlier comments mention as where they use fixtures.
You can rerun a patch by simply adding a new identifier to the end of the line in patches.txt; unlike fixture which gets applied on each migrate.
@rtdany10
If we can manage workflows through patches, what is the need for fixtures? Also, why do we need to add a new identifier to patches.txt to rerun a patch? Instead of modifying patches.txt, can’t we update the latest workflow changes directly and migrate. Since fixtures are applied on every migrate, skipping them could also prevent unintended overwrites of existing workflow changes.
I recommend managing Workflows through fixtures and ensuring that any changes required in production are first made and tested in the local development environment, then deployed through the proper release process. Although this approach may take more time, it is safer and more maintainable because it keeps Workflow configurations consistent across environments and reduces the risk of unintended changes to existing documents in production
I agree that different developers follow different approaches based on their requirements. However, I’m looking for the approach recommended by the Frappe framework itself.