[Zurich] Config-driven master flow for 100+ catalog items

[subhikshaP01367]

 [Zurich] Consolidating 100+ per-item catalog flows into one config-driven master flow — how do you handle the variation?

Hi all,

On Zurich, Flow Designer only. Looking for guidance from anyone who has done this in a real environment.

**Current state**

~100 active catalog items, each with its own flow. Any change to a common behaviour — approvals, SLAs, notifications, task creation — means touching every flow individually. It is not sustainable.

**Target design**

* One master flow
* One custom config table — multiple rows per catalog item, sequenced by a Step Order field, each row typed by a Pattern value
* A small library of subflows for the per-pattern logic
* Onboarding a new item should mean adding config rows, not building a flow

A POC is running in DEV and works correctly for the structurally simple items.

**Where we are stuck**

The items are not variations of one flow with different data in them. They differ in *how values are arrived at*, and the variation is wide. Assignment group is the clearest example — across our items it is hardcoded on some, taken from a variable the requester selects on others, derived from the requester's location on others, and computed in script on others. The same kind of spread exists for approvers, task descriptions, due dates, task counts, and the conditions under which steps run at all.

So a config column that holds a *value* only covers a fraction of the items. Once we start adding columns and branches to cover the rest, the master flow grows toward the same complexity as the 100 flows it was meant to replace — only now concentrated in one artifact that is harder to debug.

That is the wall we have hit, and we do not want to spend three months discovering the answer the hard way.

**What I am asking**

1. **Is this pattern sound at this scale, or is it a known trap?** If you have run a single config-driven master flow across 100+ items in production, what did it look like a year later? If you abandoned it, why?

2. **How do you model "how a value is derived" in config?** Is there an accepted approach — storing a resolution strategy plus a parameter and resolving through a single Script Include, or something native we should be using instead? We are aware of Data Lookup Definitions and Assignment Rules but neither seems to cover the full spread. If Zurich has introduced anything that changes this answer, we would like to know before we build.

3. **Where is the line between config and code?** At what point does variation stop being config data and legitimately deserve its own flow? Is a hybrid model — most items through the master, a genuine minority left on their own — accepted practice or a sign the design is wrong?

4. **How do you profile the existing estate to find the real patterns?** Our assumption is that 100 "unique" flows collapse into a small number of true patterns and the rest is data. We would like to prove or disprove that before committing. Is there an established way to analyse existing flows for this, or is it a manual review?

5. **Debuggability and governance.** With one flow handling everything, how do you keep execution traces usable, and how do you stop the config table from quietly becoming an undocumented second flow engine?

Happy to share the config schema and the pattern breakdown back to the community once we land it.

Thanks in advance.