Feature · Workflow Automation System

A workflow automation system that lives inside the system of record.

Strkr Flows is the automation engine behind every revenue process in the suite. Event bus, condition evaluator, DAG runner, atomic action layer, dry-run validator, and a dead-letter queue. One system, one audit log, one bill.

Start free trial See pricing
What a workflow automation system actually is

Not a tool. An engine with runtime guarantees.

A workflow automation system is five things working together: an event bus that catches changes, a condition layer that evaluates logic, a DAG runner that executes actions in the right order, a state layer that keeps everything atomic, and an observability layer that tells you what happened. Any single-piece tool (just the builder, just the actions, just the triggers) is a workflow helper, not a system. Strkr Flows is the full engine, native to the CRM.

Event bus

Every change in every module is an event.

When a deal moves stage, a contact gets updated, a form submits, an email bounces, an SMS lands, a Projects issue transitions, or a scheduled time rolls around, an event lands on the shared bus. Every subscribed Flow reads the same event, which means two Flows that trigger on the same change both run, in isolation, without blocking each other.

Condition evaluator

AND, OR, nested, record-fetching logic.

The condition layer walks the payload, fetches related records when needed, and evaluates arbitrary logical trees. A Flow can branch on territory, deal size, account tier, product mix, time of day, rep workload, or any custom field. Nested conditions are supported up to a reasonable depth; the canvas renders every branch so the shape is legible even for operators who did not build it.

DAG runner

Directed graph, parallelism where it is safe.

Actions execute as a directed acyclic graph. Independent branches run in parallel; dependent branches serialize. A Flow that drafts an email AND creates a Projects issue AND posts to Slack fires all three in parallel because none of them depends on the others. The runner knows the dependencies from the graph shape; the builder makes the graph visually obvious.

Atomic state

Partial failures do not corrupt the record.

Every action that touches a record runs inside a transaction. If the fourth step in a chain fails, the first three roll back cleanly. The classic nightmare where a deal is half-updated and the Slack notification already fired cannot happen here, because the notification is a terminal side-effect ordered after the writes. State transitions are atomic by design, not by hope.

Dead-letter queue

Failed runs land somewhere queryable.

When a Flow fails for a reason it cannot retry (missing credentials, blocked content, schema violation, upstream API down), the run lands in a dead-letter queue with the full trigger payload, the step that failed, and the error class. Admins can replay from the DLQ once the issue is fixed. Nothing fails silently; nothing disappears.

Observability

Per-block metrics, audit log, trace timeline.

Every block in a Flow carries metrics: runs today, success rate, median latency, p95 latency. The audit log captures each run as a trace: trigger payload in, each step's input and output, final record state. The classic question "what happened to that lead on Tuesday" has an answer in two clicks, not a reconstruction from guesses.

Rate limiting

Protects the system from itself.

Per-tenant and per-Flow rate limits prevent a misconfigured loop from flooding the queue. When a limit is hit, subsequent runs queue cleanly rather than failing. Admins see which Flow is hot and can tune its schedule or decompose it into smaller pieces. The runtime stays healthy even when a well-intentioned operator ships a greedy workflow.

The triggers the system catches

Events across every module, not just the CRM.

A workflow automation system that only sees the CRM misses half the revenue work. Strkr Flows subscribes to events across CRM, Marketing, Messaging, Projects, and the Docs module, plus scheduled time and manual fires. The list below is the first-order trigger surface the system exposes to Flow authors.

Record events

Created, updated, deleted, field-changed.

The classic CRUD surface. A Flow can trigger on contact created, deal updated, account deleted, custom-field changed. The field-changed variant is the fine-grained one most teams want: fire only when deal.stage moves to Proposal, not on every deal update.

Stage transitions

The stage-change trigger.

Pipeline work pivots on stage transitions. The trigger catches both the from-stage and the to-stage so a Flow can run for Discovery → Qualified without also running for Discovery → Closed Lost. Stage history is first-class, which keeps the stage-move trigger reliable even when a record is updated by multiple actors in a short window.

Form submission

Marketing form fires an event.

Every marketing form submission writes to the event bus. The payload includes the form fields, the UTM data, the originating page, and any routing hints the form captured. Lead-triage Flows subscribe to this trigger directly without an intermediate layer.

Email events

Reply, bounce, click, unsubscribe.

The native email layer writes inbound replies, bounces, clicks, and unsubscribes to the event bus. A Flow that re-routes based on reply intent sees the inbound event with the parsed thread, not just a notification that mail arrived.

SMS inbound

Strkr Messaging event, native.

Inbound SMS from Strkr Messaging fires an event with the full thread context, the sending number, the keyword match (if any), and the owning rep. SMS flows (opt-in confirmations, auto-replies, consent recording) subscribe directly.

Project transitions

Projects module events, same bus.

When a project issue moves status, a sprint closes, an epic is marked done, or a release ships, the event lands on the same bus as CRM events. A Flow can trigger on a Closed Won deal AND a project-start event with no stitching.

Scheduled time

Cron-style scheduler, tenant-timezone aware.

Flows can run on a schedule in addition to firing on events. Cron syntax for complex cadences, friendly presets for daily/weekly/monthly. Schedule respects tenant timezone, so a 7am Monday report lands at 7am local for every team member regardless of their office.

Webhook inbound

External events, same runtime.

An inbound webhook is a trigger. Any third-party system that posts JSON to a Strkr endpoint can fire a Flow with the payload. The pattern covers systems without a native connector; the runtime treats the event identically to a native one.

The actions the system can execute

Writable surfaces across every module and integration.

Triggers are the easy half; the hard half is the write path. A workflow system is only useful if the actions it supports cover the real work. Strkr's action library spans every writable surface in the product plus every native integration.

CRM actions

Create, update, delete, assign, enroll.

Contact, account, deal, lead, task, note, call, meeting. Each entity exposes create/update/delete plus the entity-specific actions: assign owner, move stage, enroll in cadence, convert lead, mark primary. The surface is the same one the UI uses; permission inheritance is identical.

Marketing actions

Enroll in cadence, update campaign, add to segment.

Enroll a contact in a sequence, remove from a segment, update a campaign-level metric, trigger an email send. The marketing surface is first-class from the Flows side; the triage and nurturing patterns compose directly.

Messaging actions

Send SMS, send MMS, record consent, pause send.

Send-SMS is an action that composes a message from the payload, respects the recipient's consent state, and writes the outbound record to the thread. The action can also record a new consent, revoke an existing one, or pause outbound while a condition holds.

Projects actions

Create issue, transition status, create sprint.

When a Closed Won deal needs a delivery project, the Create Project action spawns one from a template, assigns an owner, and links the deal. Create Issue and Transition Status cover the day-to-day; the integration keeps CRM and project state in sync.

External actions

Salesforce write, Google Workspace, Microsoft 365, Slack.

The native integrations are callable as actions. Write to a Salesforce record, create a Gmail draft, add a Google Calendar event, post to Slack, update an Outlook item. Each action respects the installing user's OAuth scope; what the user cannot do by hand, the Flow cannot do either.

Webhook outbound

POST JSON to any URL.

For systems without a native integration, the outbound webhook action POSTs a configurable JSON payload to any URL. HMAC signing optional. Retries follow the same exponential-backoff pattern as native actions. The custom integration gap closes with one action, not a sidecar service.

AI step

Strkr AI as an in-chain action.

The AI step is itself an action. Takes structured input, calls the model layer, returns structured output. Approved prompts come from the tenant prompt library; PII redaction runs before send. The next step consumes the AI output as if it were any other data source.

The builder that sits on top of the system

A canvas revenue ops can run without an admin certification.

The engine is only as useful as the people who can build on it. Strkr's canvas is designed for a sales ops or revenue ops generalist to configure in an afternoon, not a Salesforce-certified admin billed hourly. The builder exposes the whole engine without requiring the operator to think in DAG terms.

Visual canvas

React Flow + Dagre auto-layout.

Drag trigger, condition, and action blocks onto a canvas. Click Tidy to auto-arrange. Hover a block to duplicate or delete. The canvas renders at scale; a 40-block Flow still reads cleanly because the layout engine respects the graph topology.

Dry-run mode

Validate before you publish.

Pick a sample record, run the Flow in dry mode. The runtime walks every branch, logs the condition evaluation, shows which actions would fire. No records change, no emails send, no SMS leaves the system. The classic "test on a dummy contact and hope" pattern becomes a repeatable validation step.

Version history

Every save is a version; every change diffs.

Save a Flow and the engine snapshots it. The version list shows who changed what, when, and why (if a save note was added). Side-by-side diff shows added blocks, removed blocks, changed conditions. Rollback is one click; the engine resumes from the prior version on the next trigger.

Live preview

See the next trigger before you ship.

The canvas shows the record that would trigger the Flow next (based on the current conditions). Operators see concrete data instead of abstract field names, which catches the "I meant to filter on commit stage not pipeline stage" mistakes before they ship.

Per-block metrics

Each block carries its own stats.

Hover a block, see runs today, success rate, median latency. The hot path is visible without opening a separate metrics tool. When a action is failing, the metrics chip turns red and surfaces the error class.

Templates library

Starter Flows ship as copyable blueprints.

Lead triage, stale-deal nudge, meeting prep, Monday digest, churn escalation, closed-won kickoff, renewal flag. Each template is a working Flow the operator copies, re-wires to their tenant's fields, and publishes. The learning curve shortens dramatically for the first 10 Flows.

What a system means in production

The guarantees you can only get when it is one engine.

The reason this is a system and not a toolbox is that the pieces guarantee each other's behavior. Below are the production-grade behaviors you only get when the trigger layer, the condition layer, the action layer, and the state layer are all one engine.

Atomic transitions

Multi-step chains are one unit of work.

When a Flow writes to three records in sequence, the engine wraps them in a transaction. If the third write fails, the first two roll back. The read path never sees a partial state. Downstream Flows cannot trigger on a half-updated record because the event does not fire until the transaction commits.

Replay from DLQ

Failed runs rerun once the issue is fixed.

A Flow that failed because a Salesforce credential expired lands in the DLQ. Admin rotates the credential, selects the failed runs, hits Replay. Each run resumes from the step that failed with the original payload. The pattern recovers from outages without manual record repair.

Permission inheritance

Flows run as a user, obey the user's access.

A Flow owned by a sales ops lead runs with that lead's permissions. If the owner cannot update a protected field, the Flow cannot either. Admins can elevate a Flow to run as a service account for cases that need broader scope; the elevation is logged separately and visible on the Flow's detail page.

Audit on every call

The log is immutable and queryable.

Every run writes a record: trigger payload, condition evaluation, actions executed, outputs returned, errors raised. The log is append-only, cannot be edited, and is queryable by Flow, user, record, or outcome. SOC 2 Type II and ISO 27001 auditors have the full trail without a special export.

Shared memory

Flows read the same records the UI does.

No separate automation data layer. The runtime reads the same tables the application reads. When an admin changes a field name in Settings, every Flow referencing that field sees the new name on the next run. No separate migration, no stale references.

One bill

No per-run meter, no action-count tier.

The Flows runtime ships on Pro and above with no per-run meter. A team running 5,000 Flow executions per day pays the same per-seat price as a team running 50. The business incentive is to automate aggressively, not to ration runs because the vendor meters them.

What the system replaces

The stack that comes out when Flows comes in.

Mid-market revenue orgs typically assemble automation from four or five vendors: a workflow automation platform, a per-task glue service, a native-CRM workflow add-on, a scheduling tool, and a notification middleware. Each has its own data layer, its own permission model, and its own bill. The native system replaces the stack.

Workato / Tray

Enterprise iPaaS, enterprise price tag.

Workato and Tray are capable, enterprise-grade workflow platforms. Pricing lands in the five-figure to six-figure annual range depending on connectors and recipe count. Powerful; also sized for a 500-person operations team to administer. Most mid-market teams never fully turn them on.

Zapier

Approachable, per-task meter.

Zapier is easy to start with. The friction is the per-task meter: every step costs a task, and complex workflows burn through quota fast. Teams routinely spend USD 500 to 3,000 per month just on Zapier tasks for workflows that would run free inside a native system.

HubSpot workflows

Solid, gated to Enterprise.

HubSpot workflows are capable. The deeper triggers and the AI step live in Enterprise, which doubles the per-seat line versus Pro. For a growing team the jump to unlock the full workflow surface is a line item leadership keeps pushing out.

Salesforce Flow

Powerful, admin-certified.

Salesforce Flow is deep. The friction is the admin layer: anything non-trivial needs a certified admin, and the admin salary alone usually exceeds the full Strkr license. Mid-market teams either over-pay for configuration help or run a stripped-down subset of the feature.

Slack-side middleware

Notification glue that fails silently.

The classic pattern: a middleware service listens for CRM webhooks, formats a Slack message, posts it. Works until the service goes down or the webhook contract changes. Native Flows posts to Slack from the same runtime that wrote the record; the two cannot drift apart.

Strkr Flows

One engine, every surface, no meter.

Native triggers, native actions, native integrations, native AI step, native audit, native carrier for SMS. One permission model, one data layer, one bill. The automation lattice is a product surface, not a glued-on vendor collection.

How teams adopt the system

Week one through month three, the pattern that works.

The teams that get the most out of a workflow automation system follow a shape: enable the obvious patterns in week one, instrument them in week two, extend in week three, audit quarterly. The pattern below is drawn from tenants ranging from a 7-rep agency to a 220-rep enterprise sales org.

Week one

Enable the templates.

Turn on lead triage, stale-deal nudge, meeting prep brief, Monday digest. Four templates, four Flows live by Friday. The RevOps lead configures the territory map, picks the escalation thresholds, points the digest at the right Slack channel. No code, no custom work.

Week two

Instrument and tune.

Open the per-block metrics on each live Flow. Watch which actions fire most, which conditions evaluate true, which steps occasionally fail. Tune the thresholds based on real data instead of guesses. The first-week Flows get 20 to 30 percent more accurate inside a week of instrumentation.

Week three

Extend with team-specific Flows.

The sales team wants a Flow for named-account escalation. The CSM team wants a Flow for health-score drops. The marketing team wants a Flow for high-value content download routing. Each team gets its own Flows under its own owner; the admin layer stays sane because permissions are per-Flow.

Month two

Add AI steps where they earn their keep.

The patterns that benefit from Strkr AI are drafting, classifying, and summarizing. Add an AI step to the lead-triage Flow for first-touch drafting, to the meeting-prep Flow for the one-page brief, to the Monday-digest Flow for the narrative paragraph. The costs stay bounded because the daily budget cap is set.

Month three

Audit and prune.

Open the Flows list sorted by run count. The hot Flows prove their value; the cold ones (fewer than 20 runs per month) are candidates for retirement. Pruning quarterly keeps the Flow list legible and prevents the "we have 400 Flows and nobody knows which fire" problem.

Quarterly

Review the DLQ, roll up the metrics.

Open the dead-letter queue, review the failed runs, replay what still matters, retire what does not. Pull the quarterly automation metrics (runs executed, hours saved, errors recovered) for the business review. The system's value becomes visible as a line in the QBR deck instead of a vague "we automated things" story.

The whole workflow automation system ships on Pro.

DAG engine, 55+ triggers and actions, dry-run, replay, per-block metrics, native integrations, Strkr AI as a step. No per-run meter, no Enterprise paywall, no admin certification required.

Start free trial See pricing
Common questions

What buyers ask about this feature.

What is a workflow automation system?

A workflow automation system is a runtime engine that catches events, evaluates logic, and executes actions in a predictable, auditable way. Strkr Flows is the system behind every revenue process in the suite: an event bus, a condition evaluator, a DAG runner, an atomic state layer, and a dead-letter queue for failures. Every subscribed Flow reads events from the same bus and writes through the same action layer, which is what makes the behavior consistent across modules.

How is a system different from a workflow tool?

A tool is one piece: just a visual builder, just a trigger library, just a notification middleware. A system is the engine behind the tool with runtime guarantees: atomic state, replay from a dead-letter queue, permission inheritance, immutable audit. Strkr Flows is the system, not the tool; the canvas is one surface on top of a runtime that also exposes an API and a Flow template library.

Does Strkr's system have a per-run meter?

No. The Flows runtime ships on Pro and above with no per-run meter. A team running 5,000 Flow executions per day pays the same per-seat price as a team running 50. The business incentive is to automate aggressively, not to ration runs because the vendor meters them. Rate limits exist at the tenant level to protect the runtime, not to tier the bill.

Can the system replace Zapier, Workato, or Tray?

For revenue-adjacent workflows (CRM, marketing, messaging, projects, customer success), yes. The native triggers, native actions, and native integrations cover the patterns a mid-market revenue org runs on an iPaaS today. Teams with workflows that span many non-revenue systems (ERP, finance, HRIS) may keep an iPaaS alongside Strkr for the non-revenue surface and run revenue workflows natively.

What happens when a run fails?

Transient failures (rate limits, timeouts, 5xx) retry with exponential backoff. Hard failures (missing credentials, blocked content, schema violation) land in the dead-letter queue with the full trigger payload and the step that failed. Admins see the failure, fix the issue, and replay from the DLQ. Alerting is configurable so a failed run can route to a Slack channel, an email list, or a webhook to an incident tool.

Does the system need a certified admin to operate?

No. The builder is designed for a sales ops or revenue ops generalist to configure in an afternoon. Triggers are chosen from a dropdown. Conditions are built with form inputs. Actions come from a searchable library. The visual canvas with Tidy auto-layout, dry-run validation, and version history replaces the admin certification requirement that is standard with enterprise automation platforms.

Related features

Pair this with...

Workflow Automation Workflow Management Workflow System Workflow Engine No-Code Automation AI Workflow Automation

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