Allow adding "No Difference" items to package. To help with package reuse to multiple orgs
Allow assets with "no difference" to be added to a promotion to allow the same package to be used to both promote as well as sync other sandboxes (without having to manually check if asset was changed in each).
Chance Martin commented
This is very important to me. Sometimes we replace a field with another field, or condense two fields into a single field (current use-case). This leads to needing to update many reports (70 with my current project). With Environment Variables, I can easily swap out fields in my target org. But if there are no differences in the reports, I can't deploy the reports.
At the very least, it would be nice if the comparison took Environment Variables into account. So even if there is no difference without Environment Variables, if Environment Variables would create a difference, we should be able to deploy them.
I'm running into a dependency deployment issue that throws this error: 'Cannot set sharingModel to ControlledByParent on a CustomObject without a MasterDetail relationship field' error.
Sadly, the apparent fix to this issue, per Salesforce (https://help.salesforce.com/s/articleView?id=000334872&type=1), is to add the MasterDetail relationship field BUT it cannot be added because it is flagged as "No difference". So I'm stuck!
UPDATE - To get around the No Difference Limitation, I physically had to modify the custom field so that it would pickup a difference. In this case, I tweaked the Field Description by adding a single period, ".". Seems ridiculous but this only applies for my specific use case.
Brilliant idea. I am currently struggling when deploying page layouts across environments. When there are related lists involved, there are some fields which are dependencies to the page layout, but have not changed across the environments. We still need to deploy these with the page layouts, otherwise we are receiving an error as follows: Invalid field:SOLUTION.ISSUE in related list:RelatedSolutionList Error
My current solution is to take these page layouts out of the deployment package, and release them with their dependent fields in a SF change set (YUCK, I know).
Manual and really labor intensive.
This enhancement would be welcomed.
Below is one example of the issue:
Thanks in advance.