A visual canvas, a sandbox, a published flow by lunch.
The flow builder covers the three primitives any ops lead needs: a record-event trigger, a nested condition tree, and an action library that composes in sequence. Configure a flow in the morning, test it against sample records at the sandbox, publish the first live run before standup ends.
Strkr Flow has three primitives. A trigger listens for a record event. A condition tree evaluates against the record state and linked records. An action library writes back, sends a message, enrolls a sequence, or calls an external endpoint. Every flow is some combination of those three primitives. The restraint keeps the mental model learnable in an afternoon.
Trigger
Record events on every object.
Any record event qualifies: lead created, contact enriched, deal moved to stage, email replied, meeting booked, invoice sent, task completed, note added, custom field changed, inbound webhook, scheduled cron, record idle for N days. Custom objects get the same trigger surface as the standard ones. One builder covers every object; nothing is gated behind a "pro automations" tier.
Condition
Nested ALL and ANY across three hops.
Conditions evaluate the triggering record and any linked record up to three hops out. Group ALL and ANY nodes nest arbitrarily, with NOT as a modifier. Date math is first-class: within N days, more than N days ago, in the next quarter. The same syntax powers report filters, which keeps a RevOps lead in one mental model instead of two.
Action
Forty-plus actions compose in sequence.
Create a record, update fields, assign an owner, create a task, enroll in a sequence, send email, send SMS via Strkr Messaging, post to Slack, call a webhook, run a Strkr AI prompt and write the output back. Actions chain, with optional per-step conditions. A branching path like "if deal size over $50k, route to AE manager, else to pool" is one condition node between two actions.
Delay
Pause the chain for seconds to days.
Delay steps pause a flow for a configured interval. A nurture flow sends a follow-up two days after the first touch; a sales cadence waits five business days before escalation. Delay respects business hours and tenant timezone, so a Monday 2 AM evaluation never fires a send action in the middle of a prospect night.
Branches
If-else nodes split the path cleanly.
A branch node evaluates a condition and splits execution. Each branch runs independently, with its own action chain. The canvas shows branches as parallel lanes, so the ops lead reads the flow visually instead of staring at an indented JSON config. Branches rejoin or terminate at their own ends; no forced convergence.
Human-in-loop
Approval and task steps pause for a human.
A flow can pause on an approval step and wait for a tap from a configured approver. It can create a task and wait for completion. The pause state is observable; the ops lead sees exactly which flows wait on which humans. Resumed flows pick up at the next step without replaying the earlier side effects.
Loop
Iterate over linked records.
An iterate node loops over the linked records on the triggering record: all contacts on the account, all opportunities on the account, all tasks on the deal. The iteration runs the inner block per record. Common pattern: on account tier upgrade, iterate every open opportunity and update the discount flag. One flow handles the fan-out.
Terminate
Exit conditions stop a flow mid-run.
A terminate node ends the current run with a specified reason that writes to the audit log. Classic use: inside a nurture flow, terminate if the lead reaches Sales Qualified so the nurture does not keep sending while the AE is on the account. The exit reason surfaces on the run history, which keeps retrospectives short.
How the builder feels
A canvas you drag, not a spreadsheet you squint at.
Flow configuration lives on a canvas with draggable nodes, inline validation, and a sandbox panel that runs the flow against sample records before publish. The builder is designed for the ops lead who thinks in diagrams, not the engineer who thinks in YAML. Both camps land on the same engine, but the surface fits the operator.
Canvas
Pan, zoom, snap-to-grid.
Nodes snap to a 12px grid and auto-layout cleans spaghetti after a messy drag session. Mini-map in the corner shows the full flow at a glance. Keyboard shortcuts cover duplicate (cmd-D), group-select (shift-drag), and quick-add-node (slash). The canvas scales to flows with 60 nodes without losing legibility.
Inline validation
Red underlines on broken references.
A node that references a missing field, an unlinked record, or an undefined variable surfaces a red underline on save. The ops lead sees the error at the moment of edit, not at publish time. Classic save-time check: email send action with a template that references {{contact.phone}} but the contact object has no phone field. Validator catches it; the flow refuses to save until fixed.
Sandbox
Dry-run against sample records.
The sandbox panel runs the flow against a sample record (or a saved set of sample records) and shows the trigger evaluation, every condition result, and the simulated action output. Destructive actions display what would have been written instead of writing. The ops lead confirms the shape works before any real record moves.
Live preview
Hover a condition to see current matches.
Hover a condition node and the panel shows how many live records currently match. A rule like "deal amount over $50k and stage after Discovery and owner on West team" surfaces its match count instantly. The preview catches overly-tight rules before publish, when the fix is quick instead of after the first week of zero matches.
Diff view
See what changed between versions.
Every save creates a version. The diff view compares any two versions side-by-side with highlighted additions, removals, and modified node properties. Classic use: a Monday change broke a Friday pattern; the diff shows the condition node that moved from ANY to ALL and the fix is a one-click revert.
Templates gallery
Start from a working shape, not a blank canvas.
A gallery of pre-built flow templates covers the common motions: inbound lead routing, Monday hygiene sweep, project transition, renewal flagging, invoice send, Slack new-deal alert. The ops lead starts from a working shape, swaps triggers and fields, and ships. The gallery entries are editable and support tenant forks.
Reliability without a middleware tier
Retry, dead-letter, replay, and audit, in the engine.
Teams that glue tools with Zapier or Make inherit a middleware operations problem. A failed step surfaces in a dashboard the operator never opens. A rate-limited webhook silently drops a day of events. Strkr runs flows inside the system of record. The reliability primitives sit alongside the record, not inside a separate console.
Retry
Exponential backoff with max attempts.
Every action supports a retry policy with exponential backoff and a configurable max attempt count. External webhook actions default to five attempts over fifteen minutes. Internal actions default to three attempts over sixty seconds. The policy is per-action, so a chatty Slack post uses a tighter policy than a slow HubSpot write-back.
Dead letter
Failed runs land in a queue, not the void.
After the retry budget exhausts, the run writes to the dead-letter queue with the full trigger payload, the condition evaluation, every action step attempted, and the final failure reason. The ops lead inspects, fixes the root cause (bad field, dropped integration token, invalid webhook target), and bulk-replays the queue.
Replay
Reprocess individual runs or whole batches.
Any historical run (success or failure) replays from the audit log. Common use: a template field renamed broke 240 flow runs across two days. Rename the field back or add a shim, then replay the 240. The engine re-runs with the original payload against the current record state. Idempotency keys prevent double-writes on actions already completed.
Audit log
Every run writes a tamper-evident record.
Each run writes an audit entry with trigger payload, condition evaluation, every action attempted, result, duration, and the version of the flow that fired. The chain is tamper-evident with hash linking across entries. SOC 2 Type II (in progress 2026-Q4) activity logging reads this ledger; HIPAA access tracking lands here too for teams on the BAA.
Idempotency
Side effects never double-fire on replay.
External action calls carry an idempotency key derived from the run id and step index. A replayed step with a key the receiver has already seen is a no-op on the receiver side (for connectors that respect idempotency keys) and skipped internally. The engine does the hard part of exactly-once semantics so the ops lead does not reason about it.
Rate limits
Per-connector throttle respects target quotas.
Each external connector carries a per-tenant rate limit matched to the target vendor quota. A Google Workspace write-back respects the per-domain quota; a Slack post respects the workspace rate budget. The engine queues at the connector edge; the flow never sees a 429 bounce as a failure, only as a slightly later execution.
Why not a middleware tier
Flows inside the record cost less and break less.
Middleware tiers like Zapier, Make, and Workato exist because the systems of record historically did not run native automation. Strkr Flow sits inside the record. The cost model, the reliability model, and the credential model all improve as a result. The comparison below sticks to specifics.
Cost shape
Per-seat flat beats per-run metering.
Middleware tiers meter per run or per task. At twelve thousand runs a month across a mid-market team, the per-run bill lands somewhere between $600 and $1,800. The same twelve thousand runs on Strkr are the same per-seat subscription, no run-count line, no step-count math. A team running at steady state saves the metered bill.
Credential sprawl
One tenant OAuth, not twelve zap-level tokens.
Middleware zaps hold their own OAuth tokens per connection. A dozen zaps against Google Workspace means a dozen separate tokens. Strkr Flow uses the tenant-level connector OAuth. One Google token, one Slack bot, one DocuSign auth. Rotating a credential is one place, not twelve.
Dead-letter visibility
Failures surface on the record.
A middleware failure surfaces inside the middleware dashboard. The operator who notices might be the one who built the zap months ago, if they still work there. A Strkr Flow failure surfaces on the record (deal timeline, task on the owner) and inside the workflow audit log the ops lead opens on Monday. Failures stop silent.
Latency
In-process beats cross-vendor round trip.
A middleware zap listens for an outbound webhook from the source system, routes through the middleware queue, and writes to the destination system. Round-trip latency for a hot path lands around four to twelve seconds in good conditions. Strkr Flow runs inside the record, so a condition-eval-write cycle completes in under eight hundred milliseconds median.
Still a place for middleware
Three systems with no first-party fit.
If a team must sync a niche vertical system that has no outbound webhook and no inbound API, a middleware zap still fits. Strkr does not pretend to cover every tool. The guidance is: run flows inside Strkr for Strkr record events; glue external systems with native OAuth plus webhook; reach for middleware only when neither works.
Open API
Vertical integrations ship as code.
The platform documents the trigger surface, the action library contract, and the webhook delivery schema. A vertical SaaS integration ships as native code with webhooks and REST; no middleware tier in the path. Strkr publishes an SDK plus OpenAPI 3.1 spec, and the integration partners build inside the record, not outside.
Playbooks and shipped flows
Five flows a RevOps lead ships in week one.
Five flows cover eighty percent of the operational automation that mid-market teams need. The teams that get fastest value configure these five in the first week, then expand into the vertical-specific motions. Each one lists the trigger, the condition shape, and the measured impact across the sample of nineteen RevOps teams on the engine.
Playbook one
Inbound lead to assigned AE.
Trigger: lead created. Condition: company employee count over 50 and country in {US, CA, UK, AU}. Action: assign to AE pool via round-robin, create first-touch task, send Slack ping. Median time from form submit to AE assignment dropped from 11 hours (manual) to 42 seconds (automated) across the sample. Hands-free, fair, auditable.
Playbook two
Monday pipeline hygiene sweep.
Trigger: scheduled Monday 7 AM tenant-local. Action: iterate open opportunities, condition on last-activity-older-than-14-days, create review task on owner, notify manager if the owner has 10-plus idle deals. Clean pipelines before standup starts. Managers see the Monday sweep output on their 1:1 dashboard.
Playbook three
Deal transition to Closed Won.
Trigger: opportunity stage changed to Closed Won. Action: create onboarding project, notify success manager on Slack, generate the counter-signed PDF filing task, send the customer welcome kit via sequence. The transition that used to require eleven manual steps is one state change; the flow fans out the rest.
Playbook four
Renewal risk flagging.
Trigger: scheduled daily. Action: iterate accounts with renewal within 60 days, condition on health-score decline or executive-sponsor departure, flag the account on the CSM dashboard, create a risk-review task. Three customers caught churn risks sixty days earlier using this flow than they used to catch them through quarterly reviews.
Playbook five
Form-to-sequence enrollment.
Trigger: inbound webhook from the website form. Action: upsert the contact, enroll in the matching nurture sequence based on form topic, create the account record if missing, run the ICP scoring prompt via Strkr AI and write the score back. One flow replaces three manual steps per inbound.
See a flow configured, sandboxed, and published in under three minutes.
A live walkthrough from blank canvas to running flow against sample records. Bring your use case; we will build it on screen.
How many flows can one tenant have running at once?
Flow count and total monthly run volume are plan-tier gated. Starter supports the standard set at low volume suitable for a small team. Pro lifts the run cap and unlocks Strkr AI action steps. Scale and Enterprise are effectively unmetered for mid-market usage. Teams that approach a middleware-tier run volume typically consolidate onto Strkr Flow for the per-seat line, which lands below the per-run cost of running the same jobs on Zapier or Make at steady state. Specific limits are in the pricing page; a sales conversation covers edge cases.
Does the sandbox actually prevent damage to live records?
Yes. Sandbox mode runs the flow against a sample record and shows what would have been written on every action, without writing. Destructive actions like deletes, mass updates, and external webhook calls display their intended effect. The sandbox never hits an external system; webhook calls display the payload that would have been sent. This separation is what makes publish safe; the ops lead sees the full effect before the first live run.
What happens if a flow has a condition that references a deleted field?
Save-time validation surfaces the broken reference as a red underline on the node. The flow refuses to save until fixed. For flows that were published before a field deletion (which is rare because the admin surface warns about dependencies), the next run writes a dead-letter entry with the error. Replay after a fix picks up where the run failed. The system fails loud, not silent, on reference breaks.
Can we invoke a flow from a button or an external call?
Yes. Flows accept inbound-webhook triggers (anyone with the signed URL can POST a payload), scheduled-cron triggers (fire on a configured schedule), and manual-button triggers that render as a button on the record detail page. A rep taps the button; the flow runs against the record. Permissions on the button follow the standard permission system; the rep sees the button only if they have the configured permission.
How does flow authoring relate to the admin permission matrix?
Flow authoring is permission-gated. The create and edit permissions on the Flow object live in the standard permission matrix; admins grant them per role or per user. A rep without edit permission cannot modify a flow but can still execute flows via manual button triggers (if granted). The audit log captures the user that saved each version, so retrospectives find the author of a problematic change in seconds.
How is this different from CRM-native automation on tools like HubSpot or Salesforce?
HubSpot Workflows and Salesforce Flow are both reasonable native engines on their respective platforms. The differentiator for Strkr Flow is that the engine covers every surface (CRM, Marketing, Projects, Docs, Messaging) with one grammar and one audit log. Teams on HubSpot plus Asana plus DocuSign run three disjoint automation surfaces; teams on Strkr run one. The savings compound as the team adds surfaces. The migration path uses the standard CSV plus field-mapping flow and we provide a Salesforce migration shortcut for teams moving over.
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.
We use cookies.
Essential cookies keep the site working. If you accept, we also enable Google Analytics
so we can see which pages help and which don't. Reject to opt out entirely. Details in our
Privacy Policy.
