HubSpot has workflows. Salesforce has Flow. Slack has Workflow Builder. Monday has automations. Notion has database automations. At this point, it feels like every SaaS product ships with some kind of built-in automation capability. Which raises a reasonable question: why would you pay for Zapier or Make on top of that?
It's a question we get from clients constantly, and the honest answer isn't "always use an integration platform" or "always use built-in." It's a decision that depends on where your data needs to go and how complex the logic needs to be. But it's a decision with a framework, not a coin flip. Here's how we think about it after 12+ years of building integrations across both approaches.
(If you're earlier in your automation journey and still figuring out where to start, The SMB Automation Playbook covers the fundamentals.)
What Built-In Automation Does Well
Built-in automation stays within the app's data model, and that's its superpower. When you build a workflow inside HubSpot, it has native access to every HubSpot object, field, and relationship. No authentication setup. No connector maintenance. No API version headaches. It just works, because it was built by the same team that built the rest of the product.
There are some genuine advantages here that are worth spelling out:
It's usually free (or included). Most built-in automation comes as part of the plan tier you're already paying for. HubSpot Professional includes workflows. Salesforce Enterprise includes Flow. Power Automate is bundled with Microsoft 365 Business. You're not adding another line item to the budget.
The vendor maintains it. When HubSpot updates their API, HubSpot workflows don't break. When Salesforce changes their data model, Salesforce Flows get updated in the same release. Third-party integrations don't always have that luxury. We've seen plenty of Zapier integrations lag behind after a major platform update, and you're stuck waiting for the connector to catch up.
Deeper access to app-specific features. Built-in tools often reach things that external platforms can't. HubSpot workflows can use internal lead scoring models, set enrollment criteria based on complex object relationships, and trigger internal notifications with full context. Salesforce Flow can fire on record changes at a level of granularity that most external connectors don't support. Built-in tools aren't just "automation." They're part of the application's native logic layer.
Less moving parts. There's something to be said for simplicity. When a workflow lives inside HubSpot and only touches HubSpot data, there's one system to monitor, one set of logs to check, one team to contact for support. Adding an external platform means adding another system to manage, another login to maintain, another vendor relationship to think about.
We worked with a marketing team last year that was paying $50/month for Zapier to route leads between marketing and sales stages — all within HubSpot. Every lead that met certain criteria got moved to a different pipeline stage and the sales team got an email. When we looked at it, the entire workflow could be replicated natively in HubSpot workflows at no additional cost, with better reliability and easier maintenance. They didn't need cross-app automation. They needed within-app automation, and they were overcomplicating it.
Where Built-In Falls Short
The moment your workflow needs to cross an app boundary, built-in automation hits a wall. And in most businesses, app boundaries get crossed constantly.
It's siloed by design. HubSpot workflows can't natively send a Slack message. Salesforce Flow can't write to your Google Sheet without a custom connector. Monday.com automations can talk to a handful of integrations, but the list is limited and the depth is shallow. Each app's built-in automation lives in its own universe, and that universe ends at the edge of the app.
Simpler logic models. Built-in automation tends to support straightforward trigger-action chains. Some platforms handle branching reasonably well (HubSpot workflows have if/then branches; Salesforce Flow has decision elements), but the sophistication drops off quickly when you need error handling, retry logic, data transformation between formats, or complex routing across multiple paths. These are table stakes for dedicated automation platforms.
Vendor lock-in for your automation logic. This is the one that sneaks up on people. If you build 30 workflows inside HubSpot and then decide to switch to Salesforce (or vice versa), you're not migrating those workflows. You're rebuilding them from scratch. Your automation logic is locked inside the vendor's platform, and it doesn't come with you when you leave.
▶💬Real story: 50 Salesforce Flows and the migration that followed
We had a client who moved from Salesforce to HubSpot. They had over 50 Salesforce Flows handling everything from lead assignment to renewal notifications. Every single one had to be rebuilt in HubSpot's workflow engine. It took months. If those automations had lived in a dedicated platform with connectors to both CRMs, the migration would have been "swap the Salesforce step for a HubSpot step," not "rebuild 50 workflows from the ground up."
Monitoring and visibility are fragmented. If you have built-in automations running in six different tools, you need to check six different dashboards to know what's running, what's failed, and what needs attention. There's no single pane of glass. An integration platform gives you one place to see everything.
What Integration Platforms Add
Dedicated platforms like Zapier, Make, n8n, and Workato exist to solve the cross-app problem. They sit between your tools and move data where it needs to go.
Cross-app connectivity. This is the obvious one. Zapier connects to 7,000+ apps. Make connects to hundreds. The whole point is that one platform can talk to everything in your stack, so you're not limited by what any single vendor decided to integrate with.
Centralized workflow management. One dashboard. All your automations. You can see what's running, what failed, when it last ran, and how many tasks it consumed. When something breaks (and things do break), you have one place to look. Compare that to checking the automation section of HubSpot, then Salesforce, then Slack, then Monday, hoping to find which one has the red error badge.
More sophisticated logic. Filters, routers, conditional branching, error handling, retry logic, data formatting, lookups, aggregations. Dedicated platforms are built for this. When your workflow needs to say "look up this contact in the CRM, check if they have an open deal, and if so, route to path A, and if not, route to path B, and if the lookup fails, wait 5 minutes and try again" — that's where an integration platform earns its keep.
Platform agnostic. Your automations aren't tied to any single vendor. Switch CRMs? Update one step. Switch project management tools? Update one step. The rest of the workflow stays the same. Your automation logic is portable in a way that built-in automation never can be.
The Decision Framework
Here's the framework we use with every client. It's simpler than you'd think.
If your workflow lives entirely within one app — all triggers, all actions, all data stays inside HubSpot or Salesforce or whatever — use built-in. It's free, it's native, it's maintained for you, and it has deeper access to app-specific features. Don't bring in a third-party tool for a job the app already handles.
If your workflow crosses two or more apps — the trigger is in one system and the action is in another — use an integration platform. That's literally what they're built for. Trying to force a cross-app workflow through built-in automation (via webhooks, custom API calls, or whatever workaround the vendor supports) usually creates something fragile and hard to maintain.
If built-in can handle 80% of what you need, try built-in first. Extend with an integration platform only for the pieces that need to cross boundaries. Don't pay for a platform you don't need.
If you're not sure, ask this question: "Does the data need to leave this app?" If yes, integration platform. If no, built-in. That single question gets you to the right answer about 90% of the time.
The one exception we'd flag: if you're a small team and you're already running several cross-app automations in Zapier, it sometimes makes sense to consolidate your within-app automations there too, just for the convenience of having everything in one place. The cost might be worth the simplicity. It depends on your team's comfort level and how many automations you're managing.
Real-World Examples
Here's how this plays out in practice with the tools we see most often.
HubSpot: Lead scoring and internal routing. A company uses HubSpot as their CRM and wants to automatically assign leads to sales reps based on territory, company size, and engagement score. All the data lives in HubSpot. All the logic is about HubSpot objects. The assignment rules reference HubSpot properties. This is a textbook case for HubSpot's native workflows. Building this in Zapier would mean pulling data out of HubSpot just to push it back in, which adds latency, cost, and complexity for zero benefit.
But now say that same lead assignment also needs to create a Slack channel for the deal, add a task in Asana for the first outreach, and log the assignment in a shared Google Sheet for the sales meeting. Now you've crossed app boundaries in three different directions. That's a Zapier or Make job.
Salesforce: Approval processes and record updates. Salesforce Flow is excellent at what it does within Salesforce. Approval chains, field updates, record creation, automated emails from Salesforce — it's powerful, mature, and deeply integrated. But the moment you need to sync Salesforce data to your data warehouse, trigger an action in a non-Salesforce tool, or build a workflow that involves Salesforce and three other systems? That's where Make or n8n earns its place.
Slack: Simple internal workflows. Slack Workflow Builder handles internal forms, channel notifications, and message routing beautifully. "When someone posts in #support-requests, route the message to the right team channel based on the topic." Simple, clean, native. But incident response flows that also need to create Jira tickets, page on-call engineers via PagerDuty, and update a status page? That's crossed too many boundaries for Slack's built-in automation.
Microsoft Power Automate: The hybrid case. Power Automate is interesting because it straddles the line. It's "built-in" if you're in the Microsoft ecosystem (it comes with your 365 subscription), but it's also a legitimate integration platform that connects to hundreds of third-party apps. If your company runs on Microsoft 365 and most of your tools are Microsoft-adjacent, Power Automate can often serve as both your within-app and cross-app automation layer. It's worth exploring before paying for a separate platform.
The Hybrid Approach
Here's the reality that most automation advice glosses over: most businesses end up using both built-in and platform-based automation, and that's perfectly fine. It's not a failure to choose. It's the pragmatic answer.
Built-in automation handles the within-app logic. Lead scoring in your CRM. Task assignment rules in your project management tool. Notification routing in Slack. These stay native because native does them better.
An integration platform handles the cross-app flows. Syncing data between systems. Triggering actions across tools. Building multi-step workflows that span your whole stack. These go through your integration platform because that's what it's designed for.
The key is being intentional about it. Know which automation lives where. Document it. (We keep a simple spreadsheet: workflow name, what it does, where it lives, who owns it.) Don't end up with a HubSpot workflow that triggers a Zapier Zap that calls back into HubSpot. We've seen that exact pattern more than once, and it's always a maintenance headache. Data bouncing between systems for no good reason.
Draw clear boundaries: within-app logic stays native, cross-app logic goes through your integration platform, and someone on the team knows where to look when something breaks. That's the whole strategy. (And if you're wondering whether you need automation at all or should buy purpose-built software instead, that's a related but different decision.)
It's not a particularly exciting answer. But in our experience, the boring, well-organized approach outlasts the clever one every time. Maintainability beats elegance in real systems. Knowing where to find things beats building the most technically impressive solution.
This post is part of The SMB Automation Playbook, a series on practical automation for small and mid-size businesses.