Xurrent builds an iPaaS into its ITSM platform, at no extra cost
Xurrent now includes a built-in iPaaS in every subscription of its service management platform. Why application vendors are building their own integration layer.
Most news about iPaaS comes from the integration vendors themselves. This one comes from a customer of integration: Xurrent, a platform for IT service management used by IT departments and managed service providers. On 23 June, Xurrent launched its own integration platform, built into the product and included in every subscription at no extra cost.
What Xurrent launched
Xurrent iPaaS lets users build and manage integrations directly inside Xurrent, without a separate integration tool or custom code. According to the announcement:
- incidents, changes, service requests and CMDB records are treated as first-class objects, not as generic data,
- it connects to systems such as ServiceNow, Jira, Okta, ClickUp and Google Drive,
- typical uses are user provisioning, routing of incidents, adding context to incidents and keeping ITSM and development tools in sync.
The product is available now, with general availability from 1 July 2026.
Xurrent’s CEO, Brian Wenngatz, links it directly to AI: integration is what turns AI from advice into action, and without it an AI agent is an expensive demo with nothing to act on.
Why it matters
Xurrent is not a big name in iPaaS, and it does not need to be. The interesting thing is the pattern. More application vendors are building integration into their own products, because their AI features are worth little if the agents cannot reach other systems. Integration is becoming part of the product rather than a separate purchase.
For the customer, a built-in iPaaS has clear advantages. It understands the application’s own data model, it is included in the price and it is managed by the same vendor. For an ITSM platform, knowing what an incident or a change is makes many integrations much simpler.
How it compares
The downside is fragmentation. If every application has its own integration layer, the company ends up with many small integration platforms, each with its own rules, logs and credentials. That is the problem a central iPaaS was meant to solve in the first place.
The realistic answer is a split. Integrations that live entirely within one domain, such as linking ITSM and a developer tool, can often run in the built-in layer. Integrations that cross many domains, or that carry sensitive data, are better placed in a central platform that the integration team controls.
What to ask
- Where should this integration live? Set a simple rule for which integrations may run in built-in iPaaS layers and which must go through the central platform.
- Can you see it? Check whether logs and errors from built-in integrations can be sent to the same monitoring as the rest.
- Who owns the credentials? Make sure the credentials used by built-in integrations are managed and rotated like all others.
Sources
This post was written with AI assistance and reviewed by the editor before publishing.