Unbundle
Use Unbundle when a release candidate contains a change that should not ship — a feature that is not ready, or a fix that turned out to be wrong. codev rebuilds the candidate without the commits you remove, keeping everything else.
Unbundle needs an earlier candidate to rebuild from, so it appears only on candidates that are neither the first nor the most recent in a domain.
Unbundle is best for a recent candidate with little built on top of it. For an older candidate, reverting the change with a pull request is usually the better option — see When to unbundle.
How it works
Click the unbundle (scissors) action on the release candidate row.
The dialog lists the commits this candidate added on top of the previous one, grouped by package. Tick the commits you want to remove.
Choose how to handle conflicts — this only comes into play when removing a commit clashes with a later change you are keeping (see Conflict resolution).
Click Unbundle.
What happens after you click Unbundle
codev files an unbundle request as an issue in your repository (the dialog shows which repository it will use).
A feasibility check runs first: codev rebuilds the candidate as it would look without the removed commits and assesses whether the result still holds together. The verdict is posted to the issue (see How codev judges an unbundle).
If the unbundle is coherent, the request enters an approval gate. A designated approver reviews the report and approves (or rejects) it on the issue. Nothing is rebuilt until someone approves.
On approval, codev rebuilds the candidate without the selected commits, replaying the remaining changes on top of an earlier candidate. A new release candidate appears for the domain once the rebuild finishes — follow progress in Workflows > Runs and Workflows > Pending Approvals.
If removing the commits would break the release, codev recommends a forward revert PR instead and does not rebuild. The report explains why.
Validating the rebuilt candidate
The rebuild produces a new release candidate for the domain, built on its own branch. It behaves exactly like any other candidate — and like any candidate, it is not deployed anywhere automatically.
To check it before it goes further, release it to a test or review environment the same way you release any candidate. There is no environment tied to the unbundle branch — environments deploy releases you choose, so you decide where the rebuilt candidate goes and when.
Unbundling corrects this release — it does not change your source branch. The original commits remain in your branch history, so candidates built later will pick them up again. To take the change out permanently, also revert it with a pull request.
How codev judges an unbundle
Before anything is rebuilt, codev checks whether removing the commits leaves the release coherent. It reconstructs the proposed candidate — the selected commits removed, everything else replayed — then has an AI model reason about whether anything that remains still depends on what was removed.
The most common risk is a dangling reference: a retained Apex class that calls a removed class, a layout that references a removed field, a permission set that grants a removed field. These break the build even though the removed and kept changes live in different files — the kind of dependency a file-by-file comparison cannot see. (Conflicts during the rebuild are a separate concern, handled by conflict resolution below.)
The result is a written report, posted to the issue, with a clear recommendation:
Coherent → the unbundle proceeds to the approval gate.
Risky or unsafe → codev recommends a forward revert PR instead, and does not rebuild.
Because this is an AI judgement on the real reconstructed release, treat it as expert guidance, not a guarantee — the approval gate is where a person makes the final call.
The analysis uses the AI provider configured for your project — see AI providers. When no provider is connected, the check cannot run: codev still produces the mechanical summary of what would be removed, marks the result as needs-review, and sends it to the approval gate so a person can decide — it never silently rebuilds.
How codev judges an unbundle
Before anything is rebuilt, codev checks whether removing the commits leaves the release coherent. It reconstructs the proposed candidate — the selected commits removed, everything else replayed — then has an AI model reason about whether anything that remains still depends on what was removed.
The most common risk is a dangling reference: a retained Apex class that calls a removed class, a layout that references a removed field, a permission set that grants a removed field. These break the build even though the removed and kept changes live in different files — the kind of dependency a file-by-file comparison cannot see. (Conflicts during the rebuild are a separate concern, handled by conflict resolution below.)
The result is a written report, posted to the issue, with a clear recommendation:
Coherent → the unbundle proceeds to the approval gate.
Risky or unsafe → codev recommends a forward revert PR instead, and does not rebuild.
Because this is an AI judgement on the real reconstructed release, treat it as expert guidance, not a guarantee — the approval gate is where a person makes the final call.
The analysis uses the AI provider configured for your project — see AI providers. When no provider is connected, the check cannot run: codev still produces the mechanical summary of what would be removed, marks the result as needs-review, and sends it to the approval gate so a person can decide — it never silently rebuilds.
Conflict resolution
As codev rebuilds the candidate, it re-applies your kept changes one by one. If two changes touched the same lines, they cannot both apply — that is a conflict. codev does not stop to ask you; it picks a side automatically, based on the Conflict resolution option you chose in the dialog. The two options decide which version of those lines survives:
Keep the earlier change (the default) — keep the version already in the candidate, and skip the part of the later change that clashes with it.
Keep the later change — let the more recent change win, replacing the clashing lines that were already there.
Example
Suppose one line of an Apex class was edited twice — first by a commit you remove, then by a commit you keep. When codev re-applies the kept commit, that line no longer matches what the commit expected, so it conflicts:
Keep the earlier change — the line stays as it was before either edit. The kept commit's change to that line is dropped; if that was the commit's only change, the commit is left out of the candidate entirely.
Keep the later change — the kept commit wins, and the line takes its value.
Neither outcome is automatically the one you want — it depends on what you intended. The more changes have landed since the candidate you are unbundling, the more conflicts arise, and the less the rebuilt candidate resembles what you had in mind.
Always review the rebuilt candidate before releasing it. Conflict resolution is automatic, and Salesforce metadata dependencies — Apex referencing a field, a flow using a component — are not visible at the file level. The rebuild can succeed and still leave the candidate in a state you did not intend.
When to unbundle — and when to use a PR instead
Unbundle works best on a recent candidate, soon after the unwanted change landed and before much has been built on top of it. The rebuild is then small and predictable.
Avoid unbundling an older candidate that has many candidates built after it. The rebuild has to replay a long chain of changes, conflicts multiply, and the outcome is hard to reason about.
To take a change out of an older candidate, the better option is to revert it with a pull request — open a PR that reverts the change, and let your pipeline build a fresh candidate from it. The removal stays visible and reviewable in your normal review process, instead of relying on automatic conflict resolution. Reach for Unbundle only when the candidate is recent and little has been built on top.
Related
Last updated
Was this helpful?