Feature · Robotics Process Automation

Robotics process automation that lives in the record, not on a Windows desktop.

Classic robotics process automation installed a desktop agent and taught it to click through a browser. The modern version is a canvas inside the CRM where the bots read records directly, reason with Strkr AI, and write back under permission allowlists. No desktop agent, no UI scraper, no screen recordings. Nine prebuilt bots ship enabled; the admin composes new ones on the same canvas.

Start free trial See pricing
The two generations of robotics process automation

Where classic RPA fit, and where it stopped fitting.

Robotics process automation emerged as an enterprise category around 2015. The original use case was clear: a bank had thirty applications that did not integrate with each other, and the business needed data to move between them without hiring an army of operators. The classic shape installed a desktop agent, recorded a human performing the task, and replayed the recording as a scheduled bot. The approach worked for a specific class of problem. It stopped working the moment the surrounding applications started offering APIs that made integration a weekend project rather than a six-month procurement. By 2026 the use case for desktop-agent RPA has narrowed substantially. Most enterprise workflows that teams would have paid UiPath or Automation Anywhere to automate three years ago now ship as native primitives inside the application of record. The question for a revenue team in 2026 is whether the specific set of bots they need actually requires a desktop agent, or whether a canvas inside the CRM reading records directly is the right shape. The sections below describe the native canvas approach and the specific jobs it covers inside Strkr. Teams that still have genuine cross-application UI-scraping needs run those separately on a specialist RPA tool; everything inside the CRM runs natively.

Classic RPA

Desktop agent, recorded clicks, scheduled runs.

The classic shape ran on a Windows desktop with a recorded script. Scripts broke the week a vendor pushed a browser update. The maintenance cost compounded. The audit trail lived in a specialist console separate from the business system of record. The license was substantial and typically grew with bot count.

Native CRM bots

Canvas inside the application, records read directly.

The native shape runs inside the CRM. Bots read records directly from the database, reason with Strkr AI, and write back under permission allowlists. There is no UI scraper, no desktop agent, no screen recording. The bot survives UI changes because the bot never looked at the UI.

Audit integration

Bot activity sits in the main audit log.

Every bot run lands in the Strkr audit log alongside human actions. A compliance reviewer walks one log, filters by actor, and finds the bot activity in context. There is no vendor dashboard three logins away hoarding the information. The retention matches the tenant retention policy.

Permission model

Bots inherit the service account permissions.

A bot runs under a named service account with configured permissions. The bot cannot read a field the service account cannot read and cannot write a field outside the admin-configured allowlist. The validator refuses to save flows that violate the posture. The compliance review on a new bot is minutes, not weeks.

Reasoning native

Strkr AI handles the judgement half.

Where classic RPA failed on tasks that required judgement, the native approach calls Strkr AI as a node on the canvas. Classify, extract, draft, score, summarize, decide. The reasoning step honors retries, idempotency keys, and audit logging the same way every other node does, which keeps the whole flow production-reliable.

No credit meter

Bot runs do not consume billable prompts.

Strkr bots run on every paid tier with no per-run billing. A representative mid-market tenant pushes millions of bot runs a month covered by the seat price. The admin designs flows against operational need rather than against a credit budget, which is the single biggest practical difference from a competing RPA stack.

Observable

Every run leaves a visible breadcrumb trail.

The run log shows every bot execution with inputs, outputs, elapsed time, and status. A failed run exposes the exact node and error. Debugging a bot feels like debugging a stored procedure, which is the shape every working RPA team eventually ends up asking the vendor to provide.

Dev to prod promotion

Three lanes with real approvals.

Every bot carries a dev, staging, and production lane. Changes move through each boundary with configured approvals. Prod never surprises the team because staging reads exactly the same version prod will see next. The promotion is a product feature, not a Pulumi script maintained on an admin laptop.

Kill switch

One toggle to pause a misbehaving bot across the tenant.

A kill switch on every bot pauses it immediately across the tenant and emits a system notice to every admin. The paused state preserves the run history and config for diagnostic walk-through. Nothing is lost; everything is paused. The posture is the safe default under incident response.

The nine prebuilt bots

What ships enabled on every paid tier.

Classic RPA shipped a blank canvas and a professional services contract to build the bots. The native approach ships nine production-grade bots enabled by default on every paid tier, with the configuration surface exposed so the admin tunes them to the business rather than building them from zero. The nine bots cover the specific motions a mid-market SaaS revenue team runs: lead routing, deal updates, renewal prep, support triage, pipeline hygiene, forecast scrubbing, expansion sweeps, reporting, and record merging. Each one runs under the tenant governance posture and is editable on the standard flow canvas.

Lead routing bot

Owner assigned inside 60 seconds.

The routing bot reads territory rules, round-robin assignments, named-account mappings, and availability settings. Inbound leads land with an owner before the floor finishes the morning coffee. The bot respects account hierarchies and routes subsidiary leads to the parent-account owner on named accounts.

Deal update bot

Stale deals, missing plans, absent champions.

The deal bot walks every open opportunity daily. Deals past the stage SLA with no activity get a nudge. Deals in Negotiation missing a close plan get a flag. Deals above the executive threshold without a mapped champion surface a task. The manager stops being the quality gate.

Renewal prep bot

A pitch 120 days ahead of the end date.

When a contract crosses the 120-day window, the renewal bot opens the renewal opportunity, drafts a narrative from usage and support history, and lands a task on the CSM. The motion starts four months out, which correlates with renewal rates well above the one-week scramble shape.

Support triage bot

Severity, product area, routing, summary.

An inbound ticket gets a severity label, a product area tag, a short extracted summary, and a routing decision in one pass. The agent opening the queue in the morning sees a sorted and labeled stack. Nothing sits in the catch-all queue waiting for a human triage pass.

Pipeline hygiene bot

Nightly scrubs of eight hygiene categories.

The hygiene bot flags stale deals, missing close plans, absent champions, no-activity stretches, amount mismatches against quotes, past-date close dates, missing competitor mentions in Negotiation, and SLA breaches above 50 percent of the median. The pipeline stays clean without a manager cycle.

Forecast scrubber

The gap between rep-called and model-called.

The scrubber compares the rep-called forecast against the model-called forecast on every deal. Deals where the rep calls commit but the model calls at-risk land on a surfaced list for the manager. The forecast conversation opens on the real disagreements rather than from the top of the pipeline.

Expansion sweeper

White-space signals compounded into a play.

The sweeper walks every active customer. Accounts hitting a seat ceiling, adding a strategic stakeholder, or activating a feature flag that correlates with cross-sell get a surfaced play with a suggested next step and a drafted email. The AE opens an actionable queue rather than a list of accounts to read.

Reporting bot

The brief delivered Sunday evening.

A reporting bot runs Sunday evening and composes the weekly pipeline brief, the win-rate dashboard snapshot, and the churn watchlist. Each one lands in the right inbox by 06:30 Monday. The leadership team opens Monday with the receipts rather than a dashboard dig.

Record merger

Duplicates resolved by rule.

The merge bot walks the account book nightly for duplicates. Matches above the configured threshold auto-merge; ambiguous pairs surface for a human decision. Hierarchies, custom fields, and activity history preserve across the merge. The book stays clean without a quarterly scrub.

What a bot step looks like on the canvas

The anatomy of a Strkr bot node.

Every bot on the flow canvas is a composition of typed nodes with the same contract every other node on the canvas has. Triggers fire bots. Read nodes pull records. Reasoning nodes call Strkr AI. Decision nodes branch. Action nodes write back to records or send external messages. Error branches handle failures. The admin building a new bot drags each node onto the canvas, connects the paths, and publishes. The canvas is the same canvas used for every other flow in the tenant, so the admin learns one tool and applies it across sales motions, marketing motions, service motions, and operations motions.

Trigger

Record change, schedule, API event, button.

Every bot starts on a trigger. A record change on a given object fires the bot. A scheduled run (hourly, nightly, weekly) fires the bot. An inbound API event fires the bot. A button click from a user with the right permission fires the bot. The admin picks the trigger from a palette.

Read

Typed queries against the data model.

A read node pulls a record, a related record, or a filtered collection. The query is typed; the downstream nodes see shaped data rather than a raw blob. The admin never writes an opaque WHERE clause the system cannot explain, and the permission model enforces at read time.

Reasoning

Strkr AI nodes: Classify, Extract, Draft, Score, Decide.

When the bot needs judgement, it calls a Strkr AI node. The node honors retries, idempotency keys, timeouts, guardrails, and audit log entries. No webhook to a separate AI service, no second billing meter. The reasoning step is a first-class citizen on the canvas.

Branch

If/else decisions on typed conditions.

A branch node evaluates typed conditions and routes to one of several downstream paths. The condition reads shaped data from upstream nodes. The admin composes complex business logic entirely in the visual canvas rather than in a hundred lines of JavaScript the next admin cannot read.

Loop

Iterate over collections with per-iteration state.

A loop node iterates over a collection of records with per-iteration state. The admin processes an inbound batch, a list of related contacts, or a quarterly roster with the same pattern. Early-exit conditions and configured iteration limits protect against runaway loops.

Write

Updates under permission allowlists.

A write node updates fields on records under the service account permission and the admin-configured allowlist. The validator refuses to save flows that write outside the list. The record audit log shows which bot wrote which field at which time, so compliance can walk a change back to the originating automation.

External action

HTTP, SMS, email, document.

When a bot reaches outside Strkr, it uses typed action nodes. Send SMS routes through Strkr Messaging. Send Email composes through the native email stack. HTTP request calls out to an allowlisted external endpoint. The admin configures each action once; the bot picks it up with no additional glue code.

Pause and resume

Bots can wait for human approval.

A bot can pause for a configured approval, resume on a timer, or wait for a specific record change. A renewal bot drafts a pitch, waits for the CSM to approve, and then schedules the follow-up. The pause-and-resume primitive turns a long-running motion into one bot rather than a chain of webhooks.

Error branch

Named failure paths on every node.

Every node has an error branch. A failed classification routes to human review. A failed external HTTP call retries with backoff. A failed write routes to a flagged admin task. The bot has defined behavior under failure, which distinguishes a production bot from a brittle demo recording.

Governance for robotics process automation

The posture that keeps bots production-safe.

Classic RPA stalled in enterprise deployments because governance was an afterthought. The bots got written by whichever admin had capacity, nobody tracked which bots touched which fields on which objects, and the first time a bot wrote something questionable in production the whole program got paused because nobody could bound the blast radius. Strkr builds the governance posture into the product. Field allowlists, approval workflows on changes to production bots, prompt and node version history, residency pinning, PII masking, rate caps, and a per-tenant execution log. The admin configures the posture once at the tenant level and every new bot inherits it. The compliance review on a new bot takes minutes rather than weeks.

Field allowlists

Bots touch only fields the admin named.

Per object, the admin lists the fields a bot is allowed to write. The validator refuses any flow that writes outside the list. Compliance walks the allowlist in plain English rather than reading flow source. A new field added to an object is implicitly out of scope until the admin adds it to the allowlist.

Production marking

Prod flows require a second approver.

Any bot marked production requires a second admin to approve the diff before the change promotes. The diff view shows node changes, prompt changes, allowlist changes, and schedule changes. Nothing slides into prod on one keystroke, and emergency changes go through the same gate with a visible override log.

Rate caps

Protection against misconfigured upstream triggers.

Every bot carries a rate cap. The default caps ship conservative so a misconfigured upstream trigger cannot fire a million runs on a Saturday. A spike that would have crashed a brittle RPA installation routes to the overflow queue and surfaces a flag for the admin on Monday morning.

Residency pinning

Runs stay in the configured region.

A bot pinned to a region executes, reads, writes, and logs inside that region. The admin configures the posture at the tenant level, every new bot inherits, and the validator fails any flow that attempts to escape the pinned region. The EU admin running a bot on an EU record never sees the data leave the region.

PII masking

Sensitive fields do not reach the model.

Fields marked PII mask before any Strkr AI node inside the bot sees the record. The step processes the row, writes the allowed outputs, and never had access to the forbidden fields. The posture lives in the step, not in a wrapper the admin can bypass by mistake.

Audit log

Every bot run leaves a row.

The audit log carries one row per bot run with the trigger, the service account identity, the input, the resulting field changes, and the elapsed time. Investigations walk the log in Strkr; nothing lives in a vendor console the SOC has to pull a quarterly export from.

Approvals in-flow

A bot can require a human sign-off.

A bot step can pause the flow and emit a task to a configured approver. The approver reviews the proposed change, approves or edits, and the bot resumes. Approval tasks live in the standard task inbox, not in a separate workflow queue the approver would have to learn.

Prompt version history

Reasoning changes carry a diff.

Prompts inside bot reasoning steps behave like source code. Every save creates a version with a diff. The admin pulls up any prior version, compares it against the current one, and reverts in two clicks. Audits connect disputed bot outputs to the exact prompt version that produced them.

Kill switch

One toggle to stop a misbehaving bot.

Every bot has a kill switch on the admin view. One click pauses the bot across the tenant immediately and emits a system notice to every admin. The paused state preserves the run history and the config, so the admin diagnoses from a frozen state rather than a running one.

How robotics process automation plugs into the rest of Strkr

The bots talk to every object and every surface.

The payoff of a native RPA layer shows up in the second week. Admins stop building glue between the bot and the records; the record is where the bot already lives. A bot that scores a lead can write back to the lead on the next line. A bot that drafts a renewal pitch can post the draft to the account activity timeline, log the task, and schedule the follow-up in one canvas. Strkr builds the integration natively because the bot reads from and writes to the same object model the rest of the product does.

CRM records

Account, deal, lead, contact, custom objects.

Bots read and write every object the humans touch, with field-level and row-level permissions enforced on the service account. A bot updating a deal looks exactly like a rep updating a deal in the audit log, with the service account identified as the actor.

Strkr Messaging

SMS and MMS as a native action node.

A Send SMS node routes through Strkr Messaging with the full consent, opt-out, and quiet-hours policy applied. The bot composing a renewal nudge over text does not need a separate carrier config, a second compliance review, or a separate audit log.

Forecasting

Bot-updated fields flow into the forecast.

When a bot updates a deal risk score or shifts a close date, the forecast rollup reflects the change on the next read. There is no nightly batch job stitching the bot outputs back into the forecast model. The forecasting page and the automation canvas share a database.

Reports

Every bot-written field is a report column.

The field a bot wrote is a report column the admin can pivot, filter, and chart. Build a dashboard on bot-written risk scores. Pin a chart on bot-triggered churn tier movements. The output of a bot is first-class data, not a side table only the bot owner understands.

Documents module

Bots read the wiki for context.

A bot composing a support response reads the current troubleshooting article from the Strkr Documents module. A bot drafting a sales email reads the current objection-handling note. The retrieval is native; the bot references versioned content.

Projects module

Sprint, release, and backlog bots.

Projects admins run bots on sprint and release records with the same canvas, the same node palette, and the same governance posture. A sprint recap bot composes a Friday summary. A release bot drafts notes from merged pull requests. The automation story is one story across the product.

API ingress

External events trigger native bots.

An external system posts an event over the Strkr API, the matching bot runs on the payload, and the response threads back through the same API. The telemetry pipeline from a product feature feeds a usage-signal bot that nudges a save play. The API is the integration surface.

Scheduled runs

Bots run on cron, not just triggers.

Schedule a bot nightly, hourly, or at a specific hour each weekday. The weekly reporting bot runs Sunday evening and the pipeline brief lands at 06:30 Monday. The scheduler is first-class on the flow canvas rather than a separate scheduling product.

Dev to prod promotion

Three lanes with real approvals.

Bots carry a dev, staging, and production lane. Changes move through each boundary with approvals. Prod never surprises the team because staging reads exactly the same version prod will see next. The promotion is a product feature, not a Pulumi script maintained on an admin laptop.

Robotics process automation that lives in the record, not on a Windows desktop with a UI scraper.

Nine prebuilt bots cover lead routing, deal updates, renewal prep, support triage, pipeline hygiene, forecast scrubbing, expansion sweeps, reporting, and record merging. All runs are observable, retried, idempotent, and audited. On every paid tier with no credit meter.

Start free See flows
Common questions

What buyers ask about this feature.

What is robotics process automation and how does Strkr handle it differently from classic RPA?

Robotics process automation is the set of bots that run on records continuously without a human opening the UI. The classic shape (UiPath, Automation Anywhere, Blue Prism) installs a desktop agent and teaches it to click through a browser, which fits scenarios where the applications do not integrate and no shared database exists. Strkr is a CRM where the pipeline, messaging, assistant, forecasting, documents, and reporting all share a database and a permission model, so the bots live inside the product as typed workflow nodes rather than UI-scraping scripts. The admin builds a bot on the same canvas as every other flow, and the bot reads and writes records directly with full observability, retries, audit logging, and governance. No desktop agent, no screen recording, no browser-update-brittle maintenance cycle.

Which robotics process automation bots ship out of the box in Strkr?

Nine production-grade bots: lead routing (owner inside 60 seconds, hierarchy-aware), deal updates (stale deals, missing close plans, champion gaps), renewal prep (120-day briefings with drafted narratives), support triage (severity, product area, routing, extracted summary), pipeline hygiene (eight nightly scrub categories), forecast scrubbing (rep-called vs model-called disagreements), expansion sweep (seat ceiling, stakeholder, feature-flag signals), reporting bots (weekly brief, pipeline snapshot, churn watchlist), and record merger (duplicate book cleanup with hierarchy preservation). Each one ships configurable, runs under the tenant governance posture, and is editable on the standard flow canvas rather than in a specialist RPA studio.

Can we build custom robotics process automation bots or only configure the prebuilt ones?

Any admin with the flow builder role can compose new bots on the canvas. The nine prebuilt bots ship enabled and configurable; the admin can clone any of them as a starting point. New bots use the same node palette: triggers (record change, schedule, API event, button), read nodes with typed queries, reasoning steps (Classify, Extract, Draft, Score, Summarize, Decide, Compare, Verify, Chain), branch and loop primitives, write nodes under permission allowlists, external action nodes (SMS through Strkr Messaging, email through the native stack, HTTP to allowlisted endpoints), pause-and-resume for human approval, and typed error branches. The admin builds a non-trivial bot in minutes without leaving the Strkr UI, and the bot inherits every governance control configured for the tenant.

How does Strkr handle the governance posture around RPA that often stalls classic RPA deployments?

Nine controls apply by default. Field allowlists per object limit which fields a bot may write; the validator refuses to save flows that write outside the list. Production marking requires a second admin to approve diffs before any change promotes, with the diff view showing node, prompt, allowlist, and schedule changes. Rate caps protect against misconfigured upstream triggers firing in a loop. Residency pinning keeps execution, data, and logs inside a chosen region, with the validator refusing flows that escape. PII masking hides sensitive fields from reasoning steps. The audit log records every bot run with trigger, service account, input, resulting changes, and elapsed time, retained per the tenant retention policy. In-flow approvals pause bots for human sign-off. Prompt version history carries a diff on every save. A kill switch pauses a bot across the tenant in one click. The posture configures once at the tenant level and inherits to every new bot.

What happens to the audit trail when robotics process automation bots run in Strkr?

Every bot run lands in the Strkr audit log alongside human actions. The log carries the trigger, the service account identity, the inputs the bot received, the outputs it emitted, the field changes it wrote, the elapsed time, and the model that handled any reasoning calls. A compliance reviewer walks one log, filters by actor type or by date range, and finds bot activity in context with human activity. The retention matches the tenant retention policy. There is no vendor dashboard three logins away hoarding the information, and no quarterly export cycle to reconcile a specialist RPA console against the business system of record. The log is the single source of truth for both human and bot actions on the tenant.

Does Strkr RPA replace tools like UiPath or Automation Anywhere entirely?

For the specific class of jobs that live inside the CRM (lead routing, deal updates, renewal prep, support triage, pipeline hygiene, expansion sweeps, reporting, record merging), the native approach replaces classic RPA entirely because the bots read records directly rather than scraping a browser. For jobs that span unrelated applications (reading from a bank portal, writing to an ERP that lacks an API, bridging data between two legacy mainframe systems), a specialist RPA tool may still make sense. The honest framing is that the native CRM bots cover every revenue-adjacent motion. Teams that still have genuine cross-application UI-scraping needs run those on a specialist RPA tool and integrate the output back into Strkr through the API ingress surface, which keeps the audit log and the governance posture coherent on the Strkr side.

Related features

Pair this with...

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