Most of what a business application does is not a form. It is the follow-up that should have gone out on Thursday, the approval nobody chased, and the status that should have flipped when the invoice cleared. Workflows run that work in the background, on the same permission model as everything else.
Email or SMS out through the same communication layer the inbox uses, so the sent message is part of the conversation rather than lost in a provider.
Change a status, assign an owner, write a calculated value, or create a related record.
Reach an outside system mid-sequence and branch on what comes back.
Summarize activity, extract entities from unstructured text, or draft content, routed to the inference workers.
Pause for a fixed duration or until a date threshold passes, without holding a connection open.
Stop, lock the relevant record from editing, and wait for a named person to sign off before continuing.
Evaluate field values or custom metadata and take a different path.
Compose larger processes out of smaller ones rather than one unmaintainable sequence.
Automation fails in three predictable ways: the same job runs twice, a failure disappears silently, or someone edits a live workflow and corrupts the runs already in flight. All three are handled structurally.
Background workers claim a job under a lease before touching it. Two servers cannot pick up the same step, which is the difference between sending one payment reminder and sending four.
A failed step is evaluated against its retry policy and retried on a schedule. It does not vanish. Run history shows what failed, when, how many times, and what the error was.
Changing an automation does not rewrite runs already in progress. The engine creates a new version, routes new work to it, and lets everything currently running finish on the definition it started with. This is version isolation, and it is why you can improve a process without waiting for a quiet weekend.
An automation you are afraid to edit is an automation that stops improving. Version isolation exists so that fear is unnecessary.
Managers can review run history, failure rates, and cycle times, and those reporting views go through the same permission function as everything else. A dashboard is not a side door around record permissions.
Yes. An approval step halts the run, locks the record from editing, and waits for an authorized signature before continuing.
Runs in progress finish on the version they started with. Your edit becomes a new version that new runs use.
Yes. Run history, step outcomes, retries, and approvals are all recorded, and the reporting views respect record permissions.
Create an account, explore the full builder console, and launch your first application on a custom domain. Nothing is charged while your application is still in development.
No credit card required. The console preview, the documentation, and the architecture reference are all readable before you sign up.
Get started free Read the docsUniversal Inbox brings work needing attention into one place while conversations, form submissions and business records remain their original sources. Refresh a changed item before approving an action. GoClaw research and planning are read-only; material changes require the configured approval policy and permission for the specific action.
Read the guideConfigure connections and credentials for the intended app and organization, verify the connection, then explicitly enable the supported workflow or schedule. Mail delivery, payment processing, Snowflake export and background jobs depend on their configured providers and workers. A queued receipt is not delivery, bank settlement or completed execution.
Read the guide