Convert Approved Issues to Projects: One Scenario or Multiple?

I've built this both ways and landed firmly on the middle option, so: neither one mega-scenario nor nine.

Split by what fails together, not by what the form is called. With 9 forms and 30+ templates, one scenario per form means nine copies of the same logic — every change to how projects get named or scheduled is nine edits, and they drift. But one scenario with a router wide enough to cover 30+ templates becomes the thing nobody wants to touch, and when it breaks at 2am the error tells you "the scenario failed" rather than what failed.

What's worked for me: one scenario for the conversion path, with the form-to-template mapping pulled OUT of the router and into a data store. The lookup answers "which template for this form plus these selections," and the router is then only handling genuinely different behaviors — single-template vs multi-template requests, rush vs standard scheduling — instead of 30 branches of the same behavior. Adding template 31 becomes a row in the data store, not a scenario edit. That's the part that actually decides whether this is maintainable in two years.

Two things I'd build in from day one regardless of which you pick:

1) A fallback branch for "matched nothing." With 9 forms and 30+ templates you will hit combinations the mapping doesn't cover — I did, on day one of a similar build, because the spec I was given was missing a few field options nobody remembered. Route those to a named human for triage rather than letting them fail silently. An unassigned request disappears; a triaged one gets fixed in an afternoon.

2) Required fields on the forms for anything the mapping depends on. If the automation reads it, the form shouldn't let it be blank. Cheapest validation you'll ever write.

On maintainability specifically: the question I'd ask of any design is "when this fails, does the error name the thing that broke?" That's what pushed me away from big routers on a different build — I run one scenario per activity type there, and the failure is self-describing.

Longer write-up of the intake build this comes from, including the scheduling logic and what broke at launch: https://thousandcuts.ai/guides/creative-request-intake-automation

Happy to go deeper on the data store approach if that's the direction you take.

Hi ​@Celia_Ra My suggestion is to use one scenario with multiple paths for each request form.

I would also take the approach that ​@seanaber recommended: use a single scenario as the entry point, and leverage data stores, variables, routing logic, fallback routes, etc. to keep it clean and easy to maintain.

I definitely wouldn’t split it into nine separate scenarios. Keeping a single entry point will make the overall solution much easier to maintain.

If you do need to split out a specific part of the logic into a separate scenario, I’d still keep one scenario as the main entry point and create a secondary scenario with a custom webhook. The first scenario can then trigger the secondary scenario by sending an HTTP request to that webhook. 😊 Best of luck and happy building!