Inside Deelo's Automation Engine: Build Cross-App Workflows Without Code

Most small businesses run on a thin layer of duct tape called Zapier. A new lead in your CRM fires a webhook. Zapier polls your CRM API every fifteen minutes. Eventually it notices the change, calls your email tool's API, then your calendar's API, then your Slack's API. Every step is an external HTTP call to a separate vendor's database. Every step costs you a task. Every step can fail silently because the source app and the destination app do not actually know each other exists.

Deelo's automation engine works differently. Your CRM, your invoicing, your field service work orders, your patient charts, your calendar, your email -- they all live in the same database. When something happens in one app, every other app knows in under a second because the trigger is a database event, not a polled API call. The engine that runs your workflows runs on the same server as the apps it is automating.

This post is the architecture tour. We will cover what the automation engine actually is, five real workflows we have seen customers build, how the data-locality model differs from API-glue tools like Zapier, the building blocks of a workflow, what makes multi-step automations reliable in production, and where the engine is heading in Q3 2026. By the end you will know exactly what no-code business automation looks like when it is native to your operating system instead of bolted on top.

The Deelo Automation Engine is a workflow runtime built into the Deelo platform. It listens for events from any of the 53 user apps -- CRM, Invoicing, Helpdesk, Bookings, HR, Inventory, Field Service, Projects, POS, E-commerce, Marketing, Accounting, Expenses, Time Tracker, Practice, Scheduler, and the rest -- and runs multi-step workflows in response.

A workflow is a directed graph of nodes. Every workflow starts with a trigger node (an event from an app, a schedule, a webhook, or a manual run), passes through optional conditions and branching logic, and ends in one or more action nodes that do something inside another app or external system.

Under the hood, the engine has four pieces working together:

- Job Queue -- a MongoDB-backed queue (`deelo_jobs`) with atomic claim semantics, so two workers never run the same step twice. Failed steps retry with exponential backoff. Completed jobs are TTL-cleaned automatically. - Scheduler -- supports cron expressions, fixed intervals, and one-off scheduled runs. The scheduler tick endpoint is protected by a `CRON_SECRET` so only your infrastructure can fire it. - Workflow Engine -- traverses the workflow graph, calls the right node executor for each step, enforces per-node timeouts, and retries individual nodes on transient failure without restarting the whole workflow. - Event Bridge + Webhook Handler -- a wildcard subscriber to the internal EventBus (108+ route files emit through it, with 109+ event types defined) plus an HTTP webhook handler for external systems. Both feed into the same workflow matcher.

Workflows, runs, templates, drip enrollments, and metrics live in a separate database (`deelo_automation`), so heavy automation traffic never slows down your business apps. The engine is on. It is just waiting for a trigger.

The fastest way to understand a workflow engine is to look at what people build with it. These five are representative of the patterns we see most often. Every one of them runs cross-app, end-to-end, inside Deelo.

Trigger: a new contact is created in the CRM with status `lead`.

Workflow:

1. Condition node checks the contact's territory field. 2. CRM action node looks up the closest sales rep for that territory using a `find_users` lookup action. 3. CRM action node assigns the lead to that rep (`update_contact` with `ownerId` from step 2). 4. Send email node fires a templated welcome email to the lead, personalized with `{{trigger.data.firstName}}` and `{{nodes.assign.repName}}`. 5. Bookings action node creates a 30-minute calendar invite on the rep's calendar with a Zoom link. 6. Send notification node pings the rep in their Deelo notification tray with a deep link to the new lead.

From lead created to fully assigned and welcomed: under three seconds. Zero manual work.

Trigger: scheduled cron (`0 9 * * *`, 9am daily) plus an Invoicing app filter for `status = overdue` and `daysOverdue = 7`.

Workflow:

1. Loop node iterates over each matching invoice. 2. Send email node sends a polite reminder with a one-click pay link. 3. CRM action node creates a follow-up task assigned to the account owner. 4. Practice action node (for healthcare customers) flags the patient account in the chart so the front desk sees it at the next visit. 5. Condition node: if the customer has a phone number on file, Send SMS node sends a text reminder too. 6. HTTP request node posts to a Slack channel for the finance team summarizing the day's overdue accounts.

This is dunning that used to require a paid third-party tool. Now it is six nodes and runs every morning automatically.

Trigger: Field Service event `workorder.assigned`.

Workflow:

1. Field Service lookup node fetches the technician's details using `get_user`. 2. Send SMS node texts the tech: "New job at {{trigger.data.address}} -- ETA window {{trigger.data.window}}. Open in Deelo: {deep-link}." 3. Bookings action node adds the job to the tech's daily route in the Scheduler app. 4. Inventory action node reserves any required parts via `update_inventory_item`. 5. Send notification node pings dispatch confirming the assignment.

No more "did you see that work order?" phone calls. The assignment, the SMS, the route, and the parts hold are all one trigger.

Trigger: webhook from a lab system, or internal event `practice.lab_result.received`.

Workflow:

1. Condition node checks if the result is flagged abnormal. 2. Send notification node alerts the ordering physician (HIPAA-compliant in-app notification, no PHI in email). 3. AI prompt node drafts a follow-up message to the patient using the assistant, with the result context attached. 4. Bookings action node creates a tentative follow-up appointment slot for the next available physician. 5. Practice action node appends a note to the patient's chart with the lab result and the workflow's run ID for audit.

Because Practice uses Deelo's `EncryptedRepository`, every step that touches PHI is automatically encrypted at rest and audited.

Trigger: scheduled cron, runs daily, filters CRM contacts where `renewalDate` is exactly 30 days out.

Workflow:

1. Loop over matching contacts. 2. Send email node sends a personalized renewal email with the customer's account snapshot. 3. CRM action node creates a new opportunity tied to the contact, valued at the existing contract amount, in stage `renewal`. 4. Send notification node alerts the account manager with a deep link to the new opportunity. 5. Marketing action node enrolls the contact in a 4-touch nurture drip (handled by the Drip Campaign Engine, which is itself a thin layer on top of the workflow engine).

Renewals stop being a thing your account managers forget. They become a thing the platform reminds you about while pre-staging the work.

Zapier is great. It does its job well. We are not knocking it. But Zapier and the Deelo Automation Engine are solving different problems.

Zapier is API glue. It connects external apps to each other through their public APIs. Each app is a separate vendor with a separate database. Zapier acts as the postal service that carries data between them.

Deelo is a native automation engine. It runs on the same database as the apps it is automating. There is no postal service because there is no border to cross.

This difference shows up in four practical ways.

If your stack is genuinely heterogeneous -- Salesforce on one side, Stripe on another, ZenDesk somewhere else -- a tool like Zapier is the right answer. If most of your operations already live in Deelo, paying a per-task fee to ship data between apps that share a database is paying twice for the same wire.

Every workflow is built from a small set of node types. They compose into anything from a two-step welcome email to a fifty-step procurement process.

Two pieces tie the nodes together. Template expressions (`{{trigger.data.x}}`, `{{nodes.id.field}}`) let any node reference data from any upstream node, resolved at runtime by the engine. Dynamic action fields mean that when you pick an action like `crm:create_contact`, the configuration form swaps in the right fields automatically -- you do not have to remember the schema.

Open the Automation app from your Deelo desktop. Click "New workflow." Pick a name -- "Welcome new leads" works.

Add a Trigger node. Choose app `CRM`, event `contact.created`. Add a filter: `status equals lead`.

Add a Send email node. Pick a template, or write inline. In the body, type `Hi {{trigger.data.firstName}},` and the engine will substitute the lead's real first name when the workflow runs. Set the recipient to `{{trigger.data.email}}`.

Add a CRM action node. Action: `create_task`. Title: "Follow up with {{trigger.data.firstName}}". Due: 1 day. Owner: the lead's assigned rep.

Click "Activate." That is it. The next contact created in your CRM with status `lead` will fire all three nodes in sequence. You can watch the run live in the run history. Total setup time: under a minute if you know what you want, under five if you are exploring.

Most teams do not start from zero. Deelo ships a template library covering the workflows that almost every business needs:

Pick a template, swap in your specifics, activate. The templates are starting points, not black boxes -- every node is editable, and every workflow can branch off into your own logic.

Anyone can write a workflow that runs once when nothing is wrong. The hard part is running tens of thousands of workflows a day across thousands of teams without losing data, double-charging customers, or sending the same email twice. That reliability comes from how the engine handles failure.

The current engine is the foundation. Three things land on top of it next.

All three sit on the same engine described above. The job queue, the scheduler, the graph traversal, the retry semantics, the audit trail -- nothing changes underneath. The new pieces just plug in as new node types and new trigger sources.