Adaptiv was fortunate enough to get early access to the Boomi Companion tool ahead of its release at Boomi World 2026. We’ve been putting it through its paces for the past couple of months, and one of the hacks I wanted to explore was building on top of Boomi’s existing branching capability.
If you’ve used Boomi branching or the Package Comparison feature, you’ll know they give you a list of components that have changed between branches/packages – which is useful but only tells half the story.
What was actually modified inside those components? That’s the question it doesn’t answer, and that’s the gap we set out to close.
The Boomi Comparator
Using the Boomi Companion tool, I built our own comparator that goes several steps further. Beyond simply surfacing which components have been updated, showing you exactly what differed – field by field, shape by shape – rendered as a clean side-by-side diff report.
This ended up with three comparison modes:
Branch Comparison
The original motivation. Point it at a branch and it’ll produce a detailed breakdown of every changed component, with a side-by-side diff of the actual changes rather than just a list of component names.
The output is an HTML report with a searchable sidebar, colour-coded diff rows (added, removed, modified), and a clean two-panel layout that makes it easy to scan through even large processes.
Package Comparison
Compare two deployed packages against each other. Great for understanding exactly what went out in a release, or auditing differences between environments. As with the Branch Comparison, you have the same HTML report layout.
Component Comparison
Compare any two versions of a single component. Useful when you want to understand the history of a specific process or map without the noise of everything else.
How It Was Built
This is where the Boomi Companion comes in. Rather than hand-crafting the integration against the Boomi platform API from scratch, I used the Companion to accelerate the build – driving it through prompts, iterating on the output, and letting it handle the heavy lifting of API interaction and XML parsing. The whole thing is backed by a Python script that sits in our internal skills library, meaning it can be invoked directly from within a Claude Code session.
We’ll go into more detail on the technical side in a follow-up post. For now, suffice to say it’s a good example of what’s possible when you put an AI-native development tool in the hands of someone who knows the platform well.
Comparator In Action
Here’s an example of the comparator in action using the Package Comparison mode. I’ve created a simple Boomi process for the before package, then modified it for the after package. I’ve also included the map before and after.
So, let’s look at what the comparator gives us. I simply pass in a prompt asking it to compare two package UIDs (this could easily be switched to use the package name and versions, but it’s still a hack ), and ask to generate the html.
For context, this is what the Boomi Package Comparison feature shows you:
The Boomi Comparator result is the following summary. To break this down, we have the component tree on the left with all changed components, and on the right a list of all changes in the Comparator folder. You can also select individual components on the left if you just want to look at what changed on each component, useful for large modifications.
As you can see, I made changes to the Comparator Map and main Boomi Comparator Process. For the map, I removed the mapping from JsonField1 to XMLField1 and added a mapping from JSONField2 to XMLField2.
Process Changes
-
Added new Try/Catch and Exception Shapes
-
Disconnected the Start Shape from the Message Shape
-
Connected the Start Shape to the Try/Catch Shape
-
Connected the Try/Catch to the Message and Exception Shape
This is a relatively simple example; however, I’ve done more complex changes using all 3 modes and the result is still fantastic – a detailed breakdown of everything that changed. This can be used in Code Reviews, attached to CAB documentation and even post incident reports (but hopefully not!).
Why This Matters
Knowing that something changed is useful. Knowing exactly what changed – and being able to explain it clearly – is what makes the difference in practice.
For organisations running Boomi at scale, the Comparator addresses three real operational needs:
Confident change reviews: Code reviews and change approvals are only as good as the visibility they have. A readable, field-by-field diff means reviewers can verify precisely what’s going in, rather than relying on a component name and a summary.
Audit-ready release documentation: CAB submissions, release notes, and change records typically require a description of what changed. The Comparator generates that evidence automatically – no manual write-up needed.
Faster incident investigation: When something breaks, the first question is always “what changed?” Whether you’re comparing packages across environments or drilling into a single component’s history, the answer is immediate.
The broader point: better tooling raises the quality of the process around it. Reviews get sharper, documentation gets more accurate, and post-incident analysis gets faster – not because teams are working harder, but because they have better information.
In Summary
Boomi Branching and Package Comparison are solid features, but they stop short of telling you what was actually modified. The Boomi Comparator fills that gap with detailed, readable diffs at the branch, component, and package level – built in a fraction of the time it would have taken without the Companion tool.
We’re continuing to refine it, so watch this space.
