another step backward

In the old framework, it wasn’t possible to “publish” to the automation builder (and have them work) blocks which had multiple fields of the same type. The primitive types didn’t exist. BUT you could create custom fields for a trigger output that matched with custom fields on your action and it would match up fine because the custom field was typed.

In the new infrastructure, custom fields that are primitives collapse to strings etc. so if you want your action to work with your trigger - it won’t map anymore. But never fear! Just create an automation template and map them yourself! Thats what we did in the old infra - make a recipe.

But lo! in the new infra when you load that template it tries to resolve them still and one or both blocks vanish from the recipe and can’t be reselected because its not compatible.

So far we’re about 1.5 steps forward and 4 steps back with the new infra. A lot of new native capabilities built in are the steps forward but for actual app features its just steps back with the only step forward so far being you can have subitem triggered automations with apps in the automation builder.

The workaround to the issue seems to be either put the fields in the sentence and make it obvious for users to configure each of them, or possibly and this is what im testing next, using an object containing them all.