Smart fixes & dependencies
Missing dependencies, fields and permissions added for you; deleted fields cleaned out of layouts, reports and list views.
Most failed Salesforce deployments fail for the same reasons: something the package needs isn't in it, a deleted field is still used somewhere, or a profile points at something the target doesn't have. Smart fixes repair the package before Salesforce ever sees it.
They run every time you open the deploy panel (and on every CI run). The panel lists each fix under Smart fixes with what changed and why. Click Undo on any fix you don't want; the package and the test plan update straight away.
What Diffbridge fixes
| Fix | What happens |
|---|---|
| Missing dependencies | A class, object, component, label or flow the package uses that only exists in the source is added. Repeats until nothing is missing, so dependencies of dependencies come too. |
| Missing fields | A layout, Apex class, flow, report or Lightning component that uses a field that's new in the source gets just that field added (cherry-picked from its object), not the whole object. |
| Access for new items | New fields, Apex classes, objects and Visualforce pages with no access anywhere in the package get the access the source's profiles and permission sets give them, cherry-picked. Otherwise nobody could see them after the deployment. |
| Updated tests | When you deploy an Apex class, test classes that test it and were also changed in the source are added, so the code and its tests match. |
| Deleted dependencies | When something is deleted, it's removed from the page layouts, reports, list views, compact layouts and field sets that use it, in the same deployment. See below. |
| Updated or deleted users of a deletion | If Apex, a flow or a Lightning page still uses something you're deleting, and the source's version no longer does (or it's deleted in the source too), that version is added. |
| References to missing items | Profiles and permission sets deployed whole lose entries for fields, classes, pages, layouts, tabs, apps and flows the target won't have. Entries the target already has, and anything you cherry-picked yourself, are never removed. |
| API version | Components saved at an API version newer than the target supports are lowered to the target's version. |
| Active flows | Deleting a flow that's active in the target deactivates it instead (status Obsolete), because Salesforce can't delete active flows. Deploy the deletion again afterwards. |
| Names that differ only in case | If the package deploys InvoiceService and deletes invoiceService, the deletion is dropped: Salesforce sees one component, so it's a rename. |
| Record type picklist values | Values a record type uses are added to the field from the source; values no version of the field has are removed from the record type. |
| History tracking | A new field that tracks history turns on history tracking for its object when the source has it on. |
| Lookup and master-detail parents | A new relationship field's parent object is added when it only exists in the source. |
| Managed-package fields | Fields of a managed package that isn't installed in the target (ns__Field__c) are left out; they come with the package. |
| Default record types | Cherry-picking profile changes can leave two default record types (or two person-account defaults) for an object; Diffbridge keeps the package's and unsets the other. |
| Undeletable components | Deleting a FlowDefinition, Skill, standard value set or record type is dropped, with why: the Metadata API can't delete them. Deactivate a record type instead. |
| Connected app keys | A connected app new to the target loses its consumer key, which is unique across Salesforce; the target generates its own. |
| Users named by username | Site admins, dashboard running users, workflow and approval recipients get the target's sandbox suffix (ops@acme.com.dev → ops@acme.com.uat), worked out from the two orgs' usernames. |
| Button overrides | Overrides pointing at Visualforce pages, Lightning pages or components the target won't have are removed until those are deployed. |
| Layout action order | Action sort orders with gaps or repeats (common after cherry-picking) are renumbered 0, 1, 2… |
| Default record type missing | A profile with visible record types for an object but no default gets the first visible one as default. |
| Standard apps | Deleting a standard app (standard__…) is dropped; standard apps can only be hidden. |
| Flow translations | When a flow that exists in the target changes, the target's translations of it are deployed again, unchanged, so the new version keeps them. Needs Translations in the comparison's metadata types. |
| Flow definitions | A flow definition deployed together with its flow is left out: the flow's own status decides which version is active. |
| Queue routing | A queue whose routing configuration was removed in the source gets a blank routing configuration, because leaving the element out wouldn't unlink it. |
| Experience Cloud site names | A Network's picassoSite and a Site.com site's label name the target's own site, so the target's value is kept. |
| Active StageAssignment rules | A changed rule that's active in the target is deployed inactive (Salesforce won't change an active one). Turn it back on in the org afterwards. |
| Retired AI models | A new prompt template published with a model Salesforce has retired moves to the closest supported model, so it can be activated. |
| Agent scripts | Deleting an agent script leaves out deletions of the bot, bot version and planner bundle generated from it; Salesforce removes them with the script. |
| Installed packages | A retrieved installed package gets activateRSS set to false (Salesforce's default), which Salesforce otherwise demands. |
| Older target API versions | Lightning page component alignment (API 58+) and the activity list's Related To column (API 47+) are removed when the target is older. |
| Isotope subscriptions | The IsotopeSubscription action, which Salesforce rejects in deployments, is taken out of layouts. |
| Features not enabled in the target | New standard objects and fields (from a feature that's on in the source only) are left out, with how to enable it. |
Diffbridge also warns, without changing anything, when a field changes type (Salesforce rejects some conversions and may convert data), and stops a deployment that would delete every list view of an object, and warns when an outbound message's endpoint differs between orgs (a job for an environment variable). It also stops packages over Salesforce's per-deployment limits (more than 16 queues with routing configurations, more than 50 agent scripts), warns when Quotes are turned on or off, and warns about standard tabs in a profile that no profile in the target mentions (often a feature that isn't enabled there). It also warns when workflow rule actions are removed (the Metadata API can't remove them) and when deleting a flow that may have older versions.
Suggestions (with an Add button, not applied automatically): Apex, components and flows the package uses that changed in the source but aren't in the package, and OmniScripts that embed a changed reusable OmniScript.
Turn smart fixes off for the workspace under Settings → Code analysis → Smart fixes. They're then only shown as suggestions, and problems appear as issues with an Add button.
Deleting fields and other object items
You can delete a single field, validation rule, list view, record type, button or link, field set or compact layout without deleting its object:
- Compare a source that no longer has the item (for example your Dev sandbox, or a branch where it was removed) with the org that still has it.
- Open the object and its Pick changes panel. Items that only exist in the target show Only in the target. Tick to delete it from the target.
- Tick the ones to delete. The panel shows deleting 1 next to the changes you're deploying.
- Click Validate or Deploy.
Diffbridge then:
- removes the field from every page layout, report (columns, filters and groupings), and the object's list views, compact layouts and field sets that show it, and deploys those cleaned versions in the same package;
- deletes the field only after those updates (deletions always run last);
- stops the deployment with an error naming the component and line when Apex, a flow, a validation rule, a formula field or a lookup filter still uses the field and there's no updated version to bring in. Salesforce would refuse the deletion anyway. Change those first, or add the updated versions from your source.
Reports, email templates and dashboards aren't part of a comparison by default, because orgs can have thousands. When you delete fields, the panel tells you which types weren't checked. Include Reports in the comparison's metadata types to clean them up too.
Rolling back a deployment that deleted a field restores the object as it was, field included. Data in a deleted field is kept by Salesforce in its recycle bin for 15 days, not by Diffbridge.
Reviewing the package
Before you start a validation or deployment, Review package in the deploy panel lists every component going out: what's deployed, what's cherry-picked (3 of 12 changes) and what's deleted. Anything a smart fix added says why, for example Field needed by Layout Account-Account Layout. Click the component count in the panel's footer to jump to the list. Use the filter box to find a component in a large package.
After the deployment, the deployment page shows the same fixes, and its Components tab marks what was added automatically.