Migrating Base44 workflows: how multi-step automations move

Workflows versus automations

Base44 has had two engines for backend work that happens on its own.

Automations, the older engine, attach a single backend function to a trigger: a schedule, a data change or a connector event. Each run can last at most three minutes, and runs can’t be closer together than five minutes (Creating automations).

Workflows replace them. According to Base44’s workflows guide, apps created from 6 July 2026 use workflows, older apps may still use automations, and an app has one or the other, never both. Older apps can switch in one step from the Automations page, which recreates each automation as a workflow with the same trigger and schedule. Workflows need the Builder plan or above.

What workflows add:

• Several steps in one flow, instead of one function per trigger.
• Conditions that send each run down a different path.
• Waits of minutes, hours or days between steps.
• Run history, step by step, and versions: editing a workflow creates a new version, and runs already in progress finish on the version they started with.

A typical example: when a new lead signs up, send a welcome email, wait two days, then send a follow-up only if they haven’t replied.

Triggers

A workflow starts from one trigger. Base44’s guide lists six in the editor:

The developer API adds a few more trigger types: app user sign-up or sign-in, inbound webhooks, and triggers used by Base44’s Superagents (Apps API: workflows).

What a workflow is under the hood

Behind the diagram in the dashboard, each workflow is two things:

1. A definition written in the CNCF Serverless Workflow 1.0 format, an open standard. Its do list holds the steps, and every step is one of three kinds: a call that runs an activity (such as running one of your backend functions), a switch that branches on a condition, or a wait that pauses for a duration or until a time.
2. A trigger configuration, stored separately, with an optional condition written as a jq expression over the trigger’s payload. The workflow only runs when the expression is true.

Every change to a definition is saved as an immutable version whose ID is the SHA-256 hash of the definition, and each run records the version it executed.

Here is the lead follow-up example, simplified for illustration; the field names in a real Base44 definition differ in detail:

document:
  dsl: '1.0.0'
  name: lead-follow-up
do:
  - sendWelcome:
      call: run_backend_function      # e.g. sendWelcomeEmail
  - waitTwoDays:
      wait:
        days: 2
  - checkReply:
      switch:
        - noReplyYet:
            when: ${ .lead.replied != true }
            then: sendFollowUp
        - replied:
            then: end
  - sendFollowUp:
      call: run_backend_function      # e.g. sendFollowUpEmail

The definition is portable because it’s a standard format. What isn’t portable is everything that makes it run.

What it takes to run a workflow outside Base44

To move a workflow, four things have to exist on the other side:

1. The definitions and triggers, exported from Base44 and kept with your code.
2. A scheduler that honours cron schedules in the right time zone, intervals and one-time runs.
3. An event source that notices when records are created, updated or deleted, evaluates each trigger’s jq condition, and starts the right workflows.
4. A step runner that calls your backend functions with the right identity and arguments, follows branches, and keeps a run’s place through a long wait, including across server restarts.

Most migration approaches stop here, because the definitions are the easy part and the engine is the hard part. Rebuilding on another platform usually means re-creating each workflow by hand in that platform’s own automation tool, then testing that it behaves the same.

How Unbase44 migrates workflows

Unbase44 reads every workflow’s definition and trigger from Base44 and writes them into your repository alongside your functions and tables. The backend that runs your app includes a workflow engine for the same definitions: scheduled triggers (cron with time zones, intervals and one-time runs), data-change triggers with their jq conditions, steps that run your backend functions, branches and waits.

Apps still on the older automations engine are supported too. There’s no need to switch to workflows before you migrate.

Some triggers belong to Base44 itself. “App publish” fires when you publish from Base44’s builder, which you won’t be using afterwards; its natural replacement is your deploy pipeline. “App payment” depends on Base44’s payment integration. The analysis lists each of your workflows with its trigger before you pay, and flags anything that needs a decision.

After the move, workflow steps no longer draw on integration credits. Base44 charges roughly one credit per ten steps, plus the cost of what each step does (Credits). On your own server, steps cost nothing extra, and email or AI calls inside them are billed by your own providers.

Checking that workflows behave the same

Before switching over:

• Make a list from Base44’s Workflows dashboard: each workflow, its trigger, whether it’s active, and how its last run ended.
• Check the schedules’ time zones. A daily digest that moves by an hour is the classic migration bug.
• Test on the new app with realistic data. Remember that running a workflow by hand executes real actions, like real emails and real record changes, so use test records and your own address.
• Watch for loops. An entity workflow that updates the record that triggers it can run forever. Base44’s guide warns about this; the same care applies anywhere.

At the switch:

• Deactivate the workflows on Base44 once the new app is live. Otherwise scheduled jobs run twice, and your customers get two copies of every email. Keep the Base44 app itself published while your users sign in to the new app for the first time.
• Let in-flight runs finish. A run that is waiting on Base44 completes there; new runs start on your server.
• Update external senders. If another service sends events into your app, such as a Stripe webhook that calls one of your backend functions, point it at the new address.