Automation workflows under every surface, not next to them.
The same engine runs lead routing, deal nudges, invoice sends, project transitions, and renewal flagging. One trigger model, one action library, one audit log. Non-engineers configure the motion in a visual builder with Boolean conditions and the live sandbox tests every branch before publish.
Automation workflows are the engine beneath every workflow surface on the platform. The grammar is simple: a trigger fires on a record event, a condition evaluates against the record state, an action writes back or sends. The same three primitives cover a lead-routing rule, a Monday hygiene sweep, a project status transition, and a customer-success renewal flag. Keeping the grammar simple is what lets a RevOps lead configure forty workflows in a week without a dev handoff. Keeping the engine powerful is what lets those forty workflows run reliably at a million records.
Triggers
Record events across every object.
Lead created, deal updated, contact enriched, email replied, meeting booked, sequence step completed, invoice sent, project transitioned, task completed, note added, custom field changed, scheduled time reached, inbound webhook received. Every record event the platform produces is a candidate trigger, and every custom object gets the same trigger surface the standard objects do.
Conditions
ALL-of and ANY-of across linked records.
Conditions evaluate against any field on the triggering record and any field on linked records up to three hops. ALL-of and ANY-of can nest, and the condition tree supports NOT and date math (within 7 days, more than 30 days ago, in the next quarter). The same grammar that filters a report also filters a workflow, which keeps the mental model tight.
Actions
Write, send, assign, enroll, call out.
Create a record, update fields on the triggering record, update fields on a linked record, assign an owner, create a task, enroll in a sequence, send an email, send an SMS via Strkr Messaging, post to Slack, call an external webhook, run a Strkr AI prompt and write the result back. Actions compose in sequence with optional conditions between steps.
Scheduling
Cron, delay, and tenant-local timing.
Scheduled workflows fire on cron expressions with tenant-timezone handling and DST awareness. Delay steps between actions pause the flow for seconds, minutes, hours, or days. Business-hour-only windows gate send actions to the right time of day so a Monday 2 AM trigger does not land in the prospect inbox at 2 AM.
Error handling
Retry, fallback, dead letter.
Every action has a retry policy, a timeout, and a dead-letter queue for inspection. Failed webhook actions retry with exponential backoff. Updates that violate validation rules write to the dead letter with the full payload so the ops lead can replay after the fix. The engine never silently swallows a failure.
Audit log
Every run, every edit, every click.
Every workflow run writes an audit record with the trigger payload, the condition evaluation, the action results, and the user that configured the version. Every edit to the workflow itself writes a diff against the prior version. The audit trail satisfies SOC 2 Type II (in progress 2026-Q4) activity logging and HIPAA access tracking for teams on the BAA.
Testing
Sandbox against sample records.
Before publish, the builder runs the workflow against a sample record (or a saved set of sample records) and shows the trigger evaluation, the condition result, and the simulated action output. The ops lead catches misroutes and missing conditions before the first live run instead of after the first bad email lands in a prospect inbox.
Versioning
Draft, publish, roll back.
Workflows have draft and published states. A new edit creates a draft that can be tested in sandbox and published when ready. Every published version is retained, and a bad publish can be rolled back to the prior version in one click. The ops lead who shipped a broken condition at 4 PM Friday can roll back in five seconds.
Permissions
Who can edit, who can observe.
Workflow edit permissions scope by object, by workflow, or by workspace. A RevOps lead can edit sales workflows while the customer success manager can only edit CS workflows. The audit log scopes to the same permission model so an exec can observe every workflow without accidentally editing one.
How Strkr runs automation workflows
One engine, every surface.
Most platforms ship separate workflow engines for sales, marketing, and operations. Strkr runs one engine with one builder, one audit log, and one permission model. The surface below is where that lands in practice. The RevOps lead who learned the sales workflow builder on day one is already fluent in the marketing workflow builder, the project workflow builder, and the custom-object workflow builder. One mental model, four jobs, zero re-training on new tabs.
Sales workflows
Routing, sequences, nudges, hygiene.
Lead-to-SDR routing, inbound SLA timers, outbound sequence enrollment, deal-aging nudges, pipeline hygiene sweeps, close-date slippage flags, and manager one-on-one prep. Every sales workflow runs on the same engine as every other workflow, so the audit log and the version history work the same way across all of them.
Marketing workflows
Nurture, scoring, enrollment, suppression.
Email nurtures on marketing contacts, lead-score updates on behavioral signal, campaign enrollment on segment match, suppression on sales-active opportunity, re-entry on Closed Lost. The marketing workflow builder is the same builder as the sales builder with a different starter template set.
Project workflows
Status transitions, SLA timers, handoffs.
Issue status transitions, sprint handoffs, release gate checks, SLA timers on customer-facing projects, and automatic Slack notifications on blocker-raised events. Project workflows read from the same record model as sales and marketing workflows, so an escalation on a project can route to the CRM owner inline.
Document workflows
Review cycles, approval, send-to-sign.
Document review cycles, approval chains, redline rounds, and send-to-sign through DocuSign or PandaDoc. Document workflows fire on upload, revision, approval, and completion events. Native Strkr Docs covers the wiki surface. For contracts and e-signature, the workflow passes to the integration partner.
Operations workflows
Any custom object, any schedule.
Custom objects (orders, subscriptions, services, inspections, whatever the business runs on) get the same trigger surface as standard objects. A monthly billing workflow, a quarterly compliance check, a daily inventory reconciliation run on the same engine with the same visual grammar. The ops lead who built the sales workflows builds the ops workflows the same way.
Integration workflows
Webhooks in, webhooks out, API in both directions.
Inbound webhooks fire a trigger with the payload available in conditions and actions. Outbound webhook actions call any external system with templated bodies and header auth. The platform plays the role Zapier does in a Zapier-powered stack, except the trigger is on the actual record not on a Zap read from the record.
AI workflows
Strkr AI as an action step.
A workflow step can prompt Strkr AI (summarize this call transcript, extract the next step from this email, score this account on ICP fit) and write the result back to a field. The prompt library ships with starter prompts, and prompts can be scoped per team. The LLM provider is the Strkr backend, not the user-facing brand.
Metrics
Run count, success rate, latency per workflow.
Every workflow has a metrics tab showing run count, success rate, action latency, and error distribution over the last 24 hours, 7 days, and 30 days. The ops lead investigating a flaky workflow sees the pattern in two clicks instead of grepping log files.
What a Zapier-style stack costs
Why a middleware tax does not scale.
A workflow stack built on Zapier (or Make, or Workato, or any middleware tier) imposes a tax that compounds as the motion matures. The pattern below is the shape of the tax, drawn from switchover engagements where the ops lead measured the cost of running the middleware versus owning the engine inside the platform. Strkr is a software company and every integration ships as first-class native code with webhooks, APIs, and KMS-encrypted credential storage. We mention the middleware pattern because buyers are usually comparing against it, not because we recommend it.
Per-run metering
The bill scales with activity.
Zapier charges per Zap run. Make charges per operation. The more successful the motion, the more expensive the stack. A workflow that runs on every lead becomes a line item that grows with lead volume, which creates a direct financial penalty for growing the top of funnel. Strkr runs workflows on the per-seat license without per-run metering below the plan cap.
Round-trip latency
Trigger fires, Zapier polls, action lands.
A middleware Zap polls the trigger source on an interval (one minute on paid, five on free, longer on starter), executes the step chain, and calls the destination API. Round-trip latency ranges from seconds to minutes. A native workflow runs inside the same database transaction as the trigger event, with latency in low tens of milliseconds.
Credential sprawl
Secrets in a middleware vendor you did not scope.
Every integration a middleware Zap uses stores credentials with the middleware vendor. The compliance team now has a vendor relationship with Zapier plus every integration vendor. On a SOC 2 Type II (in progress 2026-Q4) scope, each additional vendor is a questionnaire, a DPA, and a risk assessment.
Error visibility
The failed step lives in a tab you forget.
When a middleware step fails, the error lands in the middleware console. Ops teams who do not check the middleware console daily miss failures that corrupt downstream data. Native workflows log every error on the record audit log, where the ops lead already looks.
Version drift
The Zap diverges from the CRM reality.
A Zap built on a field set keeps the field set hard-coded. When the CRM schema changes (new field, renamed field, type change), the Zap breaks. Native workflows watch the schema automatically because the engine and the schema live in the same system.
Hard scaling cliffs
Middleware tiers do not match growth.
Middleware tiers have run-count caps and task-count caps that trip when the motion scales. The upgrade conversation lands at renewal with a 2x or 3x price step. Native workflows run on the plan tier the team is already on, which keeps the renewal conversation inside the main contract.
Three automation workflows live inside two weeks
What a RevOps lead ships on day one.
The playbooks below are the shape of the workflow set most Strkr customers stand up in the first two weeks. Each one lives on the same engine, uses the same visual builder, and reads from the same records. The configuration time for all three combined is one afternoon for a RevOps lead who already knows the current motion. The pattern repeats across customers because the three jobs cover 80 percent of the daily operational tax a growing team pays.
Lead routing
Fifteen rules in one tree.
Route by segment, times territory, times SDR workload, times named-account book, times tier. All conditions live in one rule tree with ALL-of and ANY-of nesting. The ops lead publishes once, tests against sample leads, and the entire routing motion runs on one workflow instead of a scattering of filter rules.
Deal hygiene sweep
Monday 7 AM, pipeline cleaned.
Scheduled workflow fires every Monday at 7 AM tenant time. For every open deal, evaluate aging threshold per stage, close-date validity, amount presence on late-stage, Next Step staleness, and commit tier without decision date. Flag the record, task the owner, tag on the forecast prep page.
Renewal pre-flight
Six-month pre-renewal motion runs itself.
Six months before renewal date, book a success check-in automatically. Three months out, open a success task on the CSM with usage trends attached. One month out, re-open the deal for the AE with renewal brief, usage, support history, and expansion signals. Three workflows chained on a single date-math trigger.
Inbound SLA timer
Hot inbound answered inside an hour.
When a tier-A lead is created, start an SLA timer. If no first-touch activity in 60 minutes, escalate to the SDR manager with a Slack ping. If still no touch at 90 minutes, re-route to a backup SDR. The timer runs on scheduled branches so the escalation only fires when the activity is actually missing.
Automation workflows on every paid tier. Any trigger, any action, no middleware tax.
The workflow engine, the visual builder, the audit log, and the sandbox ship on every paid tier. Starter runs the standard trigger and action set at low volume. Pro lifts the run cap and unlocks AI action steps. Scale and Enterprise unlock custom webhook signing and advanced permission scoping. No per-run metering below the plan cap.
What is the difference between automation workflows and sales automation?
Automation workflows are the engine. Sales automation is the opinionated set of pre-built workflows and surfaces that cover the sales team day on top of that engine. Workflows run on any record event with any action. Sales automation covers the jobs a sales team runs every day. In Strkr the two share one engine, one activity graph, and one permission model. You can run the pre-built sales automation surfaces as-is, extend them with custom workflows, or build net-new revenue motions on top of the primitives. Most RevOps leads run the pre-built set in week one and add custom workflows as the motion matures.
Do I need engineering to build automation workflows in Strkr?
No. The workflow builder is a visual, no-code surface. Triggers, conditions, and actions compose in a drag-and-drop canvas. Conditions use ALL-of and ANY-of grammar with date math and nested Boolean logic. Actions pick from a library of pre-built steps. For custom logic that goes beyond the action library, outbound webhook actions call any external system, which keeps the escape hatch open without pushing the whole engine onto an engineering team. Most RevOps leads ship their first ten workflows in the first two weeks of go-live without an engineering ticket.
How do automation workflows handle errors?
Every action has a configurable retry policy with exponential backoff, a timeout, and a dead-letter queue. Failed webhook actions retry on a schedule. Updates that violate validation rules write to the dead letter with the full payload so the ops lead can inspect and replay after the fix. The engine never silently swallows a failure. Every error writes to the workflow audit log with the trigger payload, the condition evaluation, and the action that failed, so troubleshooting takes seconds instead of grepping log files or digging through a middleware console.
Can I test a workflow before publishing it live?
Yes. The sandbox mode runs the workflow against a sample record (or a saved set of sample records) and shows the trigger evaluation, the condition result, and the simulated action output. For destructive actions, sandbox shows what would have been written instead of actually writing. The ops lead catches misroutes, missing conditions, and bad field references before publish, which prevents the Friday-afternoon-broken-workflow scenario that drives most middleware regret.
How does Strkr compare to Zapier, Make, or Workato for workflow automation?
Zapier and Make are general-purpose middleware tiers. They sit between the systems and translate events across tools. Workato is the enterprise-tier equivalent. Strkr runs workflows inside the system of record, which eliminates the round-trip latency, the per-run metering, and the credential-sprawl problems. For integrations between Strkr and external systems, Strkr ships native connectors for the common targets (Google, Microsoft, Slack, Stripe, DocuSign, PandaDoc) and outbound webhook actions cover the long tail. We never recommend a middleware tier for jobs that can live inside the platform.
Is there a limit on how many workflows I can run?
Workflow count and run volume are plan-tier gated. Starter supports the standard set at low volume. Pro lifts the run cap and unlocks AI action steps. Scale and Enterprise are effectively unmetered for typical mid-market usage. Teams with workflow volume that approaches a middleware-tier scale usually consolidate onto Strkr for the per-seat line, which lands below the per-run cost of running the same jobs in Zapier or Make at steady state.
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.
