Feature · Business Process Automation

Low-code business process automation that models, enforces, and audits the real process.

Model long-running business processes with state transitions, approval chains, SLA tracking, hand-offs across humans and systems, and versioned process definitions; then enforce them on the live CRM data with immutable audit on every advancement.

Start free trial See pricing
The business process reality

Real business processes do not run in a single flow.

A business process is not a flow. A flow runs once, start to finish, in seconds. A business process can run for days, weeks, or months, with state transitions between phases, approvals from named roles, SLAs that measure dwell time per phase, hand-offs between humans and systems, and compensating actions when a phase fails. A deal-close process runs for 45 to 180 days. A customer onboarding runs for 30 to 90 days. A quote-to-cash cycle runs for 7 to 30 days. A procurement approval runs for 2 to 14 days. These are not flows. They are long-running processes with state, and they need a tool that models them as such. Low-code business process automation is the shape of tool for this problem. Strkr ships a BPM layer that models long-running processes with explicit states, defines approval chains per transition, tracks SLAs per phase, logs every advancement in an immutable audit trail, and runs the whole thing on live CRM data. The sections below describe the BPM shape in detail.

The duration gap

Processes run for days or months, not seconds.

A deal process runs 45 to 180 days. A customer onboarding runs 30 to 90 days. A procurement approval runs 2 to 14. A flow-shaped tool cannot model a process this long because the state has to persist, the human hand-offs have to pause and resume, and the SLA clock has to track dwell per phase.

The state gap

Processes have explicit phases, not just steps.

A deal is in Qualification, Discovery, Demo, Proposal, Negotiation, or Closed. A customer onboarding is in Kickoff, Technical Setup, Training, Launch, or Active. These are states. The process definition names them, defines valid transitions, and enforces entry and exit criteria per state.

The approval gap

Transitions require named-role approvals.

A deal cannot advance to Proposal without the Deal Desk approving the pricing. A customer onboarding cannot close Technical Setup without the CSM confirming provisioning. A procurement cannot close without Legal approving the contract. The approvals have to route by role, not by individual.

The SLA gap

Dwell time per phase matters more than total duration.

A healthy deal cycle has specific dwell-time expectations: 7 days in Qualification, 10 days in Discovery, 14 days in Demo. A deal that dwells 45 days in Negotiation is dying. The SLA tracker measures dwell per phase and alerts on deviation; the total-duration view hides the phase-level signal.

The hand-off gap

Humans and systems interleave through the process.

The process moves through hand-offs: SDR to AE, AE to Deal Desk, Deal Desk to Legal, Legal to Finance, Finance to Implementation. Each hand-off is a human action; between hand-offs, systems execute (contract generation, provisioning scripts, invoice issuance). The tool has to orchestrate both.

The versioning gap

Process definitions evolve across quarters.

The deal process you defined in Q1 does not match the process you need in Q3 after a product launch. The onboarding process evolves as the product matures. The tool has to version the process definition, run in-flight instances on the version they started on, and promote new instances to the new version.

The audit gap

Every advancement needs a signed row.

Compliance, SOX, and partner-contract review all demand audit on process advancement. Which human approved which transition at which time with what reason. The audit log cannot be an afterthought bolted onto a flow tool; it has to be a native primitive of the BPM layer.

The compensation gap

A failed phase triggers compensating actions.

When a phase fails (deal lost in Negotiation, onboarding stalled in Training, procurement declined in Legal), the process has to run compensating actions: release the hold on the technical team, refund the deposit, notify the account owner, update the forecast. The compensations are part of the process definition.

What BPM delivers

All of the above, on one surface.

A real BPM layer models the states, defines the transitions and the approval chains, tracks the SLAs, orchestrates the human and system hand-offs, versions the definitions, logs the audit, and runs compensations. Strkr's low-code BPM covers each primitive natively on the CRM data layer.

The process definition surface

Model the real process in a visual canvas, not XML.

A BPM tool's usefulness lives in its process definition surface. The surface has to express states, transitions, entry and exit criteria, approval roles, SLA expectations, timers, parallel paths, and sub-processes; in a canvas a RevOps lead can read and edit, not an XML schema an engineer has to maintain. Strkr's process definition surface models the primitives visually with executable semantics behind the picture. The elements below describe how process definitions compose in practice.

States

Named phases with entry and exit criteria.

Each state in a process definition names a phase of the business reality: Qualification, Discovery, Proposal, Negotiation. Each state defines entry criteria (fields that must be populated, approvals that must land) and exit criteria (fields updated, approvals obtained, SLA met).

Transitions

Explicit edges between states.

Transitions define the valid moves between states. A deal can transition from Qualification to Discovery, from Discovery to Demo, or from any state back to Lost. Illegal transitions (Qualification directly to Proposal) are blocked by the engine with a clear error message.

Approval chains

Role-based approvals per transition.

A transition can require approvals: the deal-to-Proposal transition requires Deal Desk approval; the deal-to-Close-Won transition requires the Finance approval if the deal exceeds a threshold. The chains define as roles, not individuals, so personnel changes do not break the process.

SLA definitions

Dwell-time expectations per state.

Each state defines an expected dwell time: 7 days in Qualification, 10 days in Discovery. The SLA clock starts on state entry and stops on state exit. The dashboard surfaces dwell-vs-SLA across every active instance. Alerts fire on SLA breach to the responsible owner.

Timer triggers

Time-based auto-advancement.

A state can auto-advance after N days unless specific conditions block: a dormant deal in Qualification auto-moves to Nurture after 30 days of no activity. A pending approval auto-escalates after 48 hours of no response. The timers encode in the state definition.

Parallel paths

Multiple states active simultaneously.

A process can hold multiple states active in parallel: a customer onboarding runs Technical Setup, Training, and Billing Setup concurrently with each tracked independently. Convergence rules define when parallel paths rejoin.

Sub-processes

A state can embed a smaller process.

Any state can embed a sub-process definition: the Legal state in a procurement process embeds a Contract Review sub-process with its own states (Draft, Redline, Negotiate, Signed). The embedding keeps the outer process readable while the inner process holds its own detail.

Compensating actions

Rollback behavior when a phase fails.

Each state can define compensating actions: on Deal Lost, release Technical Hold and notify Operations; on Procurement Declined, refund the deposit and update the forecast. The compensations run as the state exits to a terminal failure.

Visual canvas

A canvas the RevOps lead can read and edit.

The process definition surfaces in a visual canvas: boxes for states, arrows for transitions, badges for approvals, timers for SLAs. The RevOps lead reads the whole process in one view and edits inline. No XML, no code, no engineer required for a transition change.

Approval chains and SLA enforcement

Human decisions, system execution, and the clock.

A BPM tool earns its value in the human-decision moments: who approves what, by when, with what context. The approval surface and the SLA surface are where processes bog down in most tools. Strkr's approval primitive routes decisions to named roles with full context, times out to escalations, and logs the decision with a reason. The SLA primitive measures dwell per phase and alerts on deviation. The elements below describe how approvals and SLAs operate in practice.

Role-based routing

Approval routes to the role, not the person.

An approval routes to a role (Deal Desk, Legal, Finance, CFO) rather than a person. The current person holding the role gets the approval task. Personnel changes do not break the process; the new Deal Desk lead inherits the approval queue automatically.

Approval context

The approver sees everything they need.

An approval task arrives with the full context: the deal record, the pricing proposal, the discount asked, the owner's justification, the SLA remaining, the policy references. The approver does not have to hunt for context in other tabs; the task holds it in one view.

Approval decision + reason

Approve, decline, request changes, with explanation.

The approver takes one of three actions: approve (process advances), decline (process branches to a decline path with the compensations), request changes (process returns to the author with the change request). Each action carries a required reason. The reason persists.

Timeout escalation

A pending approval escalates after N hours.

An approval that sits unanswered after a configured timeout escalates: notify the approver's manager, re-notify the approver, after a second timeout auto-route to a backup approver. The escalation chain defines in the process definition.

Parallel approvals

Multiple approvals happen simultaneously.

A transition can require parallel approvals: Legal and Finance both approve a procurement contract. The transition waits for both. The parallel execution reduces end-to-end process duration vs serial approval chains.

SLA dwell tracking

Time spent in each state measured independently.

The SLA engine measures time in state separately from time in process. A deal that spent 10 days in Qualification, 8 days in Discovery, and 45 days in Negotiation gets flagged on the Negotiation phase rather than hidden inside total duration.

SLA alerting

Alerts fire on dwell above the threshold.

When a state's dwell exceeds the SLA threshold, the engine fires alerts: notify the record owner, surface on the manager dashboard, add a flag to the record. The alerts route by role so the right person acts without the owner having to escalate manually.

SLA reporting

Rolling view of dwell per phase per segment.

The reporting layer rolls up dwell per phase across every instance by segment, by owner, by team. The RevOps lead sees that the Deal Desk approval phase averaged 3.2 days last quarter and 5.8 days this quarter; the signal to go investigate the Deal Desk bottleneck.

Audit on every decision

Approver, reason, timestamp logged.

Every approval decision lands in the immutable audit log with the approver, the decision, the reason, the timestamp, and the IP address. Compliance reads the audit log to confirm approval governance. Carrier audits review the decision trail on specific deals.

Hand-offs between humans and systems

The process moves through people and services together.

A real business process interleaves human steps and system steps. The AE submits the deal; the system drafts the contract. The customer signs; the system provisions the account. The CSM confirms activation; the system issues the invoice. Each hand-off is a boundary between human action and system execution. Strkr's BPM orchestrates both: human tasks route to the right owner with context, system actions execute against external services, and the process state advances cleanly through each hand-off. The elements below describe how the hand-offs operate.

Human-task node

A task routes to the right owner.

A human-task node routes to the owner responsible for the step: the AE for pricing, the CSM for onboarding, the engineer for provisioning. The task arrives on the owner's queue with context, actions, and a due date. The process waits for completion.

System-action node

A system step calls an external service.

A system-action node calls an external service: generate a contract via DocuSign, provision via the platform API, bill via Stripe, create a Jira ticket. The call runs on the write path with retries and error handling. The response advances the process.

Hand-off between humans

Owner changes mid-process.

A process can hand off between humans across phases: SDR owns Qualification; AE owns Discovery through Negotiation; CSM owns Onboarding through Active. Each hand-off updates the record owner, notifies the incoming owner with context, and transfers the queue.

Hand-off from human to system

Approval triggers automated execution.

A human approval decision triggers a sequence of system actions: Deal Desk approval triggers contract generation, DocuSign send, calendar invite for close call, forecast update. The AE's approval kicks off a dozen downstream automations without manual trigger.

Hand-off from system to human

System event raises a human task.

A system event raises a human task when judgment is required: contract exception detected (route to Deal Desk for review), provisioning failure (route to engineer for debug), payment declined (route to CSM for customer conversation). The handoff ships with context.

Parallel human + system

Humans and systems execute concurrently.

A process phase can run human and system tasks in parallel: the CSM runs the kickoff call while the system provisions the account. The phase waits for both to complete before advancing. The parallel execution reduces end-to-end duration.

Context preservation

Every hand-off carries the context forward.

Each hand-off preserves the full process context: prior state, prior decisions, prior approvals, prior system outputs. The incoming owner sees the complete history. The incoming system call receives the full state as input.

External system failures

Retries, dead-letters, human escalation.

External system calls that fail retry on exponential backoff. Persistent failure dead-letters to a human-escalation queue with the error and the context. The process pauses on the failed step rather than silently losing state.

Idempotency

A retried action does not double-execute.

System actions carry idempotency keys so retries do not create duplicate records, duplicate charges, or duplicate emails. The engine deduplicates on the key. The posture matters when the external system (Stripe, DocuSign) returns ambiguous responses.

Versioning, audit, and the enterprise posture

Process definitions evolve; the audit never breaks.

Business processes evolve across quarters as the business learns. The deal process you defined in Q1 does not match the process you need after a product launch in Q3. A BPM tool has to version the process definitions, run in-flight instances on the version they started on, promote new instances to the new version, and keep an audit trail across every advancement regardless of version. Strkr's BPM ships the versioning and audit primitives natively. The elements below describe the enterprise posture.

Process versioning

Each definition carries a version.

Each process definition carries a semantic version. Changes to states, transitions, approvals, or SLAs create a new version. The admin reviews the diff before promoting the version. Rollback to a prior version is a one-click action.

In-flight stability

Running instances stay on their version.

An in-flight process instance runs on the version it started on. A deal that opened under v1.2 of the deal process completes under v1.2 regardless of whether v1.3 published in the middle. The posture avoids mid-process confusion for the owner.

Version migration

Explicit migration for in-flight to new.

When a new version introduces a change that must apply mid-flight (new compliance requirement), the admin runs a migration: review the affected in-flight instances, apply the migration path, confirm the state transition. The migration is explicit, not implicit.

Immutable audit log

Every state transition logged forever.

Every state transition on every instance lands in the immutable audit log: the from-state, the to-state, the actor, the decision, the reason, the timestamp. The log is retained per compliance policy (default 7 years) and tamper-evident.

Approval audit

The approval decision trail per instance.

Each instance carries a complete approval trail: which approver approved which transition at which time with what context and what reason. The trail supports SOX audits, carrier audits, and internal process reviews.

SLA breach audit

Every breach logged with who was alerted.

When an SLA breaches, the audit log records the breach: the state, the dwell duration, the SLA threshold, who was alerted, and whether the alert was acknowledged. The breach data feeds quarterly process review.

Role segregation

Author, approve, publish split by role.

A RevOps analyst can author process definitions but cannot publish to production. A RevOps lead can approve and publish. A platform admin manages approval policies. The segregation of duties protects production processes from unreviewed changes.

Three environments

Dev, stage, prod for process definitions.

Process definitions build in dev, test in stage against stage data, and promote to prod. Each environment has its own instances. A buggy process in dev cannot touch production records. The three-environment model matches application code posture.

SOC 2 Type II posture

The underlying platform carries the attestation.

Strkr runs on SOC 2 Type II certified infrastructure. The BPM layer inherits the attestation. Enterprise evaluations review the audit log retention, encryption at rest and in transit, role-based access, and segregation of duties; all native primitives.

Low-code business process automation that models the real process and enforces it.

State machines, approval chains, SLA tracking, hand-offs across humans and systems, versioned process definitions, three environments, immutable audit, and SOC 2 Type II infrastructure; all on the live CRM data where the process already runs.

Start free See workflow automation
Common questions

What buyers ask about this feature.

What is low-code business process automation and how is it different from workflow automation?

Workflow automation runs step-by-step sequences in a flow definition; a flow triggers, executes a series of actions in seconds, and completes. Business process automation models long-running processes with explicit states, state transitions, approval chains per transition, SLA expectations per state, and hand-offs between humans and systems that can take days or weeks. A deal process from Qualification to Close runs 45 to 180 days with multiple human approvals, system actions, and parallel paths. A workflow tool struggles to model this because workflows end; a BPM tool models this natively because processes have state that persists across weeks. Strkr's low-code BPM layer ships both: workflows for short-form automation and process definitions for long-running state. The admin picks the right primitive for the shape of the problem.

How does Strkr handle approvals in a long-running business process?

Approvals route to roles rather than individuals, so personnel changes do not break the process. Each approval task arrives with the full context: the record, the proposed change, the owner's justification, the SLA remaining, the applicable policy references. The approver takes one of three actions; approve, decline (branches to the decline path with compensating actions), or request changes (returns to the author with the change request); each requiring a reason. Timeouts escalate: an approval sitting unanswered after a configured window re-notifies the approver, notifies their manager, and after a second timeout auto-routes to a backup. Parallel approvals (Legal and Finance both approve a procurement contract) wait for all parties. Every decision lands in the immutable audit log with the approver, the decision, the reason, the timestamp, and the IP address.

How does the SLA tracking work and what happens when an SLA breaches?

Each state in a process definition carries an expected dwell time (7 days in Qualification, 10 days in Discovery). The SLA clock starts on state entry and stops on state exit. The dashboard surfaces dwell-vs-SLA across every active instance in real time. When a state's dwell exceeds the SLA threshold, alerts fire: notify the record owner, surface on the manager dashboard, add a flag to the record. Escalation routes by role so the right person acts without the owner having to escalate manually. The reporting layer rolls up dwell per phase across every instance by segment, by owner, and by team, so RevOps leaders can see that (for example) the Deal Desk approval phase averaged 3.2 days last quarter and 5.8 days this quarter; the signal to investigate the bottleneck. Every breach lands in the audit log with the state, the dwell duration, the threshold, and the alert history.

What happens when a business process definition needs to change mid-flight?

Each process definition carries a semantic version. Changes to states, transitions, approvals, or SLAs create a new version. In-flight instances stay on the version they started on by default; a deal that opened under v1.2 of the deal process completes under v1.2 regardless of whether v1.3 published mid-flight. This posture prevents mid-process confusion for the owner. When a new version introduces a change that must apply mid-flight (a new compliance requirement, a critical bug fix), the admin runs an explicit migration: review the affected in-flight instances, apply the migration path, confirm the state transition on each. The migration is explicit and auditable rather than implicit. Rollback to a prior version is a one-click action. The versioning posture matches application code versioning practice.

How does Strkr orchestrate hand-offs between humans and external systems?

A process interleaves human-task nodes and system-action nodes. Human-task nodes route to the right owner (SDR, AE, CSM, engineer) with full context and a due date; the process waits for completion. System-action nodes call external services (DocuSign for contracts, Stripe for billing, platform APIs for provisioning, Jira for tickets) with retry, idempotency, and error handling. Hand-offs between humans change the record owner, notify the incoming owner with context, and transfer the queue. Hand-offs between humans and systems trigger automated sequences on approval (Deal Desk approval kicks off contract generation, DocuSign send, calendar invite, and forecast update). System events can raise human tasks when judgment is required (contract exception detected, provisioning failure, payment declined). External system failures retry on exponential backoff; persistent failures dead-letter to a human-escalation queue with error context. Idempotency keys prevent retried actions from creating duplicates in external systems.

What compliance posture does Strkr's BPM layer provide for SOX and partner-contract audits?

Every state transition on every instance lands in the immutable audit log with the from-state, the to-state, the actor, the decision, the reason, the timestamp, and the IP address. Default retention is 7 years, with configurable extension. The log is tamper-evident. Each instance carries a complete approval trail; which approver approved which transition at which time with what context and what reason. Role segregation prevents the author of a process definition from being the sole approver (segregation of duties). Three environments (dev, stage, prod) enforce change management: definitions build in dev, test in stage, promote to prod with approval. The underlying platform runs on SOC 2 Type II certified infrastructure, with HIPAA posture available under BAA, GDPR and CCPA compliance end to end, and data residency election (US, EU, or Canada) at provisioning. SOX audits, carrier audits, and partner-contract reviews all run against the native audit trail.

Related features

Pair this with...

Low Code Process Automation Low Code Automation Low Code Workflow Automation Tools Workflow Automation Automation Platforms Automation Software

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