Triggers

What are triggers?

A trigger determines when a workflow starts. Every workflow execution begins with a trigger.

Triggers are attached to a published workflow version. The workflow must be published before any trigger can fire it. Triggers can be enabled or disabled independently without changing the workflow itself.

Trigger types

Choosing the right trigger

How a trigger reaches a Runner

Regardless of which trigger fires, the path from trigger to result is the same. The Hub queues the execution, a Runner is assigned, the workflow runs, and the result is reported back.

Manual triggers

Manual triggers fire on demand. A user clicks Run in Exekra Studio (during workflow authoring) or in the Hub dashboard (against a published workflow). No additional configuration is required.

Manual triggers are useful for testing during authoring, for ad-hoc runs, and for processes that need a human checkpoint before they start.

Schedule triggers

How they work

Schedule triggers fire on a cron expression. The Hub evaluates all enabled schedule triggers in-process and creates a queued execution each time a schedule matches the current time. The execution then follows the same path as any other trigger.

The Hub re-reads each trigger from the database at fire time, so disabling a schedule from the dashboard or via the API stops it firing immediately on the next evaluation.

Cron examples

Timezone behavior

If the Hub server runs in UTC and you want a workflow to fire at 09:00 in a different business timezone, convert the time to UTC when writing the cron expression. If the Hub runs in your business timezone, write the cron expression in that timezone directly.

Webhook triggers

How they work

A webhook trigger exposes an HTTPS endpoint on the Hub. External systems start the workflow by sending an authenticated POST request.

Example request

POST https://hub.example.com/webhook/trg_8b91c3f4e2a04d7
Content-Type: application/json
X-Webhook-Secret: 0c9f4e7d3a8b2f5c1e6d4a9b7c3f8e2a5d1b6f4e9c2a8d3b7e5f1a4c6d9b2e8f

{
  "customerId": 123
}

Successful response:

HTTP/1.1 200 OK
Content-Type: application/json

{ "success": true, "executionId": "exe_4d2e1a6b8c..." }

Authentication

Every webhook trigger has a secret. The Hub generates a fresh 32-byte cryptographically random secret at creation and stores it. Incoming requests must include the secret in the X-Webhook-Secret header.

The Hub uses a timing-safe comparison to prevent secret discovery via response-time analysis.

Security guidance

Starting workflows from your own applications

Applications that start workflows programmatically use a webhook trigger. The same POST /webhook/<id> endpoint with the secret header is the supported API path; this is how the platform exposes "API trigger" semantics.

For richer programmatic control (creating triggers, listing executions, fetching results), use the Hub REST API with a user JWT.

Trigger limits

What to read next

• Execution lifecycle: what happens after a trigger fires, including queueing, assignment, retries, and stale-execution handling
• Security model: RBAC, credentials, and audit posture for everything the trigger fires
• Studio guide: authoring the workflows that triggers run