Feature · Code Automation

Code automation: low-code for the 95 percent, hooks for the edge cases.

Most revenue workflow automation is low-code and does not need to be anything else. The remaining five percent needs a code hook: a custom lookup, a non-standard payload transform, a calculation the condition engine cannot express cleanly. Strkr ships both: the visual Flow canvas for the 95 percent and JavaScript or TypeScript script blocks for the edge cases, with the deploy pipeline, versioning, test harness, and audit trail wrapped around both.

Start free trial See pricing

The low-code floor and the code ceiling

Which 95 percent is low-code and which 5 percent needs a hook.

Workflow automation is often framed as a choice between low-code and code. The clearer framing is that most workflow is low-code and the remaining tail needs a code hook. The split depends on the business pattern. For revenue teams, 95 percent of flows fit the standard trigger-condition-action pattern that a visual canvas handles cleanly. The remaining 5 percent needs a hook: a custom lookup, a non-standard transformation, a calculation the condition engine cannot express. This section walks the places code hooks earn their place and the places they do not.

What belongs on the canvas

Standard trigger, condition, action flows.

Standard trigger-condition-action flows belong on the visual canvas. Discount approval chains, contract routing, onboarding motions, renewal cadences, QBR scheduling, sales-to-CS handoffs. The visual canvas handles the pattern with the right readability, the right version control, and the right audit evidence. Writing this flow set in code would produce a thousand lines of fragile glue that nobody could maintain two years from now.

What needs a code hook

Custom calculation, non-standard payload, external logic.

The right split

Canvas owns the flow, hook owns the one node.

The right pattern is canvas-owns-the-flow and hook-owns-the-one-node. The flow definition lives on the visual canvas with the triggers, conditions, actions, and the overall shape. The code hook sits as a node on the canvas with its own test harness and version history. The pattern keeps the operating readability of the visual canvas while unlocking the custom logic for the 5 percent that genuinely needs it.

The wrong split

Code owns the flow, canvas owns a dashboard.

The wrong pattern is code-owns-the-flow and the canvas becomes a dashboard. Teams that build the whole flow in code typically produce something that works initially and becomes a maintenance liability within eighteen months. The sales ops lead who could edit the visual canvas cannot edit the code, which routes every policy change through an engineering ticket. The pattern collapses the velocity gain that the canvas was meant to provide.

When code hooks are tempting

When the business logic feels too complex for the canvas.

Code hooks feel tempting when the business logic feels too complex for the canvas: nested conditions, cross-record lookups, calculated field combinations. The temptation is often a signal that the business logic is unclear rather than that the canvas is insufficient. Teams that resist the code hook temptation on the first pass usually find that the clarification conversation produces a cleaner policy that the canvas can express.

When code hooks are necessary

When the calculation is genuinely vendor-specific.

Code hooks are necessary when the calculation is genuinely vendor-specific: a pricing optimization that uses a proprietary formula, a routing rule that depends on an external service, a webhook payload transformation that does not match any standard parser. Each case is a business reality rather than a logic complexity signal. The code hook earns its place because the alternative is a hundred-block flow that nobody can read.

The portfolio balance

Most teams end up with 5 to 10 code hooks total.

Across the mid-market revenue teams we see on Strkr, the typical portfolio balance is 100-500 flows on the visual canvas and 5-10 code hooks total. The code hooks are owned by the admin team or a engineer embedded in RevOps rather than by the full engineering function. The pattern keeps the engineering surface narrow enough to maintain while unlocking the capability the canvas cannot cover.

The anti-pattern to avoid

Reach for a code hook before trying the condition engine.

The anti-pattern to avoid is reaching for a code hook before trying the condition engine. The condition engine handles three-level lookups, AND/OR composition, nested groups, and the common calculation primitives. Most logic that feels like it needs a code hook on first inspection expresses cleanly as a condition expression with a thirty-minute study of the operator set. The code hook should be the second option, not the first.

The script block

JavaScript or TypeScript hooks inside the flow canvas.

The code hook primitive in Strkr Flow is the script block. The script block sits on the canvas as a node with inbound and outbound ports, executes JavaScript or TypeScript against the flow context, and returns a result that downstream blocks consume. The script block is a first-class node rather than a bolt-on extension, which means the versioning, audit trail, and test harness primitives of the canvas wrap around it.

JavaScript or TypeScript

Pick the language per block.

The script block supports both JavaScript and TypeScript. Admins pick per block based on team preference. TypeScript is the default for new blocks because the type checking catches common errors at build time rather than runtime. JavaScript is available for teams that prefer the lighter syntax. Both languages share the same runtime, the same context access, and the same deploy pipeline.

The context object

The flow context handed in, the result handed out.

The script block receives the flow context (the record set, the trigger payload, the user identity, the policy version) as a typed context object. The block returns a result object that downstream blocks reference by field. The pattern keeps the script boundary clean: data in through the context, data out through the result. No side effects that reach outside the result object, no mutation of the record set without going through the standard action blocks.

Inline test harness

Test the script against sample records before publishing.

Every script block has an inline test harness that lets the author run the script against sample records and inspect the result object before publishing. The test harness renders the input context, the script execution, and the result object side by side. The pattern catches the common script errors (type mismatches, null handling, edge cases) at design time rather than at the first production run.

Version history

Every script change recorded on the canvas version history.

Every change to a script block records on the canvas version history alongside the visual block changes. The pattern unifies the version history across code and canvas changes, which means the audit trail reads coherently rather than splitting into two separate tracks for the two types of changes. The required change message applies to script changes just like it applies to canvas changes.

Runtime isolation

Scripts run in isolated sandboxes with resource limits.

Scripts run in isolated sandboxes with memory, CPU, and execution time limits. A runaway script hits the limit and terminates with an error rather than impacting the broader platform. The isolation pattern is the standard cloud sandbox pattern used by serverless function platforms, which has been battle-tested across the industry at scale. Scripts cannot reach outside the sandbox except through the context object and the result object.

Available libraries

A curated standard library, no arbitrary npm installs.

Scripts have access to a curated standard library covering the common needs: date manipulation, string manipulation, number formatting, JSON parse and stringify, cryptographic hashing, UUID generation. Arbitrary npm installs are not available, which keeps the supply-chain attack surface narrow. For teams with specific library needs outside the standard set, the open API supports external HTTP calls to a vendor-managed service that encapsulates the logic.

Error handling

Script errors route to the dead-letter queue.

Script errors (uncaught exceptions, timeout, resource limit) route to the dead-letter queue with the full input context, the error details, and the stack trace. The dead-letter queue is a first-class view in the admin console with the record context and a one-click replay once the underlying issue is resolved. The pattern replaces the "the script broke, nobody knew" failure mode with explicit error handling and admin visibility.

Performance monitoring

Per-script execution time tracked in the dashboard.

Script execution time, memory usage, and error rate land on the per-flow dashboard alongside the standard flow metrics. The ops lead sees which scripts are running long, which are hitting limits, and which are producing errors. The data drives optimization decisions and surfaces the scripts that have grown over time into performance liabilities. The pattern lets the admin team manage the script portfolio with the same operating cadence as the canvas portfolio.

The deploy pipeline

Script changes follow the lifecycle, not a cowboy deploy.

Script changes follow the same lifecycle as canvas changes: draft, review, published, deprecated, retired. The pattern eliminates the common failure mode on code hooks where an admin pushes an unreviewed change to production because the code tooling let them. The deploy pipeline wraps the script primitives in the same change management controls that apply to the rest of the automation portfolio, which keeps the compliance posture consistent across code and canvas.

Draft state

Script changes live on the draft flow.

Script changes live on the draft flow with the containing block in draft state. The draft version runs in the test harness without affecting the published version. The pattern lets the script author iterate on changes while the published version continues to run against live records, which eliminates the risk of accidentally saving a half-edited script into production during a long debugging session.

Review state

Required reviewer approves before publishing.

Script changes typically require a reviewer approval before publishing. The reviewer sees the diff against the current published version, inspects the test harness results, and clicks approve to publish or request changes to send back to draft. For regulated industries, the review state is required. For other teams, review is often required specifically on script blocks even if it is optional on canvas changes, because scripts carry higher audit sensitivity.

Publish event

The publish records the full script snapshot.

When the reviewer approves and the author publishes, the publish event records the full script snapshot with the publishing user, the timestamp, the required change message, the diff against the previous version, and the reviewer identity. The audit trail references the script version that ran against each record, which means historical records always resolve against the script version that was in force at the time.

Rollback

Any prior script version rolls back with a click.

Any prior script version in the history can be rolled back to with a single click. The rollback creates a new publish that points back to the earlier script definition and records the rollback with a required reason message on the audit trail. The pattern handles the "something broke, revert the Monday change" case without a git-level operation or a replay.

Dependency tracking

Scripts show up in the dependency graph.

Script blocks show up in the dependency graph alongside canvas blocks. Changing a script that other flows depend on surfaces the dependencies in the change impact preview before publishing. The pattern keeps script changes from cascading unexpectedly into downstream flows, which is a common failure mode when scripts are maintained outside the dependency tracking.

Owner assignment

Scripts carry a named owner like every other block.

Every script block carries a named owner (typically the admin or embedded engineer who maintains the script) and a business sponsor (the business leader whose policy the script implements). The owner assignment eliminates the ownership drift that typically compounds on code artifacts over time, which is one of the most common sources of code hook failure on multi-year tenures.

Documentation

Scripts carry a required description note.

Every script block carries a required description note that explains what the script does, which policy it implements, which inputs it reads, which outputs it produces, and what the edge cases look like. The documentation lives on the block definition rather than in a side wiki, which means it stays current as the script evolves. The pattern eliminates the "nobody knows what this script does anymore" failure mode on legacy code.

Retirement workflow

Scripts retire through the same workflow as canvas flows.

Retiring a script block follows the standard retirement workflow: proposal, dependency check, deprecation period, successor cutover, in-flight drain, full retirement. The pattern applies to script blocks the same way it applies to canvas flows, which keeps the retirement discipline consistent across the portfolio. Scripts that are no longer needed retire cleanly rather than persisting as dead code with no owner.

When code automation goes wrong

The failure modes to avoid.

Code automation goes wrong in specific ways. Teams that recognize the failure modes early can avoid them. Teams that do not recognize them typically end up with a code hook portfolio that becomes a maintenance liability within two years. This section walks the four most common failure modes we see across teams and the pattern to apply to each one.

Failure mode one

The code hook that nobody maintains.

A code hook written in year one by an engineer who has since left the company. Nobody has reviewed it in two years. The script references deprecated API endpoints that still work but will stop working in the next quarter. The owner field is empty. The pattern breaks when the dependency finally retires and the flow stops. The fix is explicit ownership assignment on every script block at creation time, with the ownership review as part of the quarterly flow portfolio review.

Failure mode two

The code hook that grew into a monolith.

A code hook that started as a calculation and grew over three years into a four-hundred-line script with ten conditional branches, five nested loops, and three external API calls. The business logic the script implements has drifted from what the business sponsor would recognize. The pattern breaks when a policy change requires a review that nobody wants to run. The fix is explicit decomposition: break the monolith back into canvas blocks where possible and keep the irreducible calculation in a smaller focused script.

Failure mode three

The code hook with no test harness coverage.

A code hook with no test cases in the inline test harness. The author published without running the test harness because the script worked on the first production record. The script fails on the second production record that trips an edge case the author did not consider. The pattern breaks under production edge cases that the author did not anticipate. The fix is required test harness coverage before publishing, which the review state can enforce for teams that need the governance.

Failure mode four

The code hook that bypasses the condition engine.

A code hook that implements logic the condition engine would handle cleanly. The author chose the code hook because they were more comfortable in code than in the condition builder. The pattern creates a maintenance liability that the admin team cannot edit without the author's help. The fix is a review discipline: for every code hook proposal, confirm the condition engine cannot express the logic cleanly before approving the hook.

The right discipline

Code hooks are a last resort, not a first option.

The right discipline is treating code hooks as a last resort rather than a first option. For every proposed hook, the admin team asks whether the condition engine, a sequence of standard action blocks, or a different flow structure would cover the need. The code hook ships only when none of the alternatives work. The pattern keeps the code portfolio narrow enough to maintain while leveraging the primitives the canvas provides.

The right review cadence

Every code hook reviewed quarterly.

The right review cadence is a quarterly review of every code hook: the owner confirms the hook is still needed, the business sponsor confirms the policy is still current, the admin team runs the test harness coverage. Hooks that fail the review retire through the standard retirement workflow. The quarterly cadence prevents the "we have no idea what these scripts do" state that otherwise compounds over multi-year tenures.

The right size

A code hook should fit on one screen.

A healthy code hook typically fits on one screen (under 50 lines) with a focused purpose and clear inputs and outputs. Hooks that grow beyond one screen are usually candidates for decomposition. The size discipline matches the module-size discipline that mature engineering teams apply to their broader codebase, and it keeps the maintenance burden proportional to the business value.

The right test coverage

At least three test cases per hook: happy, edge, failure.

A healthy code hook typically has at least three test cases in the inline test harness: the happy path (standard record), the edge case (null handling, zero quantity, missing field), and the failure case (invalid input, external service unavailable). The three cases catch the most common failure modes. For hooks with higher risk, additional test cases cover the conditions the business sponsor cares about.

Code automation on every paid tier, hooks on the canvas.

Script blocks (JavaScript or TypeScript), inline test harness, versioning on the canvas history, draft and review lifecycle, dependency tracking, dead-letter queue, performance monitoring, and the full audit trail ship on every paid tier. No separate scripting module, no engineering-only edition, no per-execution meter.

Start free trial See pricing

Common questions

What buyers ask about this feature.

When should we use a code hook rather than the visual canvas?

Code hooks earn their place for specific edge cases: a custom calculation (margin optimization with a vendor-specific formula), a non-standard payload transformation (an external vendor's webhook that does not match the standard parse), or external logic (a pricing policy the condition engine cannot express cleanly). The right discipline is treating code hooks as a last resort rather than a first option. For every proposed hook, the admin team asks whether the condition engine, a sequence of standard action blocks, or a different flow structure would cover the need. The code hook ships only when none of the alternatives work. Across the mid-market revenue teams on Strkr, the typical portfolio balance is 100-500 flows on the visual canvas and 5-10 code hooks total.

What languages do the script blocks support?

Can scripts call external APIs?

Yes. Scripts can make outbound HTTP calls to external services with the standard fetch primitive. The outbound calls route through the standard Strkr webhook infrastructure, which handles retries, rate limiting, and audit logging. For sensitive integrations (payment processors, PHI-adjacent services), the webhook infrastructure also handles secret management through the standard credential store rather than requiring secrets inline in the script. The pattern keeps the secret management posture consistent across code and canvas calls.

How does the test harness work?

Every script block has an inline test harness that lets the author run the script against sample records and inspect the result object before publishing. The test harness renders the input context, the script execution, and the result object side by side. Authors can save specific test cases for recurring regression testing. The required test coverage before publishing is a tenant-configurable policy, with the common pattern being at least three test cases per hook (happy path, edge case, failure case).

What is the audit evidence shape for script changes?

Every change to a script block records on the canvas version history alongside the visual block changes. The audit trail captures the full script snapshot at the publish event with the publishing user, the timestamp, the required change message, the diff against the previous version, and the reviewer identity. Historical records reference the script version that ran against them, which means audit evidence resolves against the policy that was in force at the time rather than the current one. SOC 2 Type II certification is in progress through 2026-Q4 and the script audit evidence is shaped around the change management control area.

Can we see which scripts are performance-heavy?

Yes. Script execution time, memory usage, and error rate land on the per-flow dashboard alongside the standard flow metrics. The ops lead sees which scripts are running long, which are hitting resource limits, and which are producing errors. The data drives optimization decisions and surfaces the scripts that have grown over time into performance liabilities. The pattern lets the admin team manage the script portfolio with the same operating cadence as the canvas portfolio, with the quarterly review cycle covering both script performance and script relevance.

Related features

Pair this with...

Low-Code Automation Low-Code Process Automation Low-Code Workflow Automation Tools No-Code Automation Business Workflow Automation Workflow Automation

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