Automate

Choose how workflows start

A trigger is the entry point that creates a workflow run. Declare the durable trigger insolidactions.yaml, then use the project tabs to inspect or override its operational settings.

Last reviewed July 14, 2026

Problems this solves

Start with the recurring problem, then use this feature when its boundary matches the outcome you need.

Problem

React when another system sends an event

An order, form submission, or provider event should start durable work as soon as it arrives.

How this helps

Expose the workflow through an authenticated Webhook and retain the resulting execution in Runs.

See webhook examples →

Problem

Run recurring work without an operator

A sync, report, or cleanup must happen on a reliable cadence even when no person or AI client is online.

How this helps

Use a Schedule with an explicit timezone and input, then verify every firing in Runs.

See the 15-minute calendar sync →

Trigger types

Type	Use it when	Manage it
Webhook	An external service or HTTP client should start the workflow.	Project → Webhooks
Schedule	The workflow should run automatically on a cron cadence.	Project → Schedules
Internal	A parent SolidActions workflow should start a child workflow in code.	Source and run detail
Manual / API	A person, script, or REST client needs an on-demand run.	CLI or REST API
MCP tool	An authorized AI client should call an exposed workflow as a tool.	Workflow YAML plus an MCP connection

Declare the primary trigger

workflows:
  - id: process-order
    name: Process order
    file: src/process-order.ts
    trigger: webhook
    webhook:
      auth: hmac
      response: instant

Deploy YAML changes with solidactions project deploy. The Workflows tab then shows the deployed entrypoint and trigger summary for the selected environment.

Start an on-demand run

solidactions run start my-project process-order \
  -e production \
  -i '{"orderId":"ord_123"}' \
  --wait

--wait keeps the CLI attached until the workflow finishes or fails. Without it, the CLI returns the run ID and execution continues on SolidActions. Follow the run in Automate → Runs.

Enable and disable execution

A deployed workflow and its project each have an enabled state. Turning off a workflow prevents that entrypoint from running. Turning off the project prevents every workflow in that environment from running. Pausing one schedule affects only that schedule.

Keep environment boundaries visible

Webhook URLs, schedules, variables, and run histories belong to a specific project environment. Before copying an endpoint or enabling a timer, verify the production, staging, or dev chip beside the project name.

Examples

hello-world — a small webhook workflow.
features-examples — schedules, webhooks, child workflows, retries, and other SDK patterns.

Continue with Webhooks orSchedules.