Boomi Branch and Merge finally gives integration teams what application developers have had for years: isolated work, reviewed merges and a clean way to hotfix production without dragging half-finished changes along. It also changes how you should think about packaging and promotion. This guide brings together the capabilities Boomi shipped between 2024 and 2026 – component diff and creation APIs, branching, hotfix branches, selective merges and step notes – and turns them into a working model for a team that deploys to production every week.

How Boomi got here

Parallel development in Boomi was built up in steps, and the order explains how the pieces fit together:

• Component creation APIs (early 2024) made it possible to create components programmatically, aimed at migration and automation scenarios.
• Component diff APIs (generally available February 2024) show what was changed, added or removed between two component revisions – the foundation for reviews and audits.
• Branch and Merge went from an early access program in 2024 to a general availability rollout in the November 2024 release, including hotfix branches that you can create from any deployment or packaged component.
• Selective and override merges with component selection (July 2025) let you include or exclude individual components in a merge request.
• Merge request management (September 2025) added the ability to revert or delete an active merge request, and the July 2026 release improved performance when reviewing large merge conflicts.

Enabling Branch and Merge: one decision you cannot undo

Only an account administrator can enable the feature, under Settings > Account > Features. Boomi’s documentation is explicit that you currently cannot disable it again yourself after enabling it. Treat enablement as a platform decision, not a developer preference:

• Agree on the branching model before you switch it on.
• Assign the branch and merge privileges deliberately – for example, who may delete branches and who may execute merges.
• Brief the team on the new UI elements: the branch chooser in the Component Explorer, Branch Management and the merge option in the left sidebar.

A branching model that fits Boomi

Boomi components are not source files in a Git repository. A process, a map and a connection are separate components, often shared between processes. That shapes the model:

Three rules keep this model healthy:

1. Keep feature branches short. Shared components such as profiles and connections are where conflicts concentrate. The longer a branch lives, the more of them you collect.
2. Merge the hotfix back. A fix that lives only on the hotfix branch will be overwritten by the next release from main.
3. Do not use branches as environments. Promotion between test, acceptance and production still happens with packaged components and deployments. A branch called “acceptance” recreates the drift you were trying to remove.

Reviewing a merge request properly

A merge request is only as good as its review. Use the component diff to see exactly what changed per component, and review in this order:

1. Shared components first – connections, profiles, cross-reference tables and common sub-processes affect more than the feature being merged.
2. Maps – check functions and default values, not just field lines.
3. Process logic – routes, decision shapes, error paths and try/catch handling.
4. Operational settings – tracked fields, process options and anything that changes what operations sees in Process Reporting.

Cross-reference tables deserve extra attention. Boomi fixed an issue in 2025 where Set Properties steps showed main-branch values instead of the current branch, which is a reminder that branch-aware behaviour of reference data should be part of your test cases.

Selective and override merges

Not every component on a branch is ready at the same moment. Since July 2025 you can exclude components during merge review for selective and override merges:

• The Change Summary in the merge dialog reflects your exclusions, so reviewers see exactly what will be merged.
• A merge can be executed when all locked components are excluded from the request.
• A merge in which every component is excluded cannot be executed.
• The same control is available through the Merge Request API.

Use exclusions sparingly. Excluding a changed profile while merging the map that depends on it is a reliable way to break main. When in doubt, finish the change on the branch rather than splitting it.

Hotfixes without collateral damage

The hotfix capability is the feature that makes Branch and Merge worth enabling for many teams. The flow I recommend:

1. Create a hotfix branch from the deployment that is failing, so you start from exactly what runs in production.
2. Fix and test only the affected components on that branch.
3. Package from the hotfix branch and deploy through your normal approval path.
4. Merge the hotfix into main immediately and resolve any conflicts while the context is fresh.

Note that hotfix components only show in the filter for hotfix branches created after the November 2024 platform release; older branches do not have that metadata.

Documenting intent with step notes

Step notes, generally available since July 2025, are in-context annotations inside a step (every step except Business Rules). They are the right place for “why” information that reviewers otherwise ask about in merge requests: why a route exists, why a retry count was chosen, which ticket introduced a workaround. Keep notes short and factual; they are documentation, not a discussion thread.

Automating the lifecycle with the Platform API

Branching becomes really effective when it is part of a pipeline. The Platform API exposes Branch and Merge Request objects, and the PackagedComponent object accepts the branch to package from. A typical automation flow:

1. Create a feature branch from a ticket.
2. After development, package components from the branch and deploy to a test environment.
3. Run automated tests, then open a merge request for review.
4. After approval, execute the merge and package the release candidate from main.

The component creation API and component diff API complete the picture for teams that generate components from templates or want diff reports attached to change records.

Checklist before you enable Branch and Merge

• Branching model agreed and documented, including hotfix flow.
• Privileges for branch deletion and merge execution assigned.
• Review guidelines for shared components and cross-reference tables.
• Packaging rule: release candidates only from main, hotfixes only from hotfix branches.
• Pipeline steps for packaging per branch and attaching component diffs to change records.

Sources

• Boomi Documentation: Parallel Development with Branch and Merge
• Boomi Integration Release Notes, July 2025
• Boomi Platform Release – November 2024
• Boomi Platform Release – February 2024
• Boomi Developer Blog: Automating Branch and Merge with the Platform API