Designing a Scalable Automation System

Internal users with Template editing permission created Automation. The original builder used a natural-language structure: When … Then … Do …. It was easy to read while actions were simple and predefined.

Product plans and customer requests introduced new integrations. Each addition required a new sentence pattern, design support, and special-case implementation. The format was readable, but the system behind it was not structured for expansion.

The scope became too large for one delivery, so the team split it into two tasks. The first rebuilt Automation configuration. The second introduced Data Reference so later actions could reuse information created earlier in a workflow.

Product plans and customer requests defined the need to support more integrations. I brought the two tasks through internal review with the PM and Engineering team to align the configuration rules, conditional Account behavior, integration-specific Inputs, Data Reference, and failure states.

This alignment established the baseline for the redesign. It did not test usability with customers or measure post-launch performance.

I first tried to preserve the sentence model and place new configuration inside When / Then / Do. Once app-specific fields and Account were added, the sentence kept branching and still required custom design for every capability, so I moved away from that direction.

I reframed configuration as three parts: App & Event → Account → Inputs.

App & Event defines what should run. The selected Automation App determines whether Account appears. Inputs holds the information needed to execute the event.

The goal was not to make every configuration identical. It was to define stable rules so Engineering could add future Automation types without requiring a new design for each one.

After the new Automation structure was defined, the second task addressed workflow data. Later actions increasingly depended on outputs from earlier actions: titles, dates, attachments, submitted files, and signed documents.

Data Reference lets an Input point to an existing output instead of asking users to recreate it. Text inputs can reference compatible text values; file inputs can reference attachments or generated documents.

This changed Automation from isolated rules into a way to pass information through a workflow.

Moxo-native Automation could use defined Input fields. Integration Automation needed a different Input presentation because the content returned by each integration could not be known in advance. Both followed the same high-level configuration rules without pretending their Inputs were identical.

External accounts and workflow data also introduced more ways to fail. I designed the end-to-end error experience and organized it around when the problem happens: before execution, during execution, or after an Automation fails to complete.

The message should answer three questions: what went wrong, where it happened, and what the user needs to fix.

The redesign replaced sentence-specific patterns with a structured configuration model. Once the rules were defined, Engineering could add supported Automation types without returning to Design for a new pattern each time.

The new Automation structure shipped first. Data Reference, text and file references, integration-specific Inputs, Moxo-native events, third-party integrations, and Error handling followed.

The project record does not include adoption, completion, error-rate, or time-on-task data, so the effect after launch remains unproven.