Your ops tool just became an integration platform

On June 23, 2026, Xurrent shipped a built-in iPaaS. Their service and operations platform now connects to ServiceNow, Jira, Okta, and Google Drive on its own, with a natural-language integration builder coming behind it. The integration layer used to be a separate product you bought from someone else. Now it ships inside the tool you already pay for, and a lot of platform vendors are moving the same direction.

If you run one core platform plus a Zapier or Make account on the side, you are about to get an email that says you can cancel the side account. Sometimes that is the right call. Usually it is the right call for half your integrations and the wrong call for the other half. The trick is knowing which half is which before you consolidate everything onto one vendor and find out later what that cost you.

Why vendors are absorbing the integration layer

For years the deal was clean. Your apps did the work, and a neutral integration platform (Zapier, Make, Workato, Boomi) sat in the middle and moved data between them. The apps partnered with the iPaaS vendors instead of competing with them. That is changing because the app vendors figured out two things. An integration that lives inside their product understands their data model without you mapping every field by hand. And an integration that lives inside their product is very hard to take with you when you leave.

The first is a genuine convenience. Xurrent treats incidents, change requests, and CMDB records as first-class objects rather than rows of generic data, so a sync that involves those objects is less work to set up than the same sync wired through a general-purpose iPaaS. The second is the part the launch post does not mention. Embedded integrations are a switching cost, and the vendor knows it.

Where embedded actually wins

Use the built-in integration layer for syncs that stay inside that platform's world and that you would rebuild anyway if you switched tools. Account provisioning when a ticket closes. Routing an incident to the right queue. Enriching a record with data from another system the platform already understands. These are jobs where the vendor maintaining the connector for you is a real saving, and where the logic is so specific to that platform that it has no life outside it. If you were going to throw the integration away the day you left, you lose nothing by letting it live inside the thing you would be leaving.

The convenience is real here. A connector the vendor owns is a connector the vendor fixes when an API changes. That is maintenance you are not doing, on a sync you did not want to own. Take the win.

Where embedded quietly loses

The problem case is the integration that has to outlive the tool it lives in. The sync between your CRM and your finance system. The flow that pushes new customers from your signup form into three downstream tools. The reconciliation that touches your ERP. These connect systems you expect to keep through a change of any single platform, which means the day you swap one of those platforms, every embedded integration attached to it leaves with it. You do not migrate those flows. You rebuild them from scratch inside the next vendor, and you do it under the time pressure of a migration that is already late.

This is the same trap we wrote about on the renewal call. We covered the question to ask a vendor about who owns the integration a few weeks back, and the embedded-iPaaS pitch is the same question wearing a nicer suit. Convenience now, switching cost later. The cost is invisible until the day you want to leave, which is exactly when you can least afford it.

The test

For any integration, ask one question. Would this flow outlive the tool it lives in? If you replaced this platform next year, would you want to keep this sync running against its replacement?

If the answer is no, the integration dies with the platform anyway. Put it in the embedded layer and let the vendor maintain it. If the answer is yes, that flow belongs in a neutral layer that you control, even if the embedded version is free and the neutral version costs you a seat. You are not paying for the integration. You are paying to keep the integration when the platform underneath it changes.

Most companies have both kinds. A handful of internal, platform-specific automations that should live where the vendor maintains them, and a smaller number of load-bearing flows across system boundaries that should never be locked inside one app. The mistake is treating the consolidation email as all-or-nothing and moving every flow onto the embedded layer because it is there and it is cheaper this quarter.

What to do with the iPaaS seat you already pay for

Do not cancel it the day the embedded option ships. Run the test across your existing automations first. Move the platform-specific ones into the built-in layer and let the vendor own that maintenance. Keep the cross-boundary flows where they are. After that pass, you will usually find the standalone iPaaS is carrying fewer flows than before but the ones it still carries are the ones you most want to keep portable. That is a smaller bill for a more defensible setup, which is the right outcome.

If you are picking an iPaaS from scratch rather than trimming one, the pricing breakdown we did on Zapier, n8n, and Make is the place to start, and the same test applies. Buy the neutral layer for the flows that have to survive a platform change, and lean on embedded connectors for everything else.

The bottom line

The vendors moving the integration layer inside their products are offering a real convenience attached to a real switching cost. The convenience is worth taking on the automations that would die with the platform anyway. The switching cost is worth refusing on the flows you expect to keep through your next migration. Sort your integrations by that one question before you consolidate, and the built-in iPaaS becomes a tool you use on purpose instead of a default you regret.

If you got the consolidation email and are not sure which of your flows are safe to move and which to keep portable, reach out. We run the embedded-versus-neutral sort with clients in a single working session.