From Email Automation to a Workflow Automation Framework in Nucleus

Looking back, I don't think I realised I was building an automation framework. At the time I was trying to solve another customer request and, like a lot of the work that turns out to matter, it didn't begin with a strategy or a roadmap. It began with a conversation.

In the summer of 2024, BAFTA's Operations team came to me with what looked like a straightforward requirement. They were building a complex workflow in Nucleus and needed different emails sent to different people depending on how an entrant completed their form. A single confirmation email wasn't enough. The content, recipient and timing all depended on the answers given at submission.

On paper, it was another feature request. It ended up changing how workflow automation works across the entire platform.

How Nucleus got here

Nucleus has always been built around flexibility. Unlike a lot of SaaS products that expect an organisation to adapt to the software, Nucleus adapts to the organisation. Different awards have different workflows, approval processes, judging methods and administrative needs, and supporting those differences without spinning up separate systems has always been one of the platform's strengths.

Over the years, this produced a growing collection of automations. Entries could progress through workflows automatically, categories could be assigned based on form answers, entries could be copied after submission, applications could move into approval queues and notifications could fire when specific events occurred. Every one of those features solved a genuine customer problem and each worked well in isolation.

The issue wasn't that they existed, it was how they had evolved. Each automation had been designed independently, often years apart, in response to a specific request. They lived in different parts of the admin interface, were configured in different ways and couldn't easily work together.

If an admin wanted to create a complex workflow, they had to understand several unrelated parts of the platform. If a customer asked for something new, the conversation usually started with building another feature.

There was nothing wrong with that. It is how a lot of successful products grow, particularly a highly customised platform such as Nucleus, where we are regularly responding to complicated client workflows. But eventually I kept coming back to the same question: were we solving workflow problems, or just adding more workflow features?

The first step, and the question it raised

Working with our lead developer, Muhammad Qasim, we built a configurable email automation that allowed admins to decide which status transitions triggered an email and define the criteria controlling when it was sent. Unlike earlier functionality, it wasn't tied to one award or workflow. Admins could configure it themselves, and it became the first feature within a dedicated Automations section in Nucleus. In discussions with our CTO, we agreed that once the admin redesign was complete, the various automation settings should be consolidated properly into this area.

The email automation solved the Operations team's problem and quickly proved useful elsewhere. Normally, that is probably where the development would have ended. Instead, it raised a more interesting question. If admins could configure when an email was sent, why couldn't they configure everything else in the same way?

Looking for the pattern

Rather than designing another automation, I stepped back and reviewed every automated workflow we had built over the years. I wasn't really interested in what each one did. I wanted to know what they all had in common.

The pattern came quickly. Every automation, whatever its purpose, was made up of the same three parts. Something happened that started it, the platform checked whether certain conditions were met and something happened as a result.

A trigger, a set of criteria and an action.

That was true whether we were copying entries, progressing submissions, assigning categories or sending emails. The only things that changed were the trigger and the action. That reframed the whole problem. We didn't need another automation, we had never built a reusable framework.

The inspiration was close to hand. Through 2024, I had spent a lot of time redesigning how we used Jira Service Management for the support team. Jira's automation model separates the trigger from the action, allowing different components to be combined without designing a fixed workflow for each scenario. I wanted the same flexibility for Nucleus.

The Automations section itself had originally been more our CTO's idea, which I had run with. His initial thinking around how the rules would work leaned towards more structured, predefined workflows.

My contribution was the three-part abstraction and the argument behind it. If the trigger and action were completely decoupled, we would no longer have to predict which combinations admins might want. An entry submission could send an email, copy an entry or populate an answer. A date being reached could change a status or delete an entry. A status transition could trigger an external webhook.

I plotted the model out and worked through the approach with him until we were aligned. That mattered because a framework like this only works if everyone involved agrees to stop thinking in terms of fixed workflows.

The bet, and why it was smaller than it looked

Committing to a framework meant slower delivery upfront. Instead of shipping the next requested automation, we would spend time building something that made every future automation easier.

On a largely client-funded platform, that isn't always an easy argument to make. Customers are normally funding a requirement they need now, rather than an abstract framework that might also benefit somebody else later.

What made the decision manageable was that the existing automations could continue working while we developed the framework. We put several new requests on hold and I made the case to stakeholders that although they would wait longer, the finished framework would support more complex workflows and be much quicker to expand. The risk was therefore mostly about time rather than disrupting functionality people already relied on.

The economics were probably the clearest part of the argument. A bespoke workflow could consume a significant amount of development resource while benefiting a small number of users on one award. A framework benefits every client, and once it exists, adding a new trigger or action takes around half a day to a day rather than becoming a separate project.

We kept the initial release deliberately small and prioritised it around where requests were actually coming from. More requirements arrived while it was being developed, which expanded the first version and pushed the launch back. I was comfortable with that because it meant we launched with something more useful without affecting the existing workflows.

Where the framework paid for itself

There was also a specific opportunity that helped fund part of the work. The European Film Academy had previously asked for a video integration but decided not to proceed because of the cost. At around the same time, I had been experimenting extensively with Make while building VisaScope AI, and started wondering whether I could deliver the integration much more cheaply through a no-code workflow.

The answer was yes, but the workflow needed a trigger from Nucleus to start it. I convinced the Director of BAFTA Tech to fund the webhook development so that I could take the integration back to the client. They liked the revised approach and decided to proceed.

As well as helping fund the webhook development, it delivered an integration the client had already turned down on cost. It also opened a potential new revenue stream, by allowing us to build no-code integrations around Nucleus without developing every part of an external workflow inside the core product. I will write about that integration separately because it became a project in its own right.

One framework, several very different workflows

The framework launched in February 2026. Watching different organisations use the same components in completely different ways has probably been the most useful measure of whether the abstraction was right.

The BAFTA Programmes team uses it to randomly distribute entries between judges, replacing a manual process while keeping the allocation fair and consistent. The European Film Academy uses a status change to email viewers automatically when new films become available.

The BAFTA Film team has changed the structure of its entry process. Previously, separate forms were needed for short film, short animation and other areas because entrants had to choose the right award before beginning. Entrants can now complete a single gateway form, with automation progressing the entry into the appropriate award based on the category or information they provided. This means fewer forms for admins to configure, less duplication and a simpler starting point for entrants.

The BAFTA Awards team uses a chain of three rules to manage subtitle compliance. If a video is submitted without subtitles, the first rule sets a reminder date. If a placeholder is replaced by a video later and subtitles are still missing, another rule sets the date at that point. When the reminder date is reached, the final rule checks again and emails the entrant if subtitles have still not been provided.

Previously, this would have involved spreadsheets, manual tracking and repeated follow-ups. The admins can now configure the whole process inside Nucleus.

The BFI has also requested date-based deletion, where applications will be deleted automatically based on dates entered on a form. That has been scoped for a future release, and that is really the point. It is now a small addition to the framework rather than another bespoke workflow. Every trigger or action we add gives every client another way to combine the existing components without us having to redesign the system.

A different way of approaching the backlog

The most valuable part of this project wasn't a feature. It was recognising the point at which individual features had stopped being the right answer.

For years, we had delivered exactly what customers asked for, and there was nothing wrong with that. But the requests had started to rhyme. Different organisations wanted different outcomes from the same underlying thing: a platform that responds intelligently when something happens.

It has changed how I approach the backlog. A new automation request now starts with a different question: can it be configured using what already exists? Often it can. When it can't, adding another trigger, criterion or action is usually a day's work rather than a project.

Spotting that pattern is the part of product management I find most valuable, because it means the next customer request does not necessarily become another isolated feature. Instead, it can expand a capability that becomes useful across the entire platform.