Workflows

Workflows let you automate tasks in your project using a Trigger -> Condition -> Action pattern. When an event occurs, your workflow checks the conditions and runs the actions automatically.

​

Creating a workflow

​

Trigger types

See the Workflow Node Reference for the full trigger list and every action category.

​

Merge variables

Reference data from the trigger or any earlier node with {{...}} syntax — for example {{trigger.email}} or {{ai.response}}. In any text field, typing {{ opens an autocomplete of available variables, and inserted references render as pills that show whether they resolve. A Webhook trigger’s request body lives only under trigger.output.payload (a posted email field is {{trigger.output.payload.email}}), and every run carries {{trigger.output.timestamp}}, the ISO 8601 time Hiveku received or fired the event: a webhook’s arrival, a schedule’s fire time, a database change, a form or event trigger’s event time, or the start of a manual or test run. A replayed run keeps the original run’s time. If a variable cannot be resolved at run time, its value is dropped rather than sent as literal {{...}} text. A field whose entire value failed to resolve is omitted: a create leaves it unset, and an update leaves the existing value untouched rather than clearing it. Every miss is listed in the run inspector on the affected step (“N merge variables resolved to nothing”), so a typo’d tag shows up in Run History instead of in someone’s inbox. To give a variable a fallback, use a double pipe: {{trigger.name || 'there'}}. The fallback fills in when the value is missing, empty, or only spaces (a blank optional form field counts); 0 and false are real values and are kept. Quotes around the fallback are removed. A fallback that fills in is not a miss, so {{trigger.name || }} leaves the value blank without flagging it. Everything after the first || is plain text, never looked up. {{trigger.output.payload.company || trigger.output.payload.name}} falls back to the words trigger.output.payload.name, not to the name. There is no chaining. To fall back to a second field, check the first with a Conditional node (or return the first non-empty value from a Code node) and reference that node’s output. If you mean text that looks like a path, quote it: {{ref || 'trigger.name'}}. workflow_validate warns fallback_default_is_literal, and a workflow_test template_values entry carries a hint, when a default looks like a reference. Only the double pipe is a fallback. A single pipe or or ({{trigger.name | there}}, {{trigger.name or there}}) is flagged on the step with a hint. Most steps drop it like any other miss, but some, such as HTTP Request, Send Email and AI Agent, send it out as written, braces included. A field whose name really contains or or |, such as “Residential or Commercial”, still resolves in the other steps.

​

Common use cases

• Auto-deploy — deploy your site automatically when changes are pushed to GitHub
• Notifications — send a Slack message or email when a form submission arrives
• Scheduled tasks — generate a weekly analytics report every Monday
• React to database changes — send a welcome email when a new user row is created
• Marketing automation — enroll a new CRM contact in a welcome drip; fire a one-off broadcast on a date

​

Marketing email actions

Workflows can fire your saved marketing campaigns and sequences as actions. Three node types integrate the marketing email platform:

​

Pre-flight requirements

Marketing email nodes require the same gates as the manual Send button (see the Setup Checklist):

• Email marketing enabled on your account
• At least one verified sending domain that the campaign’s from-address is on
• A physical mailing address on your account (required by anti-spam law)

If any gate fails, the node errors at run time and the workflow falls through to its error branch (or fails the run if no error handler is attached). Check the setup banner on the Marketing dashboard to confirm all gates are green before relying on these nodes in production.

​

Idempotency

Add-to-sequence and remove-from-sequence are idempotent — re-running with the same sequence and contact is a safe no-op. Send-campaign is guarded by status: it only fires for campaigns in draft or scheduled status, so accidentally re-firing the same workflow won’t double-send a campaign that’s already sending or sent.

​

Run history

Every workflow execution is logged in the Run History tab. Each entry shows:

• Trigger event details
• Whether conditions were met
• Action results (success or failure)
• Execution time

​

Debugging failed runs

Click a failed run in the history to see the full error trace. Common issues include:

• Invalid webhook payload
• Network timeouts on external API calls
• Missing environment variables

​

Dead letter queue

When a workflow fails repeatedly, the event moves to the Dead Letter Queue. From there you can:

• Replay — retry the failed event with the same payload
• Dismiss — remove the event from the queue

​

Automatic safeguards

Workflows carry built-in protection against runaway automation:

• Failure alerts — with Email admins when a triggered run fails switched on in the gear menu (Workflow Options, top right of the workflow editor), account owners and admins get an email when a triggered run fails: webhook deliveries and new visitors included, as well as schedules, database changes, form submissions, other event triggers, and any retry of one of those runs (an AI agent connected to your account can retry a failed run with your approval, using workflow_run_retry). One email per incident, not per failed run. Manual runs, Test Runs, the test webhook URL, runs an AI agent starts and replays never alert, and a retry of one of those runs is recorded as a replay, so it never alerts either. Saving the workflow or restoring a version never switches alerts off.
• Circuit breaker — 5 consecutive failed runs started by a schedule, a database change, a form submission trigger or another event trigger auto-pause the workflow. A retry of one of those runs counts toward the 5 too, whoever asked for it, so a failing retry can pause the workflow. A failed Webhook or New visitor run never pauses a workflow, and neither does a retry of one, which keeps its Webhook or New visitor origin: it is counted and alerts (when failure alerts are on), and the workflow keeps accepting every delivery, so a flaky side step cannot switch off lead capture. Manual runs, Test Runs, runs an AI agent starts, and replays never count toward the breaker, and a retry of one of those runs is recorded as a replay, which never counts either, so iterating on a half-configured node in the editor cannot pause a workflow whose real traffic is healthy.
• Auto-pause emails — when a workflow auto-pauses for any reason, account owners and admins receive an email naming the workflow and the reason, with a link to resume it.
• Nothing is lost while paused — trigger events that arrive during a pause are recorded as blocked runs (the workflow list shows “Paused” with a blocked count), and resuming the workflow replays them automatically, oldest first, unless the workflow is switched off when you resume it: then they are not replayed. Webhook deliveries that arrive while paused are stored too, but Resume does not replay them; an AI agent connected to your account can list them and replay them with your approval.
• Daily AI budget — each workflow may execute at most 200 AI-agent node runs per day, and at most 25 within a single run. Crossing the daily ceiling pauses the workflow and emails the owners; a mis-wired loop cannot silently burn AI credit overnight.
• Duplicate-send guard — side-effecting steps (emails, texts, posts) that completed in the original run are skipped when the run is replayed.

​

Switching a workflow off

A switched-off workflow runs from none of its triggers: webhooks, new visitors, schedules, database changes, form submissions, other event triggers, and retries of the runs they started all skip it.

• Webhook senders still get a success answer. A form or service that posts to the workflow’s webhook address gets 200 with the message “Workflow disabled”, so it does not keep retrying. The submission is still saved with your form submissions and you still get the usual new-submission email; only the workflow’s steps do not run. A protected webhook still checks its secret first.
• Waiting runs stop. A run one of its triggers started that is waiting at a wait or approval step is cancelled instead of continuing.
• What you start yourself still runs. A Test Run works on a switched-off workflow, and Re-run on a past run (a replay) runs it for real.
• Switching it back on starts fresh. Nothing that arrived while it was off is run when you switch it back on.

​

Needs your attention

Every hour Hiveku checks your switched-on workflows, paused ones included, and their webhook addresses. It posts a notice in the Needs your attention strip above your workflow list on the Workflows page when:

• a step is not set up (a required setting is missing, its step type is no longer available, or it has no website project chosen), a connection points to a deleted step, there is no trigger, none of the steps is connected to the trigger, or the workflow has another setup problem the editor lists, so runs would fail or do nothing;
• a live webhook address accepts posts from anyone, although its settings hold a secret or say one is required.

Open takes you to the workflow. A notice clears itself within an hour of the problem being fixed, or of the workflow or webhook being switched off. Dismiss means you have decided not to act: that notice is not shown again for 30 days while the problem stays the same, and a different problem on the same workflow still gets a notice. After you open a notice, the same one waits a day before it comes back if the problem is still there. Nothing is emailed, and Hiveku never changes a workflow or turns on webhook authentication for you: turning it on would refuse every sender that does not send the secret. The strip also lists notices about failed runs, automatic pauses and stalled runs.

​

Workflow credentials

If your workflow calls external APIs, store API keys and tokens in Workflow Credentials rather than hardcoding them. Credentials are encrypted and injected at runtime. Some webhook addresses work as a password: Slack, Discord, Microsoft Teams and Power Automate, Zapier, Google Chat, Make, IFTTT, Pipedream and Pabbly webhook URLs, and any address with a user name and password in it. API keys and AI agents connected to your account see these as [redacted] in every workflow they read, including run history and the workflow’s name and description, and so do the results of a Test Run. The workflow editor still shows them to you, and your runs still use the real address. An AI agent that sends [redacted] back keeps your saved address; to reuse one in another workflow it clones the workflow or uses an environment variable ({{env.NAME}}) you set up. Your own Hiveku webhook address is never hidden.