Skip to content
Experience

Juristic · Engineering case study

Expanding a workflow engine

New reusable capabilities for a configurable B2B automation engine.

My role
Designed and implemented new engine capabilities across frontend, services and shared types
Team
Full-stack Developer in a seven-developer product team
Technologies
TypeScript · React · AdonisJS · Node.js · SQL

Automation engine · what I added

Trigger

Something changes in a workflow

Conditions

Configured by the customer

Actions

Existing actions, unchanged

Create a task in a chosen context

Email with file attachments

Move a task with its subtasks

Run history

What ran, and why

Highlighted parts are the capabilities I added. Existing automations keep behaving exactly as before.

01The problem

What was wrong, and why it mattered.

Customers configure automations to run their own workflows, and asked for more than the engine could do: creating tasks in a specific context, sending files with notifications, and moving work between groups without breaking task hierarchies. When something ran, it was also hard to see what happened and why.

My responsibility

I extended the engine with reusable actions and corrected hierarchy handling, while keeping every existing automation behaving exactly as before.

02Constraints

What the solution had to respect.

  • Existing automations behave exactly as before
  • Permissions preserved for every new action
  • Parent and child tasks keep structure and order across moves
  • Changes span frontend, services and shared types

03Technical approach

What I built.

  1. 01Added an action that creates tasks in a specified workflow context
  2. 02Supported file attachments in automated email notifications
  3. 03Corrected cross-group moves so subtasks keep their structure and order
  4. 04Made automation runs visible so users can see what ran and why

04Decisions and trade-offs

The calls that shaped it.

  1. 01

    Capabilities, not one-offs

    Each customer request becomes a reusable action any automation can use.

    The trade-off

    More design up front than a targeted patch, and a broader engine afterwards.

  2. 02

    Hierarchies move as a unit

    A parent’s subtasks move with it and keep their order.

    The trade-off

    Careful ordering and edge-case handling instead of marking subtasks done as a shortcut.

  3. 03

    Explain every run

    Execution history shows what ran and why.

    The trade-off

    Extra data and interface, and far easier debugging for users and the team.

05Systems touched

Across the stack.

  • Automation engine
  • Configuration interface
  • API gateway services
  • Shared TypeScript types
  • Email notifications
  • Task hierarchy

06Outcome

The result.

Automations can now create tasks in a chosen context, attach files to notification emails and move tasks between groups with their subtasks intact, and run history shows what ran and why. Existing automations behave exactly as before.

Described at a public level of detail. No customer names, internal identifiers or proprietary code.