Strkr Flows runs the automation engine; the native integration lattice provides the connectors. Salesforce, Google Workspace, Microsoft 365, Slack, Strkr Messaging, and outbound webhooks are callable actions from any Flow. One permission model, one audit log, no per-task meter.
Workflow integration is the discipline of making your automation engine reach outside the system it lives in. The classic approach is an iPaaS (Workato, Tray, Zapier) sitting between the CRM and every third-party system, routing events through a middleware tier. The problem is that the middleware tier costs money per run, maintains its own permission model, and holds its own audit log. Strkr's approach is different: the integrations are native actions inside the same runtime that reads the CRM. No middleware, no per-task meter, one audit log.
A Salesforce write, a Gmail send, a Slack post, a Google Calendar event: each one is a callable action in the Flow builder, not a webhook out to a middleware service. The action runs in the same transaction as the records it touches. If the Flow fails, the integration call rolls back cleanly.
Each integration is attached to a user via OAuth or a tenant service account. The Flow runs as its owner by default and inherits the owner's integration access. If the owner has not connected Gmail, the Gmail-send action in that Flow fails cleanly with a permission error. No separate middleware IAM to configure.
The Flows audit log records every integration call: which action, which Flow, which user, which record, which output. Compliance pulls one log, not six. SOC 2 Type II and ISO 27001 auditors have the full integration trail without a special export from the middleware vendor.
Workato prices by recipe. Zapier prices by task. Tray prices by workflow. Strkr prices by seat. A Flow that calls Salesforce, Google Calendar, and Slack in sequence costs the same as a Flow that only writes to the CRM. The business incentive is to automate aggressively.
When a Salesforce sync writes to a Strkr contact, the next Flow that triggers on that contact sees the fresh data. No eventual-consistency gap, no separate caching layer. The integration and the automation share the same tables.
Transient integration failures (rate limits, timeouts, 5xx responses) retry with exponential backoff inside the runtime. Hard failures (missing OAuth, expired token, invalid payload) raise an error that lands in the dead-letter queue. The runtime handles the connectivity edge cases that an iPaaS middleman would otherwise handle.
Below is the list of native integrations available as callable actions inside Strkr Flows. Each one ships on Pro and above with no connector-count tier.
The Salesforce native integration syncs contacts, accounts, leads, and opportunities bidirectionally. A Flow can trigger on a Salesforce stage change (via webhook), run conditions, and write back to the Salesforce record. The classic "move the deal to the right stage based on signals in the thread" workflow runs end to end.
Per-user OAuth for Gmail (read, send, draft), Calendar (create event, update event), Drive (read file, write file). A Flow can read a Gmail thread as input, generate a reply via Strkr AI, and send through the native connector. Calendar events, meeting notes, and document drafts travel the same path.
Full parity with Google Workspace on the Microsoft side. Outlook mail, Teams messages, OneDrive files, Calendar events. A Flow can summarize a Teams thread the same way it summarizes a Slack thread. The integration is native, not a third-party middleman.
Post to a channel, DM a user, reply in a thread. A Flow can post the output of a condition evaluation to a Slack channel conditionally (if the deal is Red, post to the deal-ops channel with the one-line reason). The connector respects Slack permissions; Strkr does not post where the installing user does not have access.
SMS and MMS actions route through Strkr Messaging, the native carrier layer. A Flow can draft SMS replies with Strkr AI, send them, and listen for inbound. The classic sales SMS workflow (new lead, welcome SMS, wait for reply, draft follow-up) runs end-to-end inside Strkr with no third-party SMS tool to subscribe to.
For systems without a native connector, the outbound webhook action POSTs a configurable JSON payload to any URL. HMAC signing optional. Retries follow the same exponential-backoff pattern as native actions. The custom integration gap closes with one action, not a sidecar service.
Any third-party system that can POST JSON to a Strkr endpoint can fire a Flow with the payload. The runtime treats the inbound webhook identically to a native event. The pattern covers systems without a native connector; HMAC verification keeps the inbound path safe.
Any external service can act as a Flow trigger (via inbound webhook) or a Flow target (via the public REST API). The combination means a custom integration is achievable in an afternoon rather than a quarter, and the runtime handles the retry and audit concerns.
Below are the integration-crossing workflows we have watched produce visible ROI inside 30 days. Each one spans at least two systems and runs end-to-end inside Strkr Flows without a middleware layer.
When a deal moves to Proposal, Flow posts a formatted message to the #deal-ops Slack channel with the amount, the AE, and a link back. When a deal closes won, posts to #celebrations with a different template. The Slack notification layer that otherwise lives in a middleware service runs natively.
An inbound Gmail reply arrives on an AE account. Flow extracts the thread, Strkr AI classifies intent (interested, not interested, out-of-office, question), interested replies route to the AE with a prep brief, question replies create a task, out-of-office responses reschedule the next-touch. The integration-heavy chain runs in one Flow.
30 minutes before a Google Calendar event with a prospect, Flow reads the attendees, matches to CRM records, calls Strkr AI to compose a prep brief, writes the brief to the opportunity, and emails the AE. Three integrations (Calendar, CRM, Email) in one Flow with no middleware.
A marketing form submits. Flow writes to Strkr CRM, then writes to Salesforce (if the tenant runs a dual-system setup during migration). Both writes are atomic; if the Salesforce write fails, the Strkr write still succeeds and the Salesforce failure lands in the DLQ for replay once the credential is rotated.
Deal moves to Closed Won. Flow creates a Strkr Projects project (native), drafts a welcome email via Gmail (integration), creates a Google Calendar kickoff invite (integration), posts to #cs-handoffs on Slack (integration), writes a record to the billing system (webhook). One Flow, four integration surfaces, atomic.
A prospect replies to an SMS from Strkr Messaging. Flow parses the content, matches to the active opportunity, updates the deal activity, and if the content contains "schedule a demo" creates a Google Calendar hold with a tentative time. SMS to deal state in under 2 seconds.
An iPaaS running integration workflows across a dozen systems is a compliance challenge. Permissions, audit, data retention, and PII handling all have to be configured across the middleware and each endpoint. Strkr's native lattice collapses the governance surface because the integration runs inside the same tenant as the record.
Each OAuth connection (Gmail, Calendar, Slack, Salesforce) records the scopes granted. Admins see the full list on the Integrations page. Over-scoped connections (e.g., Gmail asked for full-mailbox when read-only would do) are visible and revocable. No middleware vendor holding scopes you cannot audit.
Gmail, Calendar, and Outlook connect per-user because mail is personal. Salesforce and Slack connect at the tenant level because they are team resources. The split is correct for the real world; teams do not get Gmail cross-contamination or Slack over-permissioning.
Fields marked sensitive at the tenant level (SSNs, bank accounts, health identifiers) are stripped from any payload sent to an integration. The redaction is non-overridable; admins see which fields are marked. External systems never receive the raw value.
The Flows audit log captures each integration call: which action, which Flow, which user, which record, which output. Pullable per-integration, per-user, per-Flow. SOC 2 Type II and ISO 27001 auditors review one surface instead of six separate vendor consoles.
Each tenant sets a retention policy for Flows audit records (30 days, 90 days, 1 year, 7 years). The retention applies to integration call logs because they live inside the Flows audit. No separate retention negotiation with each middleware vendor; the tenant's policy controls the whole surface.
Per-Flow and per-tenant rate limits prevent a misconfigured loop from flooding Salesforce or Slack. When a limit is hit, subsequent runs queue cleanly rather than hammering the downstream. The downstream vendor's rate limits are respected automatically.
Mid-market revenue orgs typically run their integration layer on Workato, Tray, Zapier, or a combination. Each one priced by recipe, task, or workflow. The native integration lattice replaces the middleware tier entirely for revenue-adjacent integrations.
Workato lands in the USD 15k to 60k ARR range for a mid-market deployment with 20 to 50 active recipes. The recipes are powerful; the price tag is the friction. Teams running revenue-adjacent workflows can replace the Workato recipes with native Flows and retain Workato only for non-revenue surfaces (ERP, HR, finance).
Tray.io is capable and flexible. The friction is similar to Workato: a middleware tier with its own learning curve, its own audit surface, and its own bill. Mid-market teams rarely need the full flexibility; the native lattice covers the common revenue cases without the middleware tier.
Zapier is easy to start. The friction is the per-task meter: every step costs a task. A 40-rep team running 92 Zaps lands at USD 500 to 3,000 per month in task fees. The native lattice has no per-task meter; the equivalent patterns run on the per-seat Strkr price.
Make is a cheaper per-operation iPaaS than Zapier for complex scenarios. The architecture problem is the same: a middleware tier between your systems with its own permission model and its own audit surface. Native replaces the architecture, not just the price.
Some teams build custom middleware (Node service, Python service, Lambda functions) to glue systems together. Works until the service goes down, the authentication expires, or the person who built it leaves. Native integration removes the DIY middleware tier and the key-person risk.
Native Salesforce, Google Workspace, Microsoft 365, Slack, Strkr Messaging, inbound/outbound webhooks. One permission model, one audit log, one bill. The integration tier is a product surface, not a glued-on vendor collection.
The native lattice covers the majority of mid-market revenue integrations. For the long tail (vertical SaaS, legacy on-prem, a specific CRM add-on), the webhook pattern covers the gap. Below is how teams handle the systems without native connectors.
The outbound webhook action takes a URL, a configurable JSON payload, and optional HMAC signing. Retries follow the exponential-backoff pattern. For any third-party system with an inbound REST endpoint, a Flow can call it directly from the runtime.
A third-party system POSTs JSON to a Strkr endpoint and fires a Flow with the payload. HMAC verification protects the inbound path. The runtime treats the inbound event identically to a native event; the whole Flow builder and condition layer work on the payload.
A custom integration can also call the Strkr public REST API directly, bypassing the webhook pattern. The API respects the same permission model and writes to the same audit log. For an integration that is bidirectional and high-volume, the API is often the cleaner surface.
A Flow can combine native actions (write to CRM, send Slack, create Calendar event) with a webhook to a vertical SaaS (write to the credit-check service, write to the specialty billing system). The hybrid pattern covers the long tail without a separate iPaaS tier.
When a long-tail integration runs more than 1,000 times per month across the customer base, it becomes a candidate for a native connector. Strkr tracks webhook usage patterns and prioritizes native connectors for the highest-volume long-tail cases. The pattern is "webhook today, native tomorrow" for the integrations that earn it.
For a class of partner (verticalized ISVs, data providers, enrichment services) Strkr builds direct integrations as the long tail matures. The webhook pattern is the first step; the native connector is the second. Teams get coverage immediately and native-grade behavior over time.
Rip-and-replace rarely works. The pattern below is the staged move from an iPaaS to the native lattice, keeping the business running throughout.
Export the active Zap, Recipe, or Scenario list. Group by what each one actually does: routing, enrichment, notification, record sync, document generation. Discard the inactive recipes; most teams have more inactive than active. The real target is usually 20 to 40 active recipes.
Split the active recipes into revenue-adjacent (CRM, marketing, messaging, projects, customer success) and non-revenue (ERP, HR, finance). The revenue-adjacent ones are migration targets for Strkr Flows; the non-revenue ones usually stay on the iPaaS. The split keeps the migration scope sane.
For each revenue-adjacent recipe, build the equivalent Flow in Strkr. The common patterns (lead routing, Slack notification, calendar event, document creation) rebuild in minutes because Strkr ships templates. The custom patterns rebuild in an afternoon or two.
Run both the iPaaS and Strkr Flows in parallel for 30 days. The Strkr Flows write to a shadow log to surface edge cases. Compare: did the Flow fire for every event the iPaaS fired for? Did the actions match? The shadow period catches the surprises.
Once the shadow log shows parity, flip the Strkr Flows to live and deactivate the iPaaS recipes. Monitor for a week; the iPaaS stays deactivated-not-deleted. After a clean week, delete the iPaaS recipes.
With the revenue-adjacent recipes migrated, the iPaaS footprint shrinks. Some teams downgrade to the lowest tier for the remaining non-revenue recipes; others cancel entirely and run the non-revenue surface on something lighter. The decision depends on your remaining recipe count.
Salesforce, Google Workspace, Microsoft 365, Slack, Strkr Messaging, inbound and outbound webhooks. No middleware tier, no per-task meter, one audit log.
Workflow integration is the native lattice of integration actions callable from any Strkr Flow. Salesforce, Google Workspace (Gmail, Calendar, Drive), Microsoft 365 (Outlook, Teams, OneDrive), Slack, Strkr Messaging for SMS, inbound and outbound webhooks, and the public REST API. Each one runs as a native action inside the same runtime that reads the CRM. No middleware tier, no per-task meter, one audit log.
For revenue-adjacent workflows (CRM, marketing, messaging, projects, customer success), yes. The native lattice covers the integrations a mid-market revenue org runs on an iPaaS today. Teams with workflows that span many non-revenue systems (ERP, finance, HRIS) may keep an iPaaS alongside Strkr for the non-revenue surface and run revenue workflows natively. The split is cleaner than running everything through one middleware tier.
Each OAuth connection records the scopes granted. Gmail, Calendar, and Outlook connect per-user because mail is personal. Salesforce and Slack connect at the tenant level because they are team resources. A Flow runs as its owner and inherits the owner's integration access; if the owner has not connected Gmail, the Gmail-send action in that Flow fails cleanly with a permission error. No separate middleware IAM to configure.
Transient failures (rate limits, timeouts, 5xx) retry with exponential backoff. Hard failures (missing OAuth, expired token, invalid payload) raise an error that lands in the dead-letter queue with the full context attached. Admins see the failure, fix the issue (e.g., rotate the credential), and replay from the DLQ. Nothing fails silently.
Use the outbound webhook action. The runtime POSTs a configurable JSON payload to any URL with HMAC signing and the same retry pattern as native actions. For inbound events, any third-party system can POST JSON to a Strkr endpoint and fire a Flow. The webhook pattern covers the long tail; high-volume long-tail integrations become candidates for native connectors over time.
An iPaaS is a middleware tier between your systems with its own permission model, its own audit surface, its own data retention policy, and its own bill. Strkr's native lattice collapses the tier because the integration runs inside the same tenant as the record. One permission model, one audit log, one data-retention policy, one bill. The architecture change is the real difference; the price difference is a consequence.
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.
