I notice you've used two different programming languages to express application logic. A the high-level, you have automations, which are simple but look very limited in terms of capabilities (i haven't studied this part in great detail, but does its support things like looping, arbitrary conditional expressions, and an abstraction mechanism like user-defined functions?). At the low level, you have JavaScript to do fine-grained data manipulation, which is often necessary to take care of details like computing summaries of data or transforming between different formats.

I've seen this approach used in a lot of different workflow systems over the years, and it's always struck be as awkward. Have you considered designing the automation language in such a way that it is sufficiently expressive to cover the full range of needs for apps, from the high-level aspects to the low-level details?

The approach I prefer to use is to pick a suitably generic language (generally based on a formal process calculus and extended with useful primitives). I'm on my second round of doing this now (first as an academic research project, now in industry) and in both cases it's been based on lambda calculus (and in the industry project, based on Scheme). The language constructs and model of computation are identical whether you're implementing high-level aspects of the workflow logic (a sequence of steps, with optional conditional branches, looping etc) and low-level aspects (iterating through a list of numbers to compute the sum). One language + interpreter takes care of both. I discuss this approach in Chapters 2 and 3 of https://www.pmkelly.net/publications/thesis.pdf.