A business process is a chain of handoffs, SLAs, exceptions, and approvals. Strkr's workflow process automation models the process end to end: trigger on the business event, enforce the SLA, route the approval, handle the exception, measure the cycle time, surface where it is breaking. Native to the CRM, no middleware tax.
There is a difference between a workflow that fires a few actions and a process automation that models an end-to-end business process. The first is useful. The second is where real cycle-time reduction happens. A process has a start event, a chain of handoffs between roles, SLAs at each handoff, approval gates, exception paths, and a terminal event. Modeling all of that is what elevates "we automate a few things" to "we run the business process in the system."
A process starts on a business event: new deal above threshold, new high-value lead, new support ticket, new renewal 90 days out. The start event is the business thing that happened, not the technical event (which record got touched). The process view asks "what kicked off this cycle" rather than "what field changed."
A process is a sequence of handoffs: BDR hands to AE, AE hands to SE, SE hands to legal, legal hands to CS. Each handoff is an owner change with a timestamp. The process view tracks the handoffs because the handoffs are where processes slow down, not where they move fast.
Each stage of a process has an SLA: BDR to AE in 1 hour, AE to SE in 2 business days, legal review in 5 business days. The runtime enforces the SLA with alerts, escalations, or auto-advance when the clock runs out. The classic "it is sitting on legal's desk" problem has a specific SLA and a escalation path.
When a process needs approval (discount above 20 percent, contract term above 36 months, custom MSA language), the approval is a step in the Flow with an approver, a decision button, and a timeout. The approval log is part of the process audit, not a separate record in a different system.
Processes have exceptions: the deal does not have an SE assigned, the legal reviewer is on vacation, the customer wants a non-standard payment term. The process view models the exception paths explicitly instead of pretending the normal path always applies. The exception is logged with its reason and routed to the right handler.
A process ends in a terminal event: contract signed, support case closed, renewal booked, lead disqualified. The cycle time is the time from start event to terminal event. The process view measures end-to-end so improvement work has a concrete number to move.
Below are the six revenue processes we have watched teams automate end to end with measurable cycle-time improvement. Each one models a real business handoff chain, not a single-step action.
Start event: inbound lead. Handoffs: BDR enrichment (SLA 1 hour), BDR qualification call (SLA 2 business days), handoff to AE (SLA 4 hours), AE discovery call (SLA 5 business days). Terminal event: opportunity created at Qualified stage. Teams that automate the end-to-end process see cycle time drop from 11 days to 4.
Start event: deal has discount above threshold. Handoffs: AE submits with justification, manager reviews (SLA 1 business day), VP reviews if above 30 percent (SLA 2 business days), finance confirms the price. Terminal event: approved and reflected on the opportunity. The classic "it is sitting with the VP" problem has a visible SLA and auto-escalation.
Start event: AE requests legal review on a non-standard contract. Handoffs: legal queue (SLA 2 business days), redline draft (SLA 3 business days), AE review of redline (SLA 1 business day), customer re-review. Terminal event: signed contract. The cycle time is the SLA; the process view surfaces where it is breaking.
Start event: deal moves to Closed Won. Handoffs: CS kickoff scheduled (SLA 2 business days), onboarding project created (SLA 1 business day), kickoff call completed (SLA 7 business days), implementation milestone 1 complete (SLA 30 business days). Terminal event: customer in production. The handoff chain lives in the system instead of in a Slack thread.
Start event: account health crosses risk threshold. Handoffs: CSM reach-out (SLA 2 business days), exec sponsor involved if score below critical (SLA 3 business days), save plan documented (SLA 5 business days), save decision (retain or churn). Terminal event: outcome recorded. The save motion has a cycle time and a visible failure mode.
Start event: expansion signal (usage spike, exec engagement, roadmap alignment). Handoffs: AE identifies opportunity (SLA 3 business days), discovery call (SLA 10 business days), proposal (SLA 15 business days), close. Terminal event: expansion deal booked. The expansion pipeline becomes a measurable process with a cycle time, not an ad-hoc effort.
The SLA layer is what distinguishes process automation from simple action automation. Each stage has a target cycle time, a warning threshold, and an escalation path. The runtime enforces the SLA so the process does not quietly slow down.
When a process enters a stage (handoff happens), the stage clock starts. When the stage ends (next handoff or terminal event), the clock stops. The cycle time per stage is written to the audit log. The process-level cycle time is the sum of the stage times.
Each stage has a warning threshold (e.g., 75 percent of the SLA). When the clock crosses the warning, a soft alert goes to the current owner: Slack ping, email, or in-app notification. The warning catches the "I forgot about this" cases before they become SLA breaches.
When a stage exceeds its SLA, the runtime fires the escalation path: notify the owner's manager, raise a flag on the record, open a Projects issue, or auto-reassign to a backup. The escalation is configured per stage; different stages escalate differently.
For specific stages (e.g., an approval gate where no response in 5 business days means auto-approve under a certain threshold), the runtime can auto-advance the process. The auto-advance is configured per stage and logged with the reason. The pattern avoids the "process is stuck forever waiting on an approver" trap.
SLAs are measured in business hours (configurable per tenant), not calendar hours. A 2-business-day SLA that starts Friday at 4pm does not breach Monday at 4pm; it has until Tuesday at 4pm. Weekends and configured holidays do not count against the clock.
When a stage is waiting on an external party (customer response, vendor response), the owner can pause the SLA clock. The pause is logged with a reason and a resume condition. When the external event lands, the clock resumes. The pattern avoids penalizing the owner for the external delay.
Real business processes have exceptions. The customer wants a non-standard term. The usual approver is out. The product does not fit the standard SKU. Modeling exceptions explicitly is the difference between automation that works on paper and automation that works in production.
A process can branch when a condition does not match the standard: deal size above a threshold routes to deal desk, contract term above 36 months routes to legal, product mix outside standard routes to product management. The branches are explicit paths in the Flow, not implicit fallbacks.
When the standard approver is marked out-of-office, the runtime routes to the delegate. The delegate is configured per approver; the OOO signal comes from the calendar integration. The classic "the VP is on vacation and the deal is stuck" problem has a delegation path.
Some process stages require a human to decide between paths: this deal needs a custom contract or it does not, this account needs an exec sponsor engaged or it does not. The runtime pauses the process and surfaces a decision task to the configured role. The human decides; the process continues on the chosen path.
If a customer re-opens a redline after legal signed off, the process rolls back to the legal stage. The rollback is logged with the reason; the cycle time is re-counted from the rollback point. The pattern models the real-world "something changed, we need to revisit" case.
Some deals skip the standard path: enterprise rep handling a strategic account can request a fast-path approval that routes directly to the CRO. The fast path is a modeled exception, not a shortcut that bypasses the audit log; the fast path still writes to the audit.
When a stage fires its exception path more than 20 percent of the time, the process has drifted. The reporting surface counts exception rate per stage over time. A rising exception count surfaces where the standard process needs to be revised, not where more handling needs to be added on top.
Process automation without measurement is just task automation. The real value shows up when the runtime also captures the data that lets you improve the process over time. Below is the measurement surface that turns automation into continuous improvement.
For each process, a dashboard shows median cycle time, p95 cycle time, and the distribution across stages. The chart surfaces where the time is going: 70 percent in legal review, 20 percent in BDR qualification, 10 percent in everything else. The ops lead optimizes the biggest slice first.
Each stage shows its own cycle time, SLA, breach rate, and exception rate. The bottleneck stage is visible as the one with the biggest cycle time (or the biggest SLA breach rate). The improvement work has a concrete target: shorten this stage.
For a process with branches and exceptions, the variant chart shows which paths get taken and how often. Teams discover that the "exception" path is actually the majority path for enterprise deals, which means the process definition is wrong (not the deals).
Cycle time rolled up per owner shows which people are faster and which are slower. Useful for coaching (why is this rep's discovery-to-proposal twice as long as the team median) and for process design (should we route high-urgency deals to the fastest rep).
Admins can run a process variant on a subset of records (e.g., 20 percent of new leads get the new 2-stage qualification; 80 percent get the standard 3-stage). The variant chart compares cycle times and conversion rates. The pattern turns process changes into measurable experiments.
The reporting surface exports a one-page process-review PDF for the QBR: cycle time this quarter, cycle time last quarter, the delta, the biggest bottleneck, the improvement plan for next quarter. The ops lead walks into the QBR with the data in hand.
Business processes in regulated industries (healthcare, financial services, legal, government) have specific compliance requirements: approval chains must be auditable, every decision must have a reason, exceptions must be reviewed, and the full history must survive for retention periods measured in years.
The process audit log captures every stage entry, every handoff, every approval, every exception, every rollback, every pause. The log is immutable (append-only, no edits possible) and retained per tenant policy. SOC 2 Type II and ISO 27001 reviewers get the full trail.
When a process requires a approval chain (manager, VP, finance), the runtime enforces the order. A process cannot skip the manager and go straight to the VP. Attempts to bypass are logged. The compliance posture is enforced in the runtime, not in training.
Approval and exception decisions require a reason field. The reason is stored on the audit record and visible to compliance reviewers. The pattern turns "someone approved this on Tuesday" into "Sarah approved this on Tuesday because the account is a strategic logo and the discount was within VP authority."
For regulated processes, the approver cannot be the same person as the requester. The runtime enforces segregation of duties by default; attempts to self-approve are blocked. Admins can configure the segregation rules per process.
Each tenant sets a retention policy for process audit records (90 days, 1 year, 7 years, 10 years). Regulated industries typically retain for 7 years. The retention is enforced in the runtime; the records cannot be deleted earlier than the policy allows.
In high-governance tenants, admins can require that any new or edited process is reviewed and approved before publishing. The approval queue shows the diff. SOC 2 Type II and ISO 27001 change-control satisfied with one surface.
Business process management (BPM) has historically been its own category: Pega, Appian, Camunda, Nintex. Capable, enterprise-grade, expensive, and often disconnected from the CRM. Native process automation replaces the stack for revenue-adjacent processes.
Pega is deep. The friction is the price (six-figure deployments are common) and the integration tax (connecting Pega to the CRM is a project). For revenue-adjacent processes at mid-market, the depth is overkill and the integration tax is prohibitive.
Appian is approachable and strong at complex approval chains. Pricing starts at the enterprise level. For a mid-market revenue team that just needs to model lead-to-opportunity, the Appian investment is larger than the problem warrants.
Camunda is developer-friendly and open source. For teams with engineering capacity who want BPMN notation and custom workflows, it works. For a RevOps generalist, the BPMN learning curve and the operational overhead are not worth the depth.
Nintex is tightly integrated with Microsoft 365 and SharePoint. For Microsoft-shop organizations, it is a reasonable fit. The friction is the SharePoint-centricity; CRM-centric processes end up with awkward integration layers.
Salesforce Flow Orchestrator (the multi-step process variant) is deep and native to Salesforce. The friction is the admin certification requirement and the Enterprise edition paywall. Mid-market teams usually run a stripped-down version.
The process automation surface ships on Pro and above. Model handoffs, SLAs, approvals, exceptions, and cycle times without an admin certification, without an enterprise price tag, and without a BPM-specific learning curve. The visual canvas is the same one the RevOps lead already uses for other Flows.
Model business processes end to end: handoffs, SLAs, approvals, exceptions, cycle times, continuous improvement. Native to the CRM, no BPM-specific learning curve.
Workflow process automation models an end-to-end business process (start event, handoffs, SLAs, approvals, exception paths, terminal event) in a visual canvas. The runtime enforces the SLAs, routes approvals, handles exceptions, and measures cycle times. It is distinct from simple action automation, which fires a few actions on a trigger. Strkr's process automation surface targets the business process, not just the record change.
Workflow automation is "trigger fires, actions run." Process automation is "a business process is modeled with handoffs, SLAs, approvals, exceptions, and a terminal event." The second is a superset of the first. For a simple notification Flow, workflow automation is enough. For an end-to-end business process with handoffs between roles and SLAs at each stage, process automation is the right surface.
For revenue-adjacent processes at mid-market, yes. Lead-to-opportunity, discount approval, contract redline, order fulfillment, churn save, expansion motion. Each one is a modeled process in Strkr. For non-revenue processes (claims adjudication at an insurer, loan origination at a bank), a dedicated BPM tool is still often the right choice. The split is cleaner than running every process through one BPM.
SLAs are measured in business hours (configurable per tenant), not calendar hours. A 2-business-day SLA that starts Friday at 4pm does not breach Monday at 4pm; it has until Tuesday at 4pm. Weekends and configured holidays do not count against the clock. Owners can also pause the SLA clock when a stage is waiting on an external party; the pause is logged with a reason and a resume condition.
Exceptions are modeled explicitly as branches in the process definition. Deal size above threshold routes to deal desk; contract term above 36 months routes to legal; approver out-of-office routes to the delegate. The exception is logged with its reason and routed to the right handler. The exception count per stage is a measured signal: when a stage fires its exception path more than 20 percent of the time, the standard process needs revision.
The reporting surface tracks median cycle time, p95 cycle time, stage-level cycle time, SLA breach rate, and exception rate per process. The QBR export produces a one-page summary comparing this quarter to last quarter with the delta, the biggest bottleneck, and the improvement plan. Continuous improvement becomes a data-driven conversation instead of a vague "we are getting better" claim.
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.
