Feature · Workflow Engine

A workflow engine built for the fifth and tenth build, not the first demo.

The visual canvas is the part of a workflow engine that sells the demo. The runtime is the part that keeps the business running. Strkr builds the runtime with the kind of discipline engineering teams expect from a production job queue: idempotency, retries with exponential backoff, dead-letter handling, rate limiting, parallel execution with join semantics, versioning, and a replay button for the day a flow fails on an edge case. The ops team ships twenty flows a quarter and runs them like a real engineering team runs code.

Start free trial See pricing

What a workflow engine actually has to do

The runtime semantics that separate production from demo.

The visual canvas is the easy part of a workflow engine. The hard part is the runtime: making sure a flow executes exactly once per trigger, retries transient failures without doubling the side effects, respects downstream rate limits, parallelizes where it can, serializes where it must, and surfaces failures the moment they happen. Most no-code tools ship the canvas and leave the runtime as an afterthought. The result is silent duplicates, lost executions, mysterious slowdowns, and a flow that works great in testing and quietly fails one in every forty times in production. Strkr builds the runtime first.

Exactly-once execution

A trigger fires once, the flow runs once.

The engine deduplicates triggers by event key. A record update that fires twice from a double-save produces one flow run, not two. The common failure where a flow runs twice and double-sends an email because the trigger fired twice does not happen.

Idempotent actions

Retries do not double the work.

Every action carries an idempotency key by default. A retry does not create a duplicate record, send a duplicate email, or trigger a duplicate webhook. The ops team reruns a failed execution without worrying about the downstream collateral.

Exponential backoff

Transient failures retry on a sensible curve.

When an action fails transiently (network blip, upstream 503, momentary rate limit), the engine retries on an exponential backoff with jitter. Three retries by default, configurable per action. A momentary upstream hiccup does not fail the flow.

Dead-letter queue

Persistent failures land somewhere visible.

After exhausted retries, failed executions land in a dead-letter queue visible in the admin surface. The ops team sees the failure, inspects the payload, fixes the root cause, and replays the batch. The common failure where errored executions disappear into a log file nobody checks does not happen.

Rate limiting

The engine protects itself and the downstream APIs.

Each action carries a configurable rate limit. External API actions respect the destination rate limit by default. When upstream fires faster than downstream can accept, the engine queues work and applies backpressure. A 429 storm against an external API does not poison the queue.

Parallel execution

Fan out, fan in, keep the state.

A flow can fan out into parallel branches, run each branch independently, and join them back when all finish. State flows across the fan without the common failure where parallel branches lose context mid-execution.

Serial execution

When order matters, order is preserved.

When a flow needs strict serial ordering (write to A, then write to B, then update C), the engine preserves ordering. The common failure where a visual builder reorders steps for a visual rendering and the runtime respects the visual not the semantic order does not happen.

Durable waits

A seven-day wait survives server restarts.

Wait steps persist in durable storage. A seven-day wait or a wait-for-event step survives a server restart, a region failover, and a routine deploy. The engine resumes the flow at the wait exactly when the condition fires. Long-running flows do not break on normal infrastructure events.

Audit log

Every execution, every step, logged.

Every execution lands in the audit log with the triggering event, the step-by-step state, the acting user context, and the outcome. SOC 2 and HIPAA reviewers walk the full trail. The operational surface is also the compliance surface.

The operational surface

A flow that fails has to tell you where and why.

The hardest part of running automation at scale is operating it after it is in production. A flow that fails silently for three days is worse than no automation at all. Strkr builds the operational surface with the same care the canvas gets. The run history shows every execution. The node-level trace shows the exact state at each step. The replay button reruns a failed execution. The metrics panel shows which flows are slow, flaky, or over budget. The on-call operator finds out about broken flows in minutes, not three days later when a sales rep notices the leads stopped routing.

Run history

Every execution of every flow, sortable.

The run history shows every execution with its status, duration, triggering record, and current state. Sort by failed, by slow, by pending. The common pattern where a failed flow lives in a dusty log file nobody checks does not surface because the operational surface is where the ops team already works.

Node-level trace

See the state at every step.

Clicking into a run shows every node that executed with its input, output, duration, and any error. A failed branch highlights the exact node where it broke with the error payload. Debugging a real production failure takes seconds instead of a half-hour of guessing.

Replay

Fix the cause, rerun the batch.

After fixing the root cause of a failure, replay the failed runs with one click. The engine re-executes against the original triggering records and the original state. The common pattern where a failed day of automation requires a manual re-import does not happen.

Metrics panel

Average duration, failure rate, trend.

Each flow carries a metrics panel: average duration, p95 duration, failure rate, failure rate trend, runs per day. The ops leader spots the flow that got 10x slower after a change and investigates before users notice.

Alerting on failures

A ping when the flow goes sideways.

Flows alert on sustained failure rates, on new error types, and on duration regressions. Alerts route to Slack, email, or SMS through Strkr Messaging. The on-call operator hears about the broken flow in minutes.

Sandbox and promotion

Edit in sandbox, promote to production.

Flows edit in a sandbox against sample records. Promotion to production is a controlled step with a diff view and an approval. The common failure where a well-meant edit to a live flow breaks the overnight run gets caught at the diff review instead of at the overnight page.

Versioning

Every save is a version with a diff.

Each save produces a numbered version with a diff view. Rollback to any prior version is one click. The lineage of a flow becomes a readable history. The common failure where nobody can explain what changed last Tuesday does not happen.

Role-based access

Who can edit, trigger, view, approve.

Flow permissions follow the Strkr role model. Builders edit. Operators run. Executives view metrics. Field-level permission on sensitive data (compensation, legal clauses, billing) applies through the flow context the same way it applies to record views.

Cost ceilings

An ops safety net against runaway flows.

Each tenant can set cost ceilings on expensive actions (external API calls, AI invocations, SMS sends). A runaway flow hits the ceiling, pauses, and alerts the admin. The common failure where a misconfigured flow generates a surprise bill does not happen.

Triggers that cover the real event space

Every record change, every schedule, every external event.

The reason most workflow engines feel limiting is the trigger surface. The vendor shipped twelve triggers in the demo and the thirteenth real motion requires a workaround. Strkr ships 40 plus triggers out of the box, with a webhook trigger that handles the long tail of custom shapes. The flow builder can trigger on any state change the platform tracks, any schedule the ops team configures, and any external event an upstream system emits. The common pattern where the ops team gets 80 percent of the automation they want and workarounds the other 20 does not happen because the trigger surface already covers 95 percent of real motions.

Record events

Created, updated, deleted, field changed.

Trigger on any record created, updated, or deleted. Trigger on a specific field change (stage advanced, score crossed, close date moved). Trigger on a combination of field changes. The granularity covers every real state transition the platform tracks.

Scheduled triggers

Cron, business hours, relative dates.

Scheduled triggers fire on cron expressions, business-hour windows, and relative-date rules (3 business days after close, 14 days before renewal, first business day of each month). The engine respects timezone configuration and local business hours per team.

Email events

Open, click, reply, bounce, unsubscribe.

Email events trigger flows. A reply pauses the active nurture, a bounce suppresses the contact, an unsubscribe records the consent event, a click updates the lead score. The engine reads marketing engagement as a first-class event source.

SMS events

Message received, opt-out, delivery, undelivered.

Strkr Messaging events trigger flows. An inbound text routes to the right owner, an opt-out suppresses the contact across every channel, an undeliverable number flags the record. The native messaging layer feeds the engine without a glue step.

Document events

Sent, opened, approved, signed, rejected.

Document lifecycle events trigger flows. A document signed moves the opportunity to Closed Won. A document approved moves it to Proposal Sent. A document rejected moves it to Closed Lost with a captured reason.

Meeting events

Booked, held, no-show, canceled, rescheduled.

Meeting events trigger flows. A no-show kicks off a recovery sequence. A canceled meeting prompts a reschedule flow. A held meeting fires the follow-up draft. The engine reads calendar activity as a first-class event source.

Task events

Created, completed, overdue, reassigned.

Task events trigger flows. An overdue task reassigns to the manager. A completed task fires the next step. A reassigned task notifies the new owner. The engine respects the task lifecycle as a workflow primitive.

External webhooks

Any upstream system can trigger a flow.

A webhook endpoint per flow accepts calls from any upstream system. Signed payloads, replay protection, rate limiting, and schema validation apply. The engine accepts triggers from the long tail of custom systems the business runs.

Assistant triggers

Strkr AI output as a flow trigger.

The assistant can trigger flows based on patterns it detects: churn risk crossed, expansion signal fired, objection cluster matched. The AI feeds the engine with semantic triggers that pure field-based rules cannot express.

Actions that compose the real motions

Sixty plus native actions, zero glue vendor required.

The second half of the trigger surface is the action surface. If the vendor ships 60 beautiful triggers and 8 actions, every real motion ends with a webhook to another vendor that charges per task. Strkr ships 60 plus actions covering CRM writes, messaging sends, document generation, assistant calls, and external API calls, so the real motions compose end to end without a per-task vendor sitting in the path. The economics change. The reliability changes. The audit trail stays coherent because every action lives inside the same platform as the trigger.

Record writes

Create, update, delete, assign, score.

Actions create new records, update specific fields, change ownership, update scoring, delete, archive. Every write respects the permission model, the validation rules, and the audit log. The common failure where automation bypasses the field-level validation does not happen.

Email actions

Send, add to sequence, pause, resume.

Send transactional email, add a contact to a sequence, pause an active sequence, resume a paused sequence, exit a sequence. The engine reads the marketing surface as a first-class action target.

SMS actions

Send through Strkr Messaging, native and compliant.

Send an SMS or MMS through Strkr Messaging. Delivery, opt-out, consent, and compliance all inherit automatically. The common failure where SMS requires a separate vendor and a glue layer does not happen.

Document actions

Generate, route for approval, send for signature.

Generate a proposal from a template, route it through the approval chain, send it for signature, archive the signed PDF on the account. The full document lifecycle runs as native actions on the canvas.

Assistant actions

Draft, summarize, extract, suggest, score.

Call Strkr AI with a prompt and a set of record references. The output passes to the next node in the flow. Drafts, summaries, extractions, suggestions, and scores all live as flow actions.

External API

Call any REST endpoint with signed credentials.

Call any external REST endpoint from a flow. Credential management lives in Strkr Secrets with per-tenant encryption. The common failure where external API credentials sit in a flow definition as cleartext does not happen.

Slack and Teams

Post messages, open DMs, start threads.

Native Slack and Microsoft Teams actions post channel messages, open DMs, and start threads. The ops team routing alerts to the right channel does not need a glue vendor.

Calendar actions

Book a meeting, cancel, reschedule.

Native calendar actions through Google Workspace and Microsoft 365 book meetings, cancel, reschedule, and add attendees. The scheduling layer composes with the automation layer.

Flow composition

A flow can call another flow.

A flow can invoke another flow as a subflow with input parameters. Reusable logic lives as a subflow with a stable interface. The ops team composes complex motions out of small, testable primitives.

How the workflow engine plugs into the rest of Strkr

An engine inside the system of record, not next to it.

A workflow engine that lives next to the CRM is a glue layer. A workflow engine that lives inside the CRM is a nervous system. Strkr builds the second shape. The engine reads from and writes to the same records every other function reads from and writes to, with the same permission model, the same audit log, and the same compliance posture. The common pattern where the automation runs in a separate system with a separate schema and a separate audit trail does not apply.

Shared CRM

Every record, every field, both directions.

The engine reads from and writes to the full CRM data model: accounts, contacts, opportunities, custom objects. Field changes trigger flows. Flows update fields. The schema is the schema.

Shared permission model

The flow respects what the user can see.

Shared audit log

Every flow write is a reviewable write.

Every write a flow performs lands in the same audit log as every manual write, with the acting flow identified alongside the triggering event. The compliance review walks one log, not two.

Shared messaging

SMS and MMS as a native action.

Strkr Messaging is a native action. Compliance, delivery, opt-out, and consent all inherit from the platform. The engine does not glue to a second messaging vendor.

Shared document stack

Templates, merge, signature, archive.

The document stack exposes as native actions. The engine does not glue to a second document vendor. The paper trail stays on the same records as the automation that drove it.

Shared assistant

Strkr AI as a native action.

The assistant exposes as a native action. The engine calls the AI with record context and the output passes to the next node. One AI capability, one audit log, no credit meter.

Shared reporting

Flow executions as a reportable dataset.

Every flow execution lands in a reportable dataset. Build dashboards showing flows per day, failure rate by flow, average duration, backlog depth, cost per flow. The ops function gets a native dashboard without a second analytics tool.

Open APIs

Webhooks in, REST out, every event.

Every record change emits a webhook. Every flow and every record is readable through REST with tenant-scoped authentication. External systems integrate without a middleware vendor in the path.

Flat seat pricing

No per-run fee, no per-step fee.

Strkr charges flat per seat. No per-run fee on flows. No per-step fee. No per-contact tier. A high-volume automation does not multiply the bill the way a per-task vendor would.

A workflow engine that operates like a production job queue.

Exactly-once execution, idempotency, retries, dead-letter handling, rate limiting, parallel paths with join semantics, durable waits, versioning, and replay. All on flat per-seat pricing with no per-run fee. Open the admin surface on your real pipeline and see how a flow that used to run in Zapier runs faster and cleaner natively.

Start free See pricing

Common questions

What buyers ask about this feature.

What is a workflow engine and how is it different from a flow builder?

A workflow engine is the runtime that actually executes flows reliably: exactly-once execution per trigger, idempotent actions, retries with exponential backoff, dead-letter handling for persistent failures, rate limiting against downstream APIs, parallel execution with join semantics, durable waits that survive server restarts, and versioning with replay. A flow builder is the canvas where you draw the flow. The distinction matters because most no-code tools ship a nice builder on top of a shaky runtime, and the result is silent duplicates, lost executions, and mysterious slowdowns in production. Strkr builds the runtime first.

How does Strkr handle retries and prevent duplicate side effects?

Every action in Strkr carries an idempotency key by default, so a retry does not create a duplicate record, send a duplicate email, or trigger a duplicate webhook. Transient failures retry on exponential backoff with jitter, three retries by default and configurable per action. After exhausted retries, failed executions land in a dead-letter queue visible in the admin surface, where the ops team inspects the payload, fixes the root cause, and replays the batch with one click. The common failure where a flow retries and double-charges a card or double-sends an email does not happen because the engine owns the idempotency.

Can long-running flows survive deploys and infrastructure events?

Yes. Wait steps persist in durable storage. A seven-day wait, a wait-for-event step, or a wait-until-business-hours step survives a server restart, a region failover, and a routine deploy. The engine resumes the flow at the wait exactly when the condition fires. Long-running flows (nurture sequences, renewal watchlists, multi-week approval chains) do not break on normal infrastructure events. The durability guarantee ships on every tier and does not require a separate persistence configuration.

How does debugging work when a flow fails in production?

The run history shows every execution with its status, duration, triggering record, and current state. Clicking into a specific run shows every node that executed with its input, output, duration, and any error payload. A failed branch highlights the exact node where it broke. The replay button reruns the failed execution after you fix the root cause. Alerts fire on sustained failure rates, new error types, and duration regressions, routing to Slack, email, or SMS through Strkr Messaging. The on-call operator finds out about broken flows in minutes, not three days later.

Does the workflow engine respect permissions and compliance?

Flows execute with the permission context of the triggering user or a service account with explicit scopes. A rep-triggered flow cannot escalate to see records the rep cannot see. Every write a flow performs lands in the same audit log as every manual write, with the acting flow identified alongside the triggering event. The compliance posture (HIPAA BAA for regulated tenants, SOC 2 Type II in progress with Type I available on request, GDPR data residency) applies to the engine the same way it applies to the rest of the platform. The compliance review walks one log, not two.

Does the workflow engine ship on every tier or is it an add-on?

The workflow engine ships on every paid tier at no extra charge. The visual canvas, 40+ triggers, 60+ actions, versioning, run history, node-level trace, dead-letter queue, replay, durable waits, and metrics panel are all native. Strkr charges flat per seat with no per-run fee, no per-step fee, and no per-contact tier. Strkr Messaging usage bills at a transparent per-message rate separate from the seat. There is no premium automation SKU and no implementation partner requirement to run the engine in production.

Related features

Pair this with...

Workflow Builder Workflow Automation Business Process Automation Process Automation No Code Automation Workflow Management

Try it free. Bring your team next week.

No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.

Start free trial See pricing