Feature · Flexible Automation

A flexible automation platform that bends to the business, not vice versa.

Flexible is the hardest adjective to earn in automation marketing. Every platform claims it, few deliver it. Flexible means the platform supports the common case out of the box, the uncommon case with a custom node, and the long-tail case through an API escape. It means the data model is typed but extensible, the flow canvas is no-code but supports TypeScript injection, and the pricing stays flat as the team grows into power-user territory. Strkr covers that whole range on one platform with flat seat pricing.

Start free trial See pricing
What flexibility means in practice

The seven axes of real flexibility.

Flexibility along one axis is table stakes. Flexibility along seven axes is a real moat. The axes below are where buyers actually need the platform to bend when the business does something the vendor did not anticipate.

Data model axis

Custom objects and custom fields.

Flexibility starts with the data model. A platform where admin can add custom objects (not just custom fields on standard objects) covers the long tail of use cases. A platform locked to the vendor's objects leaves the long tail to a parallel universe of integrations.

Flow surface axis

No-code with code escape.

A flow surface that is no-code by default and supports code injection for the uncommon case covers the breadth. No-code only leaves the power user in the lurch. Code-only loses the admin audience. The hybrid is what covers both.

Tool axis

Stock catalog plus custom TypeScript nodes.

A tool catalog that covers the common integrations (Stripe, Slack, HubSpot, Google Workspace) out of the box, plus the ability to ship custom TypeScript nodes for the uncommon case, is the right balance. Vendors that lock the catalog leave the uncommon case to pay-per-connector marketplaces.

Trigger axis

Records, webhooks, schedules, email.

Triggers from every direction: record events, webhook ingress, schedules, inbound email, Stripe signatures, Slack events. The flexibility is in the trigger surface, because the business event does not always come from the CRM record.

Composition axis

Nested flows and shared steps.

Nested flows let one flow call another as a sub-routine. Shared steps let a library of reusable logic exist. Flat flows that cannot nest become 400-step monsters nobody maintains. The composition axis is what keeps the flow surface sustainable.

Permission axis

Role-based with per-field overrides.

Role-based permissions with per-field overrides let the platform model real-world org structures. Flat permissions (admin and user) do not model the real world. The permission flexibility is a prerequisite for enterprise adoption.

API escape axis

Open REST and GraphQL on everything.

An open API that covers every record, every event, every flow run, every audit entry is the ultimate flexibility hatch. A team that outgrows the canvas can keep the data and rebuild the orchestration externally. The API escape makes the platform exit-friendly, which paradoxically increases stickiness.

Where platforms differ

Five axes that separate real flex from marketing flex.

Platforms that call themselves flexible often mean "has a few config options." Real flex is multi-dimensional. The axes below are where the delta shows up on the first real customization request.

Custom objects

Full objects vs field extension only.

Platforms that support fully custom objects (with CRUD, with permissions, with reports, with relationships) cover the long tail. Platforms that only extend standard objects with custom fields hit a ceiling fast when the business needs a new entity.

Code injection

TypeScript nodes vs none.

Platforms with TypeScript injection on flow nodes let the power user cover edge cases without leaving the platform. Platforms without code injection send the power user to a third-party integration layer, which splits the automation surface across tools nobody can audit together.

Custom integrations

Custom node builder vs marketplace-only.

Platforms where admin can ship a custom integration node in a day of work cover the long tail. Platforms that require everything to come from a marketplace leave the uncommon integration to a six-month vendor engagement.

Permission depth

Field-level vs object-level.

Field-level permissions let enterprise model real-world access rules. Object-level permissions hit a ceiling when the business needs "sales reps see the opportunity but not the margin field." The depth matters at enterprise scale.

API coverage

Full API vs integration-only.

Full API coverage on every record, event, and flow run is a flexibility hatch. Integration-only API (just the sync connectors, not the records) is lock-in disguised as flexibility. The API coverage predicts exit cost.

What Strkr ships for flex

The flexibility surface, in detail.

Fully custom objects with CRUD, permissions, reports, and relationships. TypeScript injection on any flow node. Custom integration node builder. Field-level permissions with role and record overlays. Open REST and GraphQL API on every record, event, flow run, and audit entry. Nested flows and shared step library. Flat $50 per seat.

Custom objects

Full objects, not just extensions.

Admin can create fully custom objects with their own fields, their own permissions, their own report queries, and their own relationships to standard objects. A healthcare tenant can model Specialty, Protocol, Study. A services firm can model Practice, Methodology, Deliverable. The data model bends to the business.

TypeScript injection

Code node on any flow.

Any flow node can be a TypeScript injection node. The author writes the custom logic in TypeScript with typed inputs and outputs. The node runs in a sandboxed runtime with audit on every call. The common failure where "no-code is too shallow for this case" does not happen because code is the escape hatch.

Custom integrations

Ship a connector in a day.

Admin can build a custom integration node that calls any REST or GraphQL endpoint with typed inputs and outputs. The node joins the tool catalog and is reusable across flows. The common failure where a required integration is three months away in the vendor backlog does not happen because the escape is in-tool.

Field permissions

Role-based with record overrides.

Field-level permissions by role, with per-record overrides. A rep can see Opportunity.amount but not Opportunity.margin. A regional lead can see Opportunity.margin for their geo but not for other geos. The permission flexibility covers real-world enterprise access rules.

Nested flows

Flows call flows as subroutines.

Flows can invoke other flows as subroutines with typed inputs and outputs. A shared "send notification" flow gets called from 40 upstream flows. Updating the shared flow updates everywhere. The common failure where 400-step monster flows exist does not happen because composition is first-class.

Open API

REST and GraphQL on everything.

Every record, every event, every flow run, every audit entry is accessible via REST and GraphQL API. A team that outgrows the canvas can rebuild orchestration externally without a data migration. The exit cost is measurable in script-writing hours.

Where teams actually land

Three deployment patterns from real customers.

A SaaS with product-side use cases, a services firm with methodology customization, and a healthcare company with specialty-level data all exercise different flexibility axes. The platform supports all three on one license.

SaaS pattern

Custom objects for product data.

A 90-seat SaaS created custom objects for Feature Request, Product Signal, and NPS Response. Each has its own permissions, reports, and relationships to Account. The product and GTM teams share the data model without a sync tool.

Services firm

Custom integration to the practice tool.

A 220-seat services firm built a custom integration to its practice-specific delivery tool (a vertical SaaS) in two days. The node joined the tool catalog, called from 15 project workflows. The common failure where the long-tail integration is a six-month engineering project did not happen.

Healthcare pattern

Specialty-level permissions.

A 340-seat healthcare company configured specialty-level permissions. A pediatric clinician sees pediatric patient records; a cardiology clinician sees cardiology records; both see shared general records. The field-level permission flexibility covered the real-world access rule.

Shared flow library

Reusable sub-flows across departments.

A 150-seat company built a shared flow library: send-notification, log-audit-event, lookup-contact, enrich-account. Every department invokes the shared flows from their own workflows. Maintenance happens once, not 40 times.

TypeScript injection

Edge-case logic without a platform swap.

A customer had a one-off requirement to compute a region-specific tax rate using a jurisdiction lookup API. They dropped a TypeScript injection node into the invoice flow, called the API, and shipped. The common failure where "no-code hit a wall and we need a different platform" did not happen.

Exit posture

Full export via open API.

Every record, every flow run, every audit entry is exportable via the open API. A team that chooses to rebuild externally can export the full state in hours. The flexibility is cheaper to escape than it is to stay in; paradoxically, that increases stickiness.

A flexible automation platform that holds up at year three.

Strkr ships custom objects, TypeScript injection, custom integration nodes, field-level permissions, nested flows, and open API coverage on every surface. Flat $50 per seat.

Start free See pricing
Common questions

What buyers ask about this feature.

What makes an automation platform truly flexible versus marketing-flexible?

Marketing-flexible platforms claim flex because they let you change a flow timing or add a custom field. Real-flex platforms bend along seven axes: data model (custom objects, not just custom fields), flow surface (no-code with code escape), tool catalog (stock plus custom nodes), triggers (every direction), composition (nested flows and shared steps), permissions (field-level with role and record overlays), and API escape (open REST and GraphQL on everything). A platform that scores high on one axis and low on five is called flexible in the brochure and inflexible in production.

Can we add custom objects, not just custom fields?

Yes. Admin can create fully custom objects with their own fields, permissions, reports, and relationships to standard objects. A healthcare tenant models Specialty, Protocol, Study as first-class objects. A services firm models Practice, Methodology, Deliverable. A product-led SaaS models Feature Request, Product Signal, NPS Response. The custom objects behave like standard objects for every downstream feature (flows, reports, dashboards, permissions).

What if we hit a wall with the no-code canvas?

Drop a TypeScript injection node into the flow. The injection node accepts typed inputs, runs custom TypeScript in a sandboxed runtime, and returns typed outputs. The common pattern is that 95% of flow logic is no-code and the 5% edge cases are TypeScript. The platform does not force the team to swap to a different system when the edge case shows up; the code is the escape hatch, in-tool, with the same audit and observability as every other node.

How are custom integrations built?

Admin uses the custom integration node builder: declare the endpoint (REST or GraphQL), the auth method (OAuth 2.0, API key, HMAC), the typed inputs and outputs, and the rate-limit profile. The node joins the tool catalog and is reusable across flows. Teams typically ship a custom integration in a day of work. The common failure where a required integration is three months out in the vendor backlog does not happen.

How do field-level permissions work in practice?

Permissions are role-based with per-record overrides at the field level. A rep role can read Opportunity.amount but not Opportunity.margin. A regional-lead role can read Opportunity.margin for records in their geo but not for other geos. The permission is enforced on the API, so integrations respect the same rules. The common failure where field-level permissions work in the UI but leak through the API does not happen because the enforcement is server-side.

How is this priced versus platforms with per-feature add-ons?

Strkr is flat $50 per seat on every tier. Custom objects, TypeScript injection, custom integration nodes, field-level permissions, nested flows, and API coverage are all included. Platforms with per-feature pricing penalize the exact flexibility the buyer is paying for; a team that uses five flexibility axes pays five surcharges. The pricing shape matters because flexibility compounds, and the compounding should not be metered.

Related features

Pair this with...

AI Automation Platforms Automation Platforms Custom Objects Custom Fields Automation Workflows Automated Workflow Management Full-Service Automation Tools

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