Client name changed to protect confidentiality.
The request
What they asked for
Orrinvale wanted something like Zapier or n8n that it owned outright. The core of it was simple to say: receive webhooks from the CRMs, run jobs on a schedule, and handle the steps in between. A new lead arrives, something happens. A deal changes stage, something else happens. Every morning at a set time, a job runs.
It was meant to be built in-house, so the team could shape it around its own CRM events instead of fitting the events to a vendor’s model.
The problem
What was broken
Automations are where marketing and revenue are supposed to meet. A lead arrives and should be routed. A deal closes and should update a report. When those handoffs fail, the failure is silent, and the CRM looks fine while revenue data quietly stops moving.
Renting that layer from a general-purpose tool trades control for convenience. The workflows become tied to the vendor’s limits, pricing and way of working, and the logic that runs the business sits in an account that the business does not really own. That was the thing Orrinvale wanted to stop doing.
- Critical CRM handoffs depended on a third-party workflow tool.
- Failures were hard to see until someone noticed missing data.
- Workflow logic lived outside the business’s own systems.
- Scheduled jobs and event-driven jobs were managed in different places.
What we built
The system, piece by piece
Core design
Events in, work out
The engine has two ways to start work. A webhook arrives from a CRM, or a scheduled time comes round. Either one creates a job, and the job runs a workflow: a defined sequence of steps. That is the same basic model as the tools it is compared to, and it is the right one for this problem.
Webhooks are received and acknowledged quickly, then processed as jobs. Receiving and doing are kept apart so a slow step downstream does not make the CRM think the delivery failed.
| Trigger | Example of what starts it | What it sets going |
|---|---|---|
| CRM webhook | A lead is created or a deal changes stage | A workflow reacts to that event |
| Scheduled job | A set time each day, week or month | A workflow runs without an event |
Reliability
Treating every event as something that can go wrong
Webhooks are delivered more than once, arrive out of order and sometimes do not arrive at all. A workflow engine that assumes otherwise will double-create records or miss them. The engine is built around that fact, with attention to duplicate deliveries and to failed steps being visible instead of silent.
The aim is that when something does fail, a person can see what failed, on which event, and run it again.
Workflows
More than a trigger and a single action
The engine goes beyond fire-and-forget. Workflows can chain steps, so the output of one becomes the input to the next. That is what makes it useful for CRM work, where a single event usually needs several things to happen in order: look something up, update a record, notify someone, write the result somewhere.
Ownership
Why build it instead of renting it
The reason to build was ownership. The workflow logic, the event history and the schedules belong to the business, run in its own environment and can be changed by its own people. There is no per-task meter and no vendor roadmap to wait for.
The trade-off is real. Building an engine means taking on its maintenance. That is the cost of control, and it is the reason this was a deliberate decision and not a default.
Why webhooks first
CRM events are where revenue data starts
The first job of the engine is to catch what the CRMs say is happening. Lead created, stage changed, deal won, deal lost. Those events are the earliest honest signal of whether marketing connected to revenue, and they are the events that tend to get lost when the only copy lives in someone else’s automation tool.
Scheduled jobs cover the opposite case: work that should happen whether or not any event arrived. Daily checks, regular syncs and periodic clean-ups are the examples. Having both in one engine means that event-driven and time-driven work are visible in the same place.
Trade-offs
Decisions that shaped it
An automation engine is a product that can grow without end. Most of the decisions were about where to stop.
Build for our events, not every event
The engine is shaped around CRM webhooks and scheduled work. A generic connector for every app would be a larger product with less value.
Acknowledge fast, process after
Receiving a webhook and acting on it are separate. A slow step should not make a CRM think the delivery failed.
Visible over clever
A workflow that can be read and rerun beats one that is clever and opaque. The people who own it have to be able to see it.
Own the maintenance
Owning the engine means owning its upkeep. The business accepted that trade for control over its own revenue plumbing.
Operations
How it runs day to day
Day to day, nothing looks like work. A webhook arrives, a workflow runs, and the result is in the system it was meant for. Scheduled jobs run at their set times. The part that needs attention is the failures, which are surfaced for a person instead of being swallowed.
Adding automation means defining a new workflow against an existing trigger, not wiring up another subscription. That is the practical difference from renting.
Measurement
What the system measures
These are what the engine records. They are definitions, not results.
- Webhook events received
- Scheduled jobs run
- Workflow runs and the steps within them
- Failed steps and retries
Scope boundaries
What we chose not to build
- A public connector marketplace
- The engine serves one business’s CRM events. Hundreds of generic connectors would be maintenance for no gain.
- A drag-and-drop product for outsiders
- It is an internal tool built for the team that owns it.
- Silent failure
- A failed step is recorded and visible. Quiet failure is how revenue data goes missing.
Outcome figures
Outcome figures are held back for confidentiality and will be added when the client approves publication.