Feature · Process Automation

Process automation that lives inside your system of record.

Process automation is the umbrella. Workflow automation, sales automation, and business process automation are the layers underneath. Strkr runs all three on the same engine, with one activity graph, one owner model, one audit trail, and one per-seat price. This page is the orientation layer. Pick the sibling that matches the job you are automating today, and come back here when the next job spans a different layer.

Start free trial See pricing
What process automation actually is

The umbrella term, and the four layers underneath it.

Process automation is one of the most abused phrases in enterprise software. Every vendor from the hyperscaler orchestration platform to the point-tool email sequencer claims to do it, and the overlap of what they mean rarely reaches 50 percent. For a revenue or operations leader standing up a stack, the first job is to name the layers underneath the umbrella so the buying motion lines up with the actual problem. Process automation is a category of categories. Underneath it sit four distinct disciplines, each with its own buyer, cadence, trigger surface, and audit model. Pick the wrong layer for the job and you will overpay for a decade, under-pay for a quarter, or ship a solution that works until the first corner case hits. The six cards below name the layers and the one or two sentences that separate them.

The umbrella

Process automation is the category of categories.

Any time a human-defined sequence of steps runs without a human doing each step manually, it is process automation. The term covers everything from a one-click lead routing rule to a 50-step pharma manufacturing release workflow. The umbrella is useful for search, SEO, and vendor positioning. The umbrella is useless for buying decisions because the layers underneath it have different buyers, different budgets, and different implementation footprints. Read the layers below before you talk to any vendor who claims to do all of them equally well.

Layer one

Workflow automation: the generic engine.

Workflow automation is the primitive. Any-record-event triggers plus any-record-write actions, with conditions, branches, and schedule-based firing. If something happens to a record, do this other thing. Lead routing, deal nudging, field hygiene, and renewal flagging are all workflow automation. The engine is category-agnostic. The opinionated surfaces that ship on top of it are what turn a lathe into a kitchen cabinet.

Layer two

Sales automation: the revenue-rep day.

Sales automation is a specific application of the engine aimed at the SDR, AE, and sales manager day. Lead capture, qualification, routing, outbound sequencing, email and call tracking, meeting booking, deal updates, task creation, deal nudging, pipeline hygiene, and forecast roll-up. It is a pre-built set of flows plus a few dedicated surfaces (sequence editor, scheduler, lead inbox) layered on top of the generic engine.

Layer three

Business process automation: approvals and cross-team handoffs.

BPA is the discipline of multi-step processes that cross team boundaries, require human approvals, and need audit trails that an external reviewer can defend. Deal approvals, discount chains, contract routing, customer onboarding, QBR scheduling, renewal motions, and partner handoffs. Approval blocks, deadline escalations, delegation during PTO, and policy-version pinning are the differentiators from plain workflow.

Layer four

Robotic process automation: the UI mimic.

RPA automates work by driving a user interface the way a human would. Login to a legacy system, click a button, fill a field, scrape a result. UiPath, Automation Anywhere, and Blue Prism are the dominant platforms. RPA is the right fit when the underlying system has no API, which usually means legacy ERP, bank portals, government filings, and screen-only vendor consoles. For CRM-centric work with real APIs underneath, RPA is almost never the answer.

Where buyers get confused

Vendors sell layer boundaries that favor their SKU.

A sales engagement vendor will tell you sales automation is the umbrella and workflow is a feature. A BPA platform vendor will tell you BPA is the umbrella and everything else is a plugin. An RPA vendor will tell you intelligent automation subsumes it all. The honest framing is that process automation is the umbrella and the four layers are peers. Each has a real use case. Pick the layer, then pick the vendor, in that order.

The pick-the-right-layer flowchart

Which process automation page do you actually need?

The four layers are peers but your current project is not. Right now, today, you are automating one specific thing. The cards below map the most common revenue and operations use cases to the layer that fits, with a link to the sibling page that covers that layer in depth. Read the card that matches your job. Click through to the sibling. Come back when the next job lives on a different layer. This page is the orientation. The siblings are the depth. Together they cover the full process automation surface without the duplication a single 15,000-word page would carry.

If you are automating

Lead routing or any record-event rule → Workflow Automation.

Form fill creates a lead, routing rule picks the owner, task fires, Slack ping lands. Deal moves to Qualified, Slack ping to the AE. Deal rots past threshold, flag it. If the pattern is "record changes, system reacts," you want the generic workflow engine. The /features/workflow-automation sibling covers the visual builder, the DAG engine, dry-run, atomic state, cascade guards, and failure replay. It is the foundation layer. Everything else here sits on top of it.

If you are automating

Outbound sequences or the SDR/AE day → Sales Automation.

Multi-step email cadences with LinkedIn tasks and call reminders. Meeting scheduler pages for inbound booking. Reply detection that pauses the sequence. Pipeline hygiene rules that stop deals from rotting. If the pattern is "revenue rep touches it every day," you want the sales automation surface. The /features/sales-automation sibling covers the nine jobs sales automation should cover, the Strkr pattern for each, and the bolt-on tax that comes with running sequences outside the CRM.

If you are automating

Approvals, discount chains, contract routing → Business Process Automation.

Discount over 20 percent routes to the VP. Non-standard contract clauses go to legal. New customer kickoff fires the full onboarding sequence. SOC 2 audit asks who approved which deal and when. If the pattern is "cross-team process with human approvals and an audit trail," you want BPA. The /features/business-process-automation sibling covers approval blocks, delegation, deadline escalation, policy version pinning, and the Nintex-vs-Strkr fit question.

If you are automating

Low-code or no-code builds for the whole team → No-Code Automation.

Your ops lead is non-technical, your sales ops team does not have an engineer, your admin budget cannot support a certified consultant. The visual builder, the plain-English condition editor, the template library, and the dry-run mode have to carry the full load. The /features/no-code-automation sibling covers how Strkr's no-code surface compares to Zapier, Make, Workato, Tray, and the per-run meter model those platforms share.

If you are automating

The full builder surface, custom logic, loops → Flows.

Compute blocks, custom objects, loops, A/B variant tests, approval branches, outbound webhooks, inbound HTTP triggers, scheduled runs with per-tenant timezone handling, failure replay with record context intact. The /features/flows sibling is the deep builder documentation for the engine that powers every other layer on this list. Read it when you want the technical surface rather than the opinionated use-case framing.

If you are automating

A UI-only legacy system with no API → RPA (not Strkr).

Honest answer. Strkr does not do UI-level screen scraping, keystroke mimicry, or legacy system driver automation. If your use case is logging into an old ERP, pulling a report, and keystroke-copying it into a bank portal, you want UiPath, Automation Anywhere, or Blue Prism. For CRM-centric work with modern APIs, RPA is slow, brittle, and expensive. For legacy UI automation, RPA is often the only option and Strkr is the wrong fit.

How Strkr handles each layer

One engine, three surfaces, zero middleware.

The reason Strkr runs all three revenue-adjacent layers of process automation on the same engine is architectural. Workflow, sales, and BPA share the same primitives: triggers, conditions, actions, approvals, waits, loops, and schedules. When those primitives live in one engine with one activity graph and one permission model, the layers compose cleanly. A sales sequence can pause for a BPA approval, which can route to a workflow that creates a task, which can trigger a notification, which can resume the sequence. Three layers, one trace, one audit log, one per-seat price. The alternative is three products from three vendors with three activity logs that reconcile nightly if the sync holds. The cards below walk through what each layer looks like inside Strkr.

The shared engine

Trigger, condition, action, approval, wait, loop, schedule.

Every process automation surface in Strkr compiles to the same DAG executor. The visual canvas, the sequence editor, and the approval chain builder are three UIs over the same primitive set. The engine handles atomic state (step 4 fails, steps 1 through 3 roll back), cascade guards (depth capped at 10), per-tenant timezone handling, dry-run against real records, and dead-letter queue for failed runs. Change the UI, keep the engine. The depth under each layer is the same depth.

Workflow layer

The visual canvas with 55+ triggers and actions.

Workflow automation is the surface most RevOps leads start with. Drag a trigger (record_created, record_updated, stage_changed, email_replied, schedule, manual, webhook_received) onto the canvas. Drag conditions and actions. Branch on AND/OR logic. Walk lookup fields three deep in one query. Click Test Run before you publish. Click Tidy to auto-layout. The depth is in /features/workflow-automation; the pattern is the same canvas every other layer uses.

Sales layer

The sequence editor plus the opinionated playbooks.

Sales automation surfaces the same engine as sequences, lead-routing rules, scheduler pages, and deal nudges. The sequence editor is a canvas with email, call-task, LinkedIn-task, and wait-step blocks. Pause-on-reply fires the email_replied trigger on the Gmail or Microsoft 365 thread. Scheduler bookings write to the deal activity and fire the pre-meeting prep flow. Depth lives in /features/sales-automation; the engine underneath is the one you already know from the workflow canvas.

BPA layer

Approval blocks, delegation, escalation, audit log.

BPA adds the approval primitive, the delegation layer, the deadline escalation path, and the policy-version-pinned audit log on top of the same engine. The approval block pauses the run, drops onto the approver's queue, and resumes down the matching outbound port on click. Delegation routes to the configured backup during PTO. SLAs trigger auto-escalation. Depth lives in /features/business-process-automation; the primitives are the same canvas blocks the workflow and sales layers use.

One activity graph

Email, call, meeting, sequence step, approval, field change.

Every event the engine produces lands on the same contact and deal timeline regardless of which layer emitted it. A sales sequence step and a BPA approval and a workflow field update all live on the same ordered log. The manager skimming a deal before a call sees the full history in one view. The auditor pulling exception evidence at year-end queries one table. The attribution report that joins marketing campaigns to closed deals runs against one activity graph, not three.

One owner model

The permission model does not change between layers.

A workflow runs under the system identity with the configured ACL. A sales sequence runs under the enrolling user. A BPA approval runs under the approver. All three resolve against the same role, team, and territory structure. Owner change on a deal reassigns open tasks, open sequence enrollments, and pending approvals in the same transaction. The audit log reads from one user directory. Deprovisioning a departing rep is one action, not three.

One price

Per-seat, no per-run meter, no Enterprise-tier gate.

Workflow automation, sales automation, and BPA all ship on every paid tier. Starter runs 1,000 flow runs per month at the included rate. Pro lifts the cap to 50,000. Scale and Enterprise are unmetered. No per-process charge, no Operations Hub add-on, no sales engagement bolt-on subscription, no deal-desk-only edition. The commercial model is one line on the invoice regardless of how many of the three layers you run.

One failure mode

Dead-letter queue, replay, atomic rollback.

When a workflow fails mid-run, writes roll back atomically and the failed run lands in the dead-letter queue with original record context, trigger payload, and the exact block that threw. A sales sequence hitting a bounced email, a BPA approval hitting a rejection, and a workflow hitting a condition miss all route through the same observability surface. One retry policy editor, one DLQ, one failure replay button. Not three incident runbooks for three stacks.

One build velocity

Thursday afternoon per flow, not six-week project.

The RevOps lead who already built a lead-routing workflow on Monday knows how to build an outbound sequence on Tuesday and a discount approval chain on Wednesday. Same canvas, same primitives, same dry-run surface, same publish-to-production motion. The learning curve pays off across all three layers rather than restarting with each vendor migration. A new RevOps hire runs their first three playbooks in week one, not month three.

Where process automation fails without CRM context

The reasons a middleware stack keeps breaking.

The dominant pattern at mid-market SaaS companies trying to automate revenue process is still a stack: a CRM, a workflow tool bolted on, a sales engagement tool bolted on, a BPA tool bolted on, and three integrations tying them together. The pattern worked when CRMs were record stores with no engine, which was true a decade ago. In 2026 it imposes a tax that compounds every quarter. The cards below are the specific places where process automation fails when it does not have native CRM context. Each one is drawn from switchover conversations where teams measured the cost of running the bolted-on pattern against the cost of consolidating.

Context depth

A webhook sees a flat subset of the triggering record.

A middleware tool receives a webhook when a deal changes stage. The webhook payload includes the deal id, the new stage, and whatever fields the integration surfaced. The tool does not see the owner, the owner's manager, the account tier, the related renewal opportunity, the last five activities, or the custom fields that make the routing decision interesting. Every lookup becomes an API round-trip back to the CRM, which is slow, rate-limited, and often cached stale by the time it returns.

Permission drift

The middleware service account has god-mode.

A bolt-on process automation tool authenticates to the CRM with a service account that has permission to read and write every record in every object. The native workflow runs under the system identity with the configured ACL, which can be narrower. The audit trail splits across two systems. The attack surface widens. When a developer at the middleware vendor is compromised, your CRM is compromised, which is a different threat model than one platform under one SOC 2 Type II report.

Latency

The round trip costs you reply time on hot leads.

A prospect replies to a sequence email. The sales engagement tool detects the reply, pauses the sequence, and syncs the status back to the CRM on its next poll cycle. The CRM fires the routing rule that pings the AE. The round trip is minutes to hours depending on sync frequency and rate limits. For a hot inbound, the gap between reply and rep ping is the difference between booked and ghosted. Native closes the gap to the time it takes to run one query.

Attribution loss

Which process touched this deal, exactly.

The deal closes. Finance wants attribution. Marketing wants campaign credit. Sales wants sequence-step credit. The CRM has the deal. The sales engagement tool has the sequence. The BPA tool has the approval. The marketing automation tool has the campaign. The join lives in a BI tool. Every schema change breaks the report. Nobody trusts the number. On a native stack, the attribution report is one chart in the standard reports library because the activity graph is one table.

State fragmentation

Owner change in the CRM, stale in the sequencer.

A deal changes hands in the CRM for a territory re-cut or a departure. The bolt-on tool still has the old rep enrolled in the sequence. The old rep gets the reply, or worse, nobody does. The new rep sees nothing for three days. The sync was supposed to run nightly and missed the hot-reply window. On a native stack, owner change reassigns open tasks, open sequence enrollments, and pending approvals in the same transaction.

Audit fragmentation

SOC 2 asks who approved, four systems answer.

The auditor asks who approved a specific 30 percent discount on a specific deal 18 months ago. The CRM has the deal. The BPA tool has the approval chain. The sales engagement tool has the sequence step. The Slack channel has the pre-approval conversation. Reconstructing the evidence is a four-day engagement. On a native stack, it is a saved view on a report that the controller signs off on in advance of the audit window.

Admin tax

Four admin consoles, four user directories.

Every new hire gets provisioned in the CRM, then in the workflow tool, then in the sales engagement tool, then in the BPA tool, with separate role mappings in each. Every departure requires deprovisioning across four systems, often via four different ticket queues. Permissions, teams, territories, and library content live in four places with four sync processes. The admin tax at a 40-rep team is roughly a full FTE in ops that goes away when the stack collapses to one platform.

Cost sprawl

Four subscriptions quadruple the per-seat line.

Mid-market pricing on dominant workflow tools runs $20 to $40 per seat per month, sales engagement tools $100 to $130, BPA tools $50 to $100, marketing automation $300 to $800 at the team level. Add seat-count minimums, annual commitments, and integration consulting. For a 40-rep team, the stack line can reach $20,000 to $25,000 per month before implementation services. Strkr ships all three layers on the per-seat CRM price with no overage below the plan cap.

Build velocity

Four vendors, four learning curves, four support queues.

A policy change that spans sequence content, discount approval thresholds, and lead-routing rules requires edits in three tools. Each edit lands at a different time because each tool has a different change-review process. The policy is inconsistent across tools until the slowest edit lands, which is often a vendor-support ticket when the admin cannot find the setting. On a native stack, the policy change is one editor, one dry-run, one publish, with version history pinned.

How teams actually pick the layer

Three decisions, three playbooks, three sibling pages.

Decision one

The record-event question → Workflow Automation.

The RevOps lead at a 30-rep team has to automate three things in week one: route inbound leads, flag deals that have aged past threshold, and create a task when a Closed Won fires. All three are record-event rules with no human approval and no multi-step cross-team handoff. The right layer is workflow automation. The build happens in /features/workflow-automation. The RevOps lead has the three flows live by Friday without opening another vendor conversation.

Decision two

The rep-day question → Sales Automation.

The VP of Sales at a 40-rep team wants to replace Outreach with a native solution before renewal lands in six weeks. The jobs are outbound sequences, scheduler for inbound booking, reply detection on the Gmail thread, meeting booked firing a prep flow, and reporting that joins sequence steps to pipeline. The right layer is sales automation. The build happens in /features/sales-automation. The team cuts a $62,000 annual subscription on the switchover.

Decision three

The approval question → Business Process Automation.

The CFO at a 60-rep team wants to formalize the discount approval chain before the Q4 push, with an audit trail defensible at SOC 2 Type II. The jobs are a three-tier approval chain, SLA-based escalation, delegation during PTO, and policy-version-pinned evidence. The right layer is BPA. The build happens in /features/business-process-automation. The chain goes live before the quarter opens and the auditor accepts the evidence in Q1.

Process automation on every paid tier. Workflow, sales, and BPA on one engine.

Starter runs 1,000 flow runs per month at the included rate. Pro lifts the cap to 50,000. Scale and Enterprise are unmetered. Workflow automation, sales automation, and BPA all ship with the per-seat license. No per-run meter below the plan cap, no Enterprise-tier gate, no middleware stack. Pick the sibling that matches your current job and come back here when the next job spans a different layer.

Start free trial See pricing
Common questions

What buyers ask about this feature.

What is the difference between process automation and workflow automation?

Process automation is the umbrella category. Workflow automation is one of the four layers underneath it, alongside sales automation, business process automation, and robotic process automation. Workflow automation specifically means record-event triggers plus any-record-write actions with conditions, branches, and schedule-based firing. Process automation covers the full stack, including human approvals, cross-team handoffs, audit trails, and UI-level legacy system automation. When a vendor says they do process automation, ask which of the four layers they actually serve well. Most tools serve one layer deeply and the others shallowly. Strkr ships workflow, sales, and business process automation on one engine. For RPA against legacy UI-only systems, Strkr is not the right fit and you should look at UiPath, Automation Anywhere, or Blue Prism.

How do I know which type of process automation I actually need?

Name the job first, then pick the layer. If the pattern is "record changes, system reacts," you want workflow automation. If the pattern is "revenue rep touches it every day," you want sales automation. If the pattern is "cross-team process with human approvals and an audit trail," you want business process automation. If the pattern is "automate a UI-only legacy system with no API," you want RPA. Most revenue teams need all three of the first categories but discover them in sequence as the business grows. The RevOps lead starts with workflow in week one, adds sales automation in month two when the sequence motion matures, and layers in BPA in quarter two when the first discount policy audit lands. Strkr ships all three on the same engine so the sequence does not require a vendor migration at each step.

Does Strkr handle all types of process automation?

Strkr ships workflow automation, sales automation, and business process automation on one engine with one activity graph, one owner model, and one audit trail. All three layers compose cleanly: a sales sequence can pause for a BPA approval, which can route to a workflow that creates a task, which can trigger a notification, which can resume the sequence. One trace, one audit log, one per-seat price. Strkr does not do robotic process automation against UI-only legacy systems with no API. For that use case, UiPath, Automation Anywhere, and Blue Prism are the right tools. For CRM-centric revenue and operations process automation, Strkr covers the full surface without a middleware stack. The split is honest and worth knowing before any vendor conversation.

Is process automation the same as business process automation?

No, and the distinction matters when buying. Process automation is the umbrella category. Business process automation is one layer underneath it, specifically the multi-step cross-team processes that require human approvals and audit trails. Deal approvals, discount chains, contract routing, customer onboarding, and renewal motions are all BPA. Simple record-event rules without a human approval step are workflow automation, not BPA. Enterprise BPA platforms like Nintex and Pega are purpose-built for the BPA layer, which is a different scope than a general-purpose process automation platform. Strkr's BPA surface covers revenue-side approval chains and cross-team handoffs with the same engine that runs the workflow and sales automation layers. For enterprise-wide BPA spanning procurement, finance, HR, and operations across a company of 10,000 employees, Strkr is not the right fit.

How does Strkr process automation compare to Zapier or Make?

Zapier and Make are middleware. They sit between tools and pass data between them, usually at per-task pricing. For a CRM-centric revenue motion, that pattern is slow (webhook round-trips), expensive (per-task pricing scales with volume), lossy (middleware sees a flat subset of the record), and fragile (schema changes break the sync). Strkr process automation runs natively inside the CRM. The engine reads the full object graph in one query, writes atomically with rollback on failure, bills under the per-seat license with no per-run meter below the plan cap, and shares one activity graph across every layer. For cross-tool workflows between non-CRM systems where the record context is minimal, Zapier may still make sense. For CRM-centric workflows that touch leads, contacts, deals, projects, or custom objects, native is faster, cheaper, and more reliable.

Can one platform really handle workflow, sales, and business process automation?

Yes, when the primitives are shared. The reason most platforms cannot is that they were built for one layer first and tried to grow into the others later. HubSpot started as marketing automation and bolted on workflow and sales features over 15 years. Salesforce started as CRM and added Flow as a workflow surface. Dedicated sales engagement tools like Outreach and Salesloft do sequences well and nothing else. Dedicated BPA tools like Nintex and Pega do approvals well and know nothing about CRM records. Strkr was architected from day one with workflow, sales, and BPA sharing the same engine, canvas, activity graph, and permission model. Triggers, conditions, actions, approvals, waits, loops, and schedules are primitives in a single DAG executor. Three UIs, one engine, zero reconciliation. The result is that a sales sequence can pause for an approval that triggers a workflow that creates a task, with one trace and one audit log.

What is the cost of running process automation on Strkr versus a middleware stack?

Mid-market pricing on a bolted-on stack typically runs $20 to $40 per seat per month on a workflow tool, $100 to $130 on a sales engagement tool, $50 to $100 on a BPA tool, and $300 to $800 on marketing automation at the team level, with seat-count minimums and annual commitments. For a 40-rep team, the stack line reaches $20,000 to $25,000 per month before implementation services and admin headcount. Strkr ships workflow, sales, and business process automation on the per-seat CRM price with no per-run meter below the plan cap and no Enterprise-tier gate for approval chains. Starter runs 1,000 flow runs per month at the included rate, Pro lifts the cap to 50,000, and Scale and Enterprise are unmetered. The commercial model is one line on the invoice regardless of how many of the three layers you run.

What happens when a process automation run fails mid-execution?

Writes roll back atomically. The failed run lands in the dead-letter queue with the original record context, trigger payload, and the exact block that threw. An admin can replay the run after fixing the upstream issue, or configure a per-flow retry policy with exponential backoff and let Strkr re-fire automatically. The DLQ, retry policy, and failure replay surface are shared across the workflow, sales, and BPA layers, so one observability surface covers every type of process automation on the platform. No half-applied state, no silent data corruption, no partial writes to clean up by hand. The run history logs every input, output, and failure so a bad flow can be re-run from the point of failure or audited after the fact for root cause.

Related features

Pair this with...

Workflow Automation Sales Automation Business Process Automation No-Code Automation Flows (full builder)

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