← Selected work

Product and platform

Automation that could branch

I led the replacement of a one-step rules engine with a production node canvas supporting branching, iteration, API execution, and readable run histories.

Ruby on RailsReact FlowITSM
Role
Technical delivery lead for an approximately 8-engineer team
Constraint
One trigger and one sub-trigger; no chaining, branching, or useful failure path
Decision
Composable nodes, schema-aware outputs, and run history that follows each branch
Result
Running in productionStill the program I lead; the node model is documented in EZO’s public Automation Engine docs.

Sanitized artifact

One condition can fork into two observable paths.

A member offboarding trigger reaches an inactive-status condition, which branches to an Entra user update and to opening a ticket. TRIGGERmember.offboardedCONDITIONstatus = inactiveCONNECTOREntra: update userACTIONopen ticket

Reconstructed from EZO’s public Automation Engine documentation. Labels are illustrative; no customer data is shown.

Ownership and reflection

My part

I split the engine into workstreams, set the integration boundaries, reviewed the cross-cutting decisions, and kept backend and frontend delivery aligned. I also built the HTTP request node, webhook triggers, and success and failure branching myself, and improved the execution logs.

The team's part

Approximately eight engineers owned execution, expressions, event and time triggers, iteration, transformation, integrations, monitoring, and the node-canvas interface.

Hardest trade-off

More flexible workflows are harder to explain when they fail. Schema-aware outputs and readable run histories had to grow with the node model.

What I'd do earlier

We let the node catalogue grow before replay rules and operational limits were boring and explicit. I would reverse that order.

01 · Constraint

What was breaking

The old engine paired one trigger with one sub-trigger. It could not chain actions, branch on outcomes, or explain which step had failed when a rule behaved incorrectly.

02 · Decisions

How I approached it

I split delivery across execution, expression resolution, event triggers, branching and iteration, data transformation, integrations, and monitoring. Responses become schemas later nodes can read; arrays split into items and paginated endpoints follow themselves.

03 · Consequence

What changed

The engine is running in production and remains the program I lead. It can carry an offboarding flow across several systems and show where a branch failed.