An automation that only runs when someone clicks Run isn't automation — it's a fancy button. FluidGrids gives workflows four ways to start on their own: API invocation, inbound webhooks, cron schedules, and chat messages.
Triggers are nodes on the canvas, so the workflow's "when" lives in the same diagram as its "what". Drop a schedule trigger and set the cron expression — six o'clock every morning for the reconciliation run. Drop a webhook trigger and FluidGrids issues a unique endpoint URL for external systems to POST to. The API trigger makes any workflow invocable from your own code, and the chat trigger turns a workflow into something you can talk to.
Schedules respect lifecycle: they arm only when the workflow version is activated, and deactivating the workflow disables them atomically. There is no zombie cron firing a workflow someone thought they turned off — the activation state and the schedule state are the same state.
Webhooks are fully observable. Every delivery is logged with its payload and validation result; invalid payloads are recorded but never start runs, and any failed delivery can be retried individually from the log. Event filters go further, letting a registration start runs only for events matching an expression — so the order-update webhook can trigger the escalation workflow only when the status is actually "failed".
Every registration can be toggled on and off without deleting it, and each run records which trigger started it. When something fires at 3 a.m., the answer to "why did this run?" is one click away, not a forensic exercise.
Do it yourself
Give a workflow four ways to start on its own — cron schedule, inbound webhook, API call, and chat — then toggle, filter, and audit each trigger delivery by delivery.
Ready to make this your story?
