Ability to have a master flow which can push changes to inherited flows on update

Feature Requests
,
1

In software development, this is known as the DRY (Don’t Repeat Yourself) principle. Right now in n8n, if you have 20 workflows that all use the exact same sequence of nodes, and you need to make a change, you have to manually edit all 20 workflows.

The idea is:

I’m proposing a system where a master (blueprint) dictates the structure, and any child workflows inherit that structure. When the Master is updated, the changes cascade down to all the linked child nodes automatically.

  • The inheritance feature can be a choice and inherited workflows can be standalone workflows without any connection to master workflow.
  • There should be also a choice to push changes automatically or manually so we can chose which child nodes should receive changes and what not.
  • There should be also a choice to update only the nodes we want.

My use case:

I’m currently handling 15+ workflows that are almost identical as we use them to generate SEO content for different clients. The differences are in trigger webhooks (that differentiate clients) and different Pinecone setups which are unique to each client. Also, as we expect to scale, and if we decided to use somehow one workflow for all clients, we would eventually hit 200 concurrent runs limitation and would need to have the master-child logic at some point.

I think it would be beneficial to add this because:

This would save a lot of time on workflow maintenance and improvement.

Are you willing to work on this?

Yes, I am!

2

Hi @flowRunner, interesting idea.

As a practical workaround, I often keep shared variables in a Data Table and let multiple workflows read from that single source of truth. That way, if I need to change one value, I update one field in the table and the workflows pick it up from there.

I also like that data tables are part of the n8n environment, not just a single workflow, so they work well for shared configuration across workflows in the same project. They do not replace true workflow inheritance, but they are a very effective way to manage common values centrally.

2 „Gefällt mir“
3

that is very interesting idea! Thanks! I’ll look into that for sure :slight_smile:

1 „Gefällt mir“
4

This is really a workflow version-drift problem. The inheritance idea would be useful, but until n8n has that kind of blueprint system I would treat shared workflow sections like versioned components.

The practical workaround I would use:

  1. Keep the shared logic in sub-workflows where possible.
  2. Tag each child workflow with the shared component version it depends on.
  3. Keep a changelog for the shared section.
  4. Roll out changes to a small canary group first.
  5. Track which child workflows were updated, skipped, failed, or need manual review.
  6. Run a smoke check after each update.

The risk is not only editing 15 workflows by hand. The bigger risk is not knowing which clients are now on which version, which ones failed after the update, and whether anyone followed up. That is the kind of maintenance trail I would want before pushing shared changes across client workflows.