Inside Deelo's Automation Engine: Build Workflows Without Code

Every business has the same handful of workflows that should be automated but aren't.

New lead arrives → someone manually adds them to the email drip. Invoice gets paid → someone manually marks the project as billable-complete. Ticket gets closed → someone manually tags it for the satisfaction survey. Customer hits a milestone → someone manually sends the upgrade prompt. None of these need a human. All of them happen because nobody set up the automation yet, and setting it up means learning a third-party automation platform, mapping fields between tools, and praying it does not break.

The Deelo Automation app is the no-code workflow engine that lives inside the platform. It is not a sidecar service. It is a first-class app that has native read and write access to the rest of the platform, runs unlimited automations on every plan, and shows you the full execution log when something goes wrong. This post is the product walkthrough: the building blocks, the patterns, and three concrete workflows you can ship today.

Every automation in Deelo is built out of the same five primitives. Once you can see them clearly, every workflow becomes a question of which pieces you snap together.

A trigger is the event that fires the workflow. Deelo supports five trigger types.

- Manual: someone clicks a button. Useful for ad-hoc workflows that the operator decides when to fire. - Schedule: a cron-style time trigger. Run this every Monday at 9 am. Run this every 15 minutes. Run this on the first of each month. - Webhook: an inbound HTTP request from outside the platform. Useful for integrating with tools that are not (yet) inside Deelo. - App event: something happened in one of the 50+ apps. A new CRM contact was created. An invoice was paid. A helpdesk ticket was closed. A booking was confirmed. - Drip: an enrollment-style trigger for sequence workflows. Adds a contact to a multi-step campaign and walks them through the steps.

App events are the most common starting point for business workflows. Because every Deelo app emits structured events, you can build automations on hundreds of different starting conditions without writing integration code. 'When a CRM deal moves to Won' is one click in the trigger builder, not a Zapier zap mapping fields by hand.

Conditions decide what happens next based on data. You almost never want a workflow to run identically for every input. A new lead from a partner referral should be routed differently from a new lead from a paid ad. A $20 invoice payment should not trigger the same internal celebration as a $20,000 one.

Deelo's condition nodes support standard comparison operators (equals, not_equals, contains, greater_than, less_than, is_empty, in, matches_regex, and more). Conditions can be chained with AND/OR logic, and they branch the workflow into separate paths. If value > $10,000, run the high-value-deal path. Otherwise, run the standard path.

The practical use: instead of building 'one workflow per scenario,' you build one workflow with branches. New lead created → branch on lead source → partner path or paid path or organic path. One workflow to maintain, not three.

Actions are the work the workflow performs. The actions available cover roughly every app in the platform: create a contact in CRM, send an email through Mail, send an SMS through Voice, create an invoice in Invoicing, update a record's status, file an expense, add a row to a sheet, create a project in Projects, post a message in Messenger, generate a document in Docs, send a survey through Survey, the list goes on.

There are also generic actions for cases where you are reaching outside the platform: send an HTTP request to an external API, run an AI prompt with a chosen model, send a Slack or Discord message, write to Google Sheets, push to Airtable.

A workflow can chain as many actions as you need. New lead → enrich with AI (an ai_prompt action) → create a CRM contact → add to marketing drip → notify Slack → schedule a follow-up task. Five actions, one workflow, zero manual steps.

Most automations need to pass data forward. The new lead's email becomes the recipient of the welcome email. The invoice number becomes the subject of the Slack notification. The customer's name fills the SOW template.

Deelo's automation engine handles this with structured data references. Each node in the workflow has typed outputs that downstream nodes can reference using a path expression. The trigger event's lead object is available as {{trigger.lead.email}}. The output of an earlier action is available by node name and path. The condition's evaluation can be referenced. The references are validated at design time, so a workflow with a broken reference shows a red mark in the editor before you publish it — not a silent failure at runtime.

The practical implication: you spend less time on field mapping than you would on a third-party integration platform, because the data model is shared. The CRM contact's fields are the same fields the Marketing app sees, the same fields Invoicing sees, the same fields Helpdesk sees. There is no 'this tool calls it firstName, the other tool calls it first_name' translation layer.

Lookups solve the problem of needing data that is not in the triggering event. The trigger event for 'invoice paid' includes the invoice details and the customer ID. But maybe your workflow needs the customer's account manager (which is on the CRM contact, not the invoice). A lookup node fetches the contact record by ID and makes its fields available to downstream nodes.

Lookups in Deelo's automation are first-class actions, one per app. You can lookup a CRM contact by email or ID, lookup an active project by customer, lookup the latest helpdesk ticket for a customer, lookup the latest order. The lookups return structured records that downstream nodes reference the same way as any other node output.

The net effect is that you can build workflows that span data from multiple apps without joining tables yourself. The platform's shared data model is what makes this possible — there is no impedance mismatch between apps because they are all writing to the same store.

Every node has retry configuration and error handling. The defaults are sensible: most actions retry three times with exponential backoff before failing. If a downstream API is briefly unavailable, the workflow does not die — it waits a second, retries, waits two seconds, retries, waits four seconds, retries, then surfaces the error if it still fails.

When a workflow does fail, the execution log shows every node's input, output, status, and error message. You can see exactly which step broke, what the data looked like at that point, and what the error was. This sounds like table stakes, and it should be, but anyone who has debugged a multi-step Zap with no visibility into the intermediate state knows it is not table stakes. The execution log is the difference between fixing an automation in 10 minutes and giving up on automations because you cannot tell why they fail.

Workflows can also have explicit error-handling branches. If the 'send email' node fails, route to a 'log the failure and notify ops' branch instead of dying silently. The pattern is the same as success-path branches, but for the failure case.

Standalone integration platforms (Zapier, Make, n8n, Workato) are great for connecting tools that do not share a data model. They translate between systems that genuinely do not know about each other. That translation is the value, and that translation is the cost — you set up field mappings, you manage authentication, you pay per task.

The Deelo automation engine lives inside the platform. When the trigger is 'new CRM contact,' the automation knows what a CRM contact is — schema, fields, types — because the CRM contact is a native object in the same store the automation engine reads from. There is no field-mapping setup, because there is no field translation. The contact object passed to the workflow is the same contact object the CRM uses, the same object the AI Assistant queries, the same object the Marketing app sends to.

The pricing model is also different. Standalone integration platforms charge per task — each step in each automation in each month counts against your plan. A business that runs 50,000 task executions a month pays for that volume. The Deelo automation engine does not meter task executions. Automations run as much as you need them to on whatever plan you are on. The business value of automation grows with usage; pricing should not punish that.

This is not to say you never need a standalone integration platform. If you have a system that lives outside Deelo and there is no Deelo app for it, you may still need Zapier or Make for that one connection. The webhook trigger is built for exactly this: an inbound HTTP request from an external system, handled inside Deelo without leaving the platform.

The most common workflow operators want and never quite get around to building. Here is the structure.

Trigger: new CRM contact created where lead_source equals 'website_form'. Action 1: AI prompt — enrich the lead with company information from the email domain. Action 2: Update CRM contact with the enriched company size and industry. Condition: company_size greater than 50. - True branch (mid-market): Assign to senior sales rep. Notify in Messenger. Schedule a 30-day pipeline review task. - False branch (small business): Enroll in the self-serve marketing drip. Send welcome email. Schedule a 14-day follow-up task. Merge branches. Action 3: Add lead to weekly sales review report.

One workflow, two paths, four to seven actions per path. No human in the loop until the salesperson takes the qualified meeting. The lead goes from 'someone filled out a form' to 'in the right sequence with the right owner and the right tasks' in seconds.

When an invoice gets paid, six things should usually happen. Most businesses do one or two and forget the rest.

Trigger: invoice marked paid in Invoicing. Lookup: pull the related project from Projects by customer and active status. Lookup: pull the customer's contact record from CRM. Action 1: Update the project's billing status to 'billed and collected.' Action 2: If this was the final invoice for the project, transition the project to 'completed.' Action 3: Send a thank-you email to the customer using the Mail app. Action 4: After a 14-day delay, send a review-request email through Marketing. Action 5: Update the customer's lifetime value on the CRM record. Action 6: Post in the team's Messenger channel announcing the closed engagement.

This workflow eliminates a class of follow-through gaps that quietly cost businesses money — the review never gets asked for, the case study never gets built, the customer's LTV never gets updated, the team never celebrates the win. None of it is hard to do manually. All of it stops happening when the team gets busy.

Support teams want to honor SLAs and almost never have a clean way to enforce them.

Trigger: schedule, runs every 15 minutes. Action 1: Query Helpdesk for open tickets where created_at is more than 4 hours ago and assigned_to is empty. Loop: for each ticket in the result. - Lookup: get the team's on-call rotation from a Sheet or a setting. - Action: assign the ticket to the current on-call rep. - Action: send a Voice SMS to the rep. - Action: log the assignment in the ticket's audit trail. Condition: if there are tickets where created_at is more than 8 hours ago and resolved_at is empty. - Action: notify the support manager in Messenger. - Action: tag the ticket as 'SLA-breached' for the weekly review.

The support team gets unstuck without anyone manually checking the queue. The manager only hears about exceptions, not noise. The SLA is enforced by the system, not by hope.

Automation does not replace the people who run a business. It removes the connective tissue work that fills the cracks between roles. The best operators I know have a long list of workflows running quietly in the background, and they almost never think about them — which is the point. The work happens, the team gets to spend its time on judgment and customer relationships, and the dropped balls that used to be normal become exceptions worth investigating.