Feature · Business Workflow Automation

Business workflow automation built on the Strkr Flow canvas.

A visual flow builder for every business workflow a revenue team runs: lead routing, task assignment, notification cadence, record updates, cross-record syncing, cross-team handoffs. Drag the blocks, wire the ports, dry-run against a sample record, publish. The flow engine is the same primitive that powers approval chains, document generation, and the full BPA library.

Start free trial See pricing

What the Flow canvas is

A visual builder with the primitives revenue teams actually use.

The Flow canvas is where every business workflow in Strkr is built. The canvas carries a defined block library of triggers, conditions, actions, and approval primitives. Blocks drag onto the canvas, ports wire between them, and the resulting flow runs against the live record set. The canvas is the primary interface for sales ops leads building the standard revenue workflows and for the admin team maintaining the long tail of smaller automations.

Trigger blocks

Record events, schedules, inbound webhooks.

Triggers include record events (created, updated, state changed, deleted), scheduled triggers (nightly, hourly, cron pattern), inbound webhooks (external systems fire the flow), form submissions, email events, and manual triggers from the record page. Each trigger exposes a defined payload that downstream blocks reference. A single flow can carry multiple triggers that converge into one path, which handles the "fire on either Closed Won or renewal event" pattern cleanly.

Condition blocks

AND, OR, nested groups, three-deep lookups.

Condition blocks evaluate against the record and any related records three lookups deep. AND and OR compose cleanly, nested groups work as expected, and the preview pane shows which branch a sample record would take before publishing. The engine resolves lookups in a single query rather than through sequential API calls, which keeps the branching fast enough for scheduled triggers running at scale.

Action blocks

Update, create, delete, notify, email, call API.

Actions include record updates (write any field on any object the flow has access to), creates (new records with defined values), deletes (soft deletes with the audit log), notifications (user, team, role), emails (template-rendered or free-text), outbound webhooks, API calls, and task assignments. Each action records its own audit entry so the downstream investigation of "what did this flow do" is a report query rather than a log hunt.

Approval blocks

Pause the flow, route to a human, resume on click.

The approval block pauses the flow at a defined point, routes the pending decision to the configured approver (user, role, or role chain), and resumes down the matching outbound port on approve or reject. SLAs apply per block with auto-escalation to the next tier on breach. The approval block is the single primitive that powers every revenue BPA chain, which keeps the mental model consistent across every flow a team builds.

Wait blocks

Wait for a date, a signal, or a condition to flip.

Wait blocks pause the flow until a defined condition becomes true: an absolute date, a relative delay (seven days after a record event), an inbound webhook signal, or a condition on a record flipping to a value. The pause does not consume execution capacity, which keeps long-running flows (ninety-day renewal motion, thirty-day customer check-in) efficient to run at scale.

Branch blocks

Multi-way branches on a condition expression.

Branch blocks support two-way, three-way, and n-way splits on a condition expression. Each outbound port corresponds to one branch outcome. The pattern replaces the chain of nested if-else blocks that early flow builders needed, which both improves readability and reduces the risk of a mis-wired branch sending a record down the wrong path.

Loop blocks

For-each over a list, bounded by a safety limit.

Loop blocks iterate over a list (deal line items, account contacts, team members) with a configurable per-iteration body. Each loop carries a safety limit on iteration count to prevent runaway flows, and the loop records a summary audit entry at completion. The pattern handles the common "update all deal line items on an approved discount" and "notify every contact on a account" shapes.

End blocks

Clean termination with a defined final state.

End blocks terminate the flow at a defined outcome: Success, Rejected, Cancelled, Expired, Error. The outcome records on the audit trail and informs downstream reporting on flow effectiveness. Flows with explicit end states report cleaner cycle times and clearer failure modes than flows that trail off into undefined termination, which matters when the flow is the source of truth for a compliance review.

The build-time experience

Draft, dry-run, publish, version, iterate.

The build-time experience on the Flow canvas is the single biggest determinant of whether an automation program ships flows at the pace the business needs. The 2026 pattern on Strkr Flow is drag-and-drop with inline validation, Strkr AI assist on the first draft, dry-run mode against sample records before publishing, and version history on every published change. The experience is designed to let a sales ops lead ship a new flow before lunch and iterate on it that afternoon.

Blank-canvas start

Open the canvas, drop a trigger, start wiring.

Every new flow starts with a blank canvas and a trigger block. The sales ops lead names the flow, picks the trigger (record created, state changed, scheduled), and starts dropping blocks. The canvas supports both left-to-right and top-to-bottom layouts. Blocks snap to a grid for readability, and the canvas handles up to several hundred blocks per flow without performance degradation, which covers every real revenue workflow we have seen in production.

Strkr AI first draft

Describe the flow in a sentence, get the first draft.

Strkr AI assist drafts the first version of a flow from a plain-language description: "when a deal reaches Closed Won, create the customer project, assign the implementation lead by segment, generate the kickoff deck, book the kickoff call, send the welcome email." The AI builds the first-pass flow and the sales ops lead refines. The pattern typically cuts build time from an afternoon to under thirty minutes for the first draft.

Inline validation

Red underline on an unwired port or missing field.

The canvas validates as the sales ops lead builds. Unwired required ports show in red. Missing required fields on an action block highlight with a error message. Reference errors (a lookup to a field that no longer exists on the record) surface at build time rather than runtime. The pattern catches the kind of error that previously surfaced only when the first production record ran through the flow at an inconvenient hour.

Dry-run mode

Run the flow against a sample record without side effects.

Dry-run mode executes the flow against a selected sample record and shows what every block would do without actually writing. The dry-run visualizes which branch each condition would take, which approvers would receive requests, which notifications would fire, and which audit log entries would record. The pattern lets the sales ops lead confirm the behavior of a new flow against last quarter's records before any production record sees it.

Draft and published states

Edit the draft, publish when the dry-run passes.

Flows carry a draft state and a published state. Edits land on the draft, dry-runs test the draft, and the publish action moves the draft into production. The pattern lets the sales ops lead iterate on a flow while the published version continues to run, which eliminates the risk of accidentally saving a half-edited flow into production during a long debugging session.

Version history

Every publish records a snapshot and a message.

Every publish records a version snapshot with the publishing user, the timestamp, a required message describing the change, and a diff view against the previous version. The audit trail references the version that ran against each record, which means historical records always resolve against the policy that was in force at the time. The version history is a first-class report accessible to any user with the admin role.

Rollback

One click to revert to a prior version.

Any prior version in the history can be reverted to with a single click. The revert creates a new publish that points back to the earlier flow definition and records the rollback with a required reason message on the audit trail. The pattern handles the "something broke, revert the Monday change" case without a database restore or a replay operation.

Collaboration

Comments on specific blocks, shared edits with locking.

Multiple admins can review and comment on specific blocks on the canvas with inline comment threads. Simultaneous editing uses optimistic locking so a second editor sees a warning rather than silently overwriting the first editor's changes. The pattern replaces the shared Google doc that admin teams previously used to coordinate flow changes and keeps the collaboration tethered to the flow definition rather than to a side doc that drifts.

The runtime experience

Flows that run reliably at scale with the observability built in.

The build-time experience is only half the picture. Once a flow is in production, the runtime experience determines whether the automation program stays trusted or quietly erodes as flows start to misfire without visibility. The 2026 pattern on Strkr Flow is runtime observability built into the canvas, per-flow dashboards, and the audit log stitched to the record timeline so every run is traceable to the record that triggered it.

Per-run audit trail

Every run records every block it visited with timings.

Every flow run records a timeline of every block it visited with per-block timings, per-block outcome, per-block input and output payloads, and per-block errors. The timeline is accessible from the record page and from the flow dashboard, which makes a run investigation a direct lookup rather than a log hunt. The audit trail retains the per-run data per the tenant retention policy with configurable overrides on sensitive flows.

Per-flow dashboard

Runs, errors, cycle times, breach counts.

Each flow carries its own dashboard with runs per day, error rate, median and P90 cycle times, SLA breach counts, and the top failure reasons for the trailing thirty days. The dashboard surfaces the operating health of the flow at a glance and feeds the weekly ops review on which flows need tuning. The pattern replaces the "we think it is working" posture that un-observed flows typically settle into.

Error handling

Retry policy, dead-letter, admin alerting.

Transient errors (API timeout, lookup failure, approver unavailable) trigger the configured retry policy with exponential backoff. Permanent errors route to the dead-letter queue with an admin alert for review. The dead-letter queue is a first-class view in the admin console with the record context, the error reason, the retry history, and a one-click replay once the underlying issue is resolved.

Record-level visibility

The deal page shows which flows ran on it.

The record page carries a Flows tab that shows every flow that has run on the record with the version, the outcome, the elapsed time, and a link to the full run audit. The pattern replaces the "which automation did what to this record" question that previously required a conversation with the ops lead who maintained the flow.

Throttling

Rate limits to protect downstream systems.

High-fanout flows (nightly scheduled triggers against the full account list) support configurable throttling to protect downstream systems. The flow runs within a defined per-minute rate limit, and the audit log captures the throttling events so the ops lead can see whether a scheduled flow completed inside its window or ran long. The pattern handles the "we fired fifty thousand webhooks in one minute" failure mode cleanly.

Pause and resume

Stop a flow in flight without data loss.

Any flow can be paused in flight with the admin console. Pausing stops new runs from starting and lets in-flight runs continue to completion with the current version. Resuming unpauses with new runs starting on the current published version. The pattern handles the "we need to pause the renewal flow for the holiday week" case without a database update or a schema flag.

Capacity and limits

Published limits for every tier, no mystery meters.

The pricing page publishes the limits for every tier: concurrent runs, runs per month, retained audit history, approval chain depth, flow definition count. The limits are generous enough for every revenue BPA pattern we have seen in production and specific enough that procurement knows what they are buying. The pattern replaces the "contact sales for limits" posture that typically hides per-execution pricing surprises.

Open API

Every flow is addressable from the open API.

Every flow is addressable from the open API with endpoints for list, read, run (manual trigger), run status, and audit lookup. Teams building custom tooling or external observability can read the full flow state from the API. The pattern avoids the vendor lock-in where every flow interaction has to go through the vendor UI, which matters more for enterprise prospects than most revenue teams realize at evaluation time.

When to reach for the Flow canvas

What belongs here and what belongs somewhere else.

The Flow canvas is the right tool for a class of automation and the wrong tool for others. Teams that reach for the canvas on every integration or every data-engineering job end up with flows that overlap with other systems and produce confusion about which tool owns which outcome. The clear framing on when to reach for Flow and when to reach for something else saves a lot of operating pain.

Right fit

Record-triggered revenue workflows.

The canvas is the right fit for record-triggered revenue workflows: deal state changes, account updates, contact events, task completions, approval requests, document generation triggers. The record is the source of truth, the trigger fires on a record event, and the actions update records, notify users, and generate artifacts. This is the sweet spot the canvas was built for.

Right fit

Scheduled check-ins and nightly motions.

Scheduled flows that run nightly or weekly against the record set are a strong fit: ninety-day renewal motion, thirty-day customer check-in, weekly forecast reminder, quarterly QBR scheduling. The scheduling primitive is reliable, the audit log tracks the per-record outcome, and the dashboard reports the operating pattern over time.

Right fit

Multi-step cross-team handoffs with approvals.

Cross-team handoffs with human approval steps (sales-to-CS, CS-to-AM, deal desk routing, legal clause review) are the single most-used pattern. The approval primitive, the SLA tracking, the delegation handling, and the audit trail combine into a defensible flow that holds up in a compliance review.

Wrong fit

High-throughput data engineering pipelines.

The canvas is not the right fit for high-throughput data engineering pipelines moving millions of rows per hour between a warehouse, a data lake, and a feature store. That workload belongs on a data engineering platform or iPaaS. The canvas handles the revenue workflow side of the data story (updating CRM records, triggering downstream syncs) rather than the bulk-processing side.

Wrong fit

Real-time event streaming with sub-second latency.

Real-time event streaming with sub-second latency requirements (telemetry pipelines, fraud detection, high-frequency trading) belongs on a dedicated streaming platform. The canvas carries a cycle time measured in seconds to minutes for typical revenue workflows, which is the right latency for the revenue use case but not for sub-second applications.

Wrong fit

Full ERP orchestration across every department.

Enterprise orchestration across procurement, finance, HR, and operations in a ten-thousand-person company belongs on an enterprise BPA platform (Nintex, ProcessMaker, Pega, K2). The Flow canvas is purpose-built for revenue workflows and does not try to replace enterprise orchestration for central IT.

The co-existence pattern

Flow for revenue, enterprise BPA for IT, iPaaS for data.

Mature companies run all three. Flow for revenue workflows, enterprise BPA for central IT orchestration, iPaaS for data engineering integration. The three categories carry their own buyers, their own operating patterns, and their own audit shapes. The co-existence respects what each tool is good at and avoids forcing one tool to cover a workload it was not built for.

The migration story

Zapier and Make flows migrate in a day.

Teams migrating simple trigger-and-fire flows from Zapier or Make typically complete the migration inside a day. The trigger maps, the action maps, and the recipe pattern translates cleanly. What changes is the governance posture: Flow produces the audit trail, the delegation handling, and the SLA tracking that the simpler tools do not, which lets the team retire the shadow-IT workflow and replace it with one that passes a compliance review.

Business workflow automation on every paid tier, with the audit log included.

Trigger, condition, action, approval, wait, branch, loop, and end blocks ship on every paid tier. Strkr AI build-time assist, dry-run mode, version history with rollback, per-flow dashboard, dead-letter queue, and the open API ship on every paid tier. No separate automation module, no per-run meter, no premium builder tier.

Start free trial See pricing

Common questions

What buyers ask about this feature.

How does the Flow canvas compare to Zapier or Make?

Different fit. Zapier and Make excel at trigger-and-fire integrations between consumer and prosumer apps and are strong for small teams gluing together a few SaaS products. The Flow canvas sits inside the CRM with native approval primitives, delegation handling, SLA tracking, and audit evidence shaped for SOC 2 Type II. Teams that have outgrown workflow-only tools for revenue governance typically migrate to the Flow canvas because the simpler tools cannot produce the compliance artifacts their audit cycle requires. The migration from Zapier or Make to Flow typically takes a day for the trigger-and-fire slice and surfaces the governance gaps the simpler tools quietly carried.

Can non-technical users build workflows on the Flow canvas?

Yes. The canvas is a drag-and-drop builder with inline validation, dry-run mode, and Strkr AI assist on the first draft. Sales ops leads, implementation managers, and admin team members build flows without engineering involvement. The limiting factor is almost always policy clarity (naming the triggers and the thresholds) rather than the tool. For teams that already have the policy documented, the first flow typically ships inside the first week of adoption.

What is the audit evidence shape for a typical flow?

Every flow run records a timeline of every block it visited with per-block timings, per-block outcome, per-block input and output payloads, and per-block errors. Every approval decision records the approver, the note, the policy version in effect, the device, and the channel. Every delegation records both the primary approver and the delegate. The log is a first-class report queryable in the standard report builder with saved views auditors sign off on in advance. SOC 2 Type II certification is in progress through 2026-Q4 and the Flow audit evidence is shaped around the control areas Type II reviewers test.

Can we migrate from Salesforce Flow or HubSpot Workflows?

Yes. The migration pattern is specific to each source platform but typically runs in two phases: inventory the current flows and classify them by complexity, and rebuild the flows on the Strkr canvas in priority order (critical revenue governance flows first, long-tail flows second). Teams migrating from Salesforce Flow typically complete the inventory in a week and ship the first critical flow on the Strkr canvas within the first two weeks. The migration surfaces the subset of flows that were only maintained because the previous platform required it, which usually cuts the actual flow count by a meaningful margin.

How does the Flow engine handle long-running flows like a ninety-day renewal motion?

Wait blocks pause the flow until a defined condition becomes true (absolute date, relative delay, inbound signal, record condition flip). The pause does not consume execution capacity, which keeps long-running flows efficient to run at scale. The ninety-day renewal motion fires on the contract signing event, waits until ninety days before contract end, and then fires the renewal chain. The pattern handles tens of thousands of concurrent long-running flows without a per-execution meter affecting the operating cost.

Is this HIPAA compliant for healthcare workflow automation?

Yes. Strkr is HIPAA compliant with a BAA available on request. PHI fields are tagged at the schema level and merge into flows only when the flow is marked for PHI handling. The audit evidence captures the PHI flow so a HIPAA reviewer can trace which flows handled protected data under which safeguards. SOC 2 Type II certification is in progress through 2026-Q4. GDPR and CCPA compliance are already in place.

Related features

Pair this with...

Business Workflow Management Business Process Automation Workflow Automation Automated Workflow Software Cloud Workflow 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