Visual workflows that start from events in your app

Drag triggers, conditions, branches, and approval steps onto a canvas to set what your Builder app does after each event. Each workflow executes on a durable engine that retries failed steps and logs every run in an audit trail.

Get early accessView all products

The backend logic behind your apps

Your app has to respond when a user submits a form, places an order, or approves a request, as well as when a scheduled date comes due. Builder Workflows lets you build that backend on a visual canvas, where you drag triggers, conditions, branches, loops, and human approval steps into place and connect them. The pipeline engine behind each workflow saves the progress of every step, retries a step that fails, and records each run in an audit trail. The people who set your business rules can build each workflow on the canvas and change it whenever a rule changes.

Give your app backend logic that your operations team owns

A workflow defines what your app does when a user submits a form, places an order, or answers an approval request. The steps below show how to build one on the canvas, from its trigger to the audit trail of each run.

What you can build on the workflow canvas

Visual canvas for complex logic illustration

Visual canvas for complex logic

If your workflow tool allows one trigger per automation or only simple if/else branches, you will have to call engineering as soon as your logic needs nested conditions, parallel branches, or a loop over a list of items.

Builder Workflows supports triggers, conditions with nested logic, parallel branches that execute at the same time, loops over collections, delay timers, and merge points, where the workflow continues once every branch finishes. You arrange blocks on a canvas, connect them, and set up each block through a form.

Human approval gates illustration

Human approval gates

A workflow can send notifications and enter data with no one checking each step; however, a person has to decide before it grants system access, issues a refund, sends a contract, or releases a payment. If your tool has no approval step, you will have to build one from separate tools.

You can insert an approval step anywhere in a workflow. When the workflow reaches that step, it pauses and sends the approver whom you name a notification through Channels. If the approver approves, the workflow continues; if they reject the request, the workflow follows the alternate branch. If no one answers before the timeout, the workflow escalates the request according to the timeout rule that you set.

Durable execution with retries illustration

Durable execution with retries

If a step in an automation fails with no alert, you may first learn about the failure when a customer asks about a missing confirmation email. If the tool saves no record of the run, you will also have to work out where the automation stops and why.

Builder Workflows executes each workflow on a durable pipeline engine, which saves each step's result so that the engine can resume the workflow from its last completed step. If a step fails, the engine retries it on the schedule that you configure. If the failure is permanent, the workflow logs the error, follows the error branch if you define one, and alerts the workflow's owner. The engine writes every run to an audit trail, so you can trace what happened, when it happened, and why.

Triggers from events, schedules, and webhooks

Your app may have to act on a user action, a scheduled time, a webhook from another service, or a change in your data. If a tool starts workflows from user clicks alone, your app can respond only to what users do inside it.

A workflow can start from a form submission, a button click, a record change in Tables, a scheduled time, a webhook from an outside service, or a manual trigger in your app. You can also give one workflow several trigger types, so the same logic starts whether a customer submits a form or your payment provider sends a webhook.

Actions across Delalify and external services

If your automation tool can only send email, you will need a separate backend to create records, update contacts, upload files, call outside APIs, and change permissions.

Built-in actions create and update records in Tables, add contacts to People, send messages through Channels, upload files to OneCloud, and change access in Teams. HTTP request blocks call any external API, while webhook responses send data back to the service that called the workflow.

Full audit trail on every execution illustration

Full audit trail on every execution

When a workflow produces the wrong result, you will need to know which step fails, what data it processes, and who triggers it. If your tool reports only success or failure, you will have to guess the rest.

Builder Workflows logs the trigger event, the data at each step, the path that the workflow takes at each branch, the time that each action takes, and the final outcome of every run. You can search and filter these audit trails, so your compliance team can review every automated decision, while anyone who debugs a failed run can start from its log.

What changes when your operations team owns the logic

Your operations team owns the rules

Your operations team builds and maintains the workflows behind its apps, so the team updates a workflow itself when the rule in it changes.

A person approves each sensitive action

Before the workflow grants access, releases funds, or sends a contract, an approval step pauses it until the approver whom you name makes a decision. If the approver does not answer in time, the workflow escalates the request under your timeout rule.

Steps complete even when connections drop

The pipeline engine retries a step that fails and resumes a crashed workflow from its last completed step, so a workflow that loses its connection partway through can still finish.

Trace every automated decision

Builder Workflows writes every run to an audit trail that your compliance team can search, so they can review each automated action and trace any failure to the step where it occurs.

Builder Workflows in practice

HR adds one record to start a new hire's onboarding

When HR adds a new hire to Tables, a workflow creates their People contact profile, sets up a OneCloud shared drive with company documents, assigns Teams permissions for their department, sends a welcome message through Channels, and pauses until IT approves system access. The IT admin reviews the request and approves it from a notification on their phone.

Result

The IT admin approves each new hire's access by hand, while the workflow completes every other step on the onboarding checklist. HR no longer has to check each step for every new hire, because the workflow follows the same checklist each time.

HR adds one record to start a new hire's onboarding

A shop owner connects payment, confirmation, and fulfillment in one workflow

A shop owner builds a workflow for the store's Builder app. When a customer places an order, the workflow charges the card through Wallet, sends an order confirmation through Channels, creates a fulfillment record in Tables, notifies the warehouse team, and schedules a delivery follow-up for 7 days later. If the payment fails, the workflow follows the error branch, which notifies the customer, holds the order, and retries the payment after 24 hours.

Result

The warehouse team receives each order as soon as the payment clears, while the customer receives the confirmation through Channels at the same time. The workflow retries each failed payment after 24 hours, so the shop owner steps in only when the retry fails as well.

A shop owner connects payment, confirmation, and fulfillment in one workflow

Contract value sets who has to sign off

When a sales rep uploads a contract to OneCloud from the Builder app, a workflow sends it for review according to the deal's value. The workflow sends a deal under $10,000 to the sales manager alone, while it sends a deal of $10,000 or more to the sales manager and then to legal. For a deal of more than $100,000, the workflow adds the CFO as a third approver. At each approval step, the workflow notifies the reviewer and pauses until they decide. If any reviewer rejects the contract, the workflow returns it to the rep with that reviewer's comments.

Result

Each approver receives a notification as soon as the workflow moves the contract to their step, so they no longer find contracts late in their email backlog. The workflow sets the approvers from the deal's value, which means that the sales rep no longer has to track who needs to sign off.

Contract value sets who has to sign off

Property manager steps in only for escalations

A tenant submits a maintenance request through a Builder app. Beryl sorts the request by urgency, after which the workflow assigns it to the right vendor from a directory in Tables, sends the work order through Channels, and starts a 48-hour response timer. If the vendor does not respond within 48 hours, the workflow escalates the request to the property manager. When the vendor marks the job complete, the workflow sends the tenant a satisfaction survey.

Result

The property manager steps in only when a vendor misses the 48-hour window, since the workflow routes every other request from submission to survey. Beryl flags each urgent request, so the workflow sends it to a vendor as soon as the tenant submits it.

Property manager steps in only for escalations

Explore more of Builder

Sites

Builder generates marketing sites, dashboards, client portals, and SaaS interfaces from your description.

Learn more

Apps

Builder generates native apps that install on a device and keep working offline.

Learn more

Components

Start each Builder project from ready-made blocks, a full template, or components from the gallery.

Learn more
View all Builder features

Visual backend logic for every app

Once you have early access, your operations team can build its first workflow, with approval steps, retries, and an audit trail of every run.

Get early accessView all products