If you use a calendar, a task manager, a note app, a chat tool, and a file drive, there is a good chance several of them already connect to each other from a settings page. That built-in connection is a native integration: a link between two apps that one of the vendors built and maintains. An automation platform is a separate service that watches one app for an event and then does something in one or more other apps. This article is about telling when the first has stopped being enough, so you don't pay for the second before you need it.
The short version
Start with the native integration. Move to an automation platform only when you can point at one of four specific gaps:
- Multi-step logic the native integration can't express
- A transform between fields, where the value arrives in the wrong shape
- A third app in the middle of a two-app connection
- A trigger the native integration doesn't expose
If you can't name which gap you've hit, you probably haven't hit one yet. Turn on the built-in connection and revisit this when it breaks down.
What a native integration actually does
A native integration is a fixed menu. The vendor decided which events in app A count as a trigger (the thing that starts the flow) and which operations in app B are available as an action (the thing that happens as a result). You pick from the menu, maybe choose a channel or a folder, and toggle it on.
That fixedness is the point. You don't build anything, you don't create another account, and when the connection breaks, the vendor is the one whose support queue it lands in. The trade-off is that the menu is the boundary. The settings page tells you what the integration does; what it doesn't mention is what it can't do, and that's rarely written down as a limitation.
What an automation platform adds
An automation platform sits between apps. You define a trigger in one app, optionally add filters (only continue if a condition is true), branches (do this or that depending on the data), and transforms (reshape a value before passing it on), and then fire actions in as many apps as you've connected.
What it costs you, beyond the subscription: one more account with access to your data, one more login to keep alive, and one more place where a flow can quietly stop running without anyone being told. With a native integration, the vendor owns the failure. With a platform, you do.
Native integration vs. automation platform
| Native integration | Automation platform | |
|---|---|---|
| Setup | Toggle in settings | Build a workflow |
| Apps per flow | Usually two | As many as you connect |
| Logic | Fixed by the vendor | Filters, branches, delays |
| Field mapping | Predefined | You map and transform |
| Who fixes breakage | The vendor | You |
| Extra account | No | Yes |
The four gaps that justify a platform
1. Multi-step logic
"When a task is marked done, post to the team channel" fits a native integration. "When a task is marked done, and it's tagged as client work, post a summary to the channel and move its linked document to the archive folder" usually doesn't. The moment your sentence needs an and then, an unless, or an only if, you're describing logic the fixed menu wasn't built to hold.
2. A transform between fields
Sometimes the native integration lets you pick which field goes where, but the value arrives in the wrong shape. A date in one format that the receiving app doesn't parse. A full name that needs splitting into first and last. A status label in app A that has to become a different status label in app B. If the connection exists but the data needs reshaping on the way through, that's a transform, and native integrations generally don't offer one.
3. A third app in the middle
A connects to B. B connects to C. A does not connect to C. You can sometimes chain two native integrations, but then you're debugging two vendors' behavior when something goes wrong, and you may not be able to tell which link dropped the data. The other version of this gap: A talks to B, but what you actually need is "when something happens in A, look something up in C, then write the result to B." That lookup in the middle is what a platform is for.
4. A trigger the native integration doesn't expose
Native integrations expose a curated list of events. If the event you care about isn't on that list — a specific field changed, a comment was added, a due date passed without the task closing — configuration alone won't add it. Check whether the app offers a webhook (a way for the app to send a message to an outside URL when something happens). If it does, a platform can listen to it. If it doesn't, even a platform may not be able to see that event, and it's worth knowing that before you subscribe.
A checklist for reading the native integration's limits
Do this before opening a pricing page for anything.
Read the settings page, not the marketing page. Write down the actual triggers and actions the integration offers. Marketing copy says "works with"; the settings page says what that means.
Write your workflow as one sentence. "When X happens in A, do Y in B." If it fits without an and then, unless, or convert, the native integration is a strong candidate. If it doesn't fit, underline the word that broke it. That word is your gap.
Count the apps. Two apps is native territory. Three or more, and you should expect to need a platform, or at least to check whether a chain of native integrations covers it without dropping anything.
Check where the trigger lives. Is the event you care about on the native list? Not something close to it — the exact event.
Check the field mapping. Can you choose which field goes where? Does the value arrive in a shape the receiving app accepts? If you can't tell, run one item through and look at what lands.
Find out how each side reports failure. With a native integration, look in the app's own settings or notifications for a status. With a platform, you're the one who has to open the run log and check.
Ask whether you'd notice if it stopped. If the honest answer is "not for a while," a flow that runs on a platform you rarely open is a liability, not a convenience. Either add a way to notice, or keep the flow simple enough to stay native.
Who doesn't need a platform
- You have one or two workflows, each between two apps. The native integrations were built for exactly this. Adding a platform gives you flexibility you won't use and a maintenance job you didn't ask for.
- Your apps are from the same vendor's suite. Those are the connections the vendor has the most reason to build well, and they're the ones least likely to need a bridge.
- You don't want to be the person who debugs it. A platform makes you the maintainer. If nobody on your team wants that role, a slightly less automated native setup is the more reliable choice.
- The step is infrequent. Automating something you do once a week saves less than automating something you do many times a day, and the platform's cost in attention doesn't shrink to match.
Who should keep reading about platforms
You've named a gap from the list above. Your workflow needs three apps, a lookup in the middle, a transform, or a trigger that isn't on the native menu. At that point the platform isn't a luxury; unless a chain of native integrations happens to cover it, the platform is the practical way to make that flow exist. Go in knowing you now own the failure mode.
The next step
Pick the one workflow you most want automated. Write it as a single sentence. Open the native integration's settings page and check whether both the trigger and the action are on the list. If they are, turn it on today. If one is missing, you've found your gap. If both are there but your sentence still needed an and then, an unless, a convert, or a third app, you've found a different one of the four. Either way, a gap you can name is the only good reason to open a tab for an automation platform.