Allow users to select custom fields even if the object does not exist in the target
Would be great if GS allowed to select custom fields when doing a comparison even if the object does not exist in the target. If I am pushing changes to a repository I might want to only include the fields I created/modified and not the whole object.
![](https://secure.gravatar.com/avatar/631474cf7244019149e66830f8ebe871?size=40&default=https%3A%2F%2Fassets.uvcdn.com%2Fpkg%2Fadmin%2Ficons%2Fuser_70-6bcf9e08938533adb9bac95c3e487cb2a6d4a32f890ca6fdc82e3072e0ea0368.png)
-
Max Paquin commented
I second what Justin said below. SFDX made it so object deployment and fields deployment could be granular. Requiring the object file takes that granularity away.
-
Justin Lyon commented
This would also be an important feature for those of us that want to break up the happy soup into various packages. I might not want to check in a whole object for one of my packages, but there would certainly be a collection of custom fields that I want to check-in.
-
Max Paquin commented
1. I do not think using the old metadata format as an excuse for product improvement is a good argument.
I would treat the relationship between fields and objects as a dependency not a requirement. The same way I can add an apex class that reference a field to a repository without adding the field to the repository. In this example I need the field to exist in the org I want to deploy my apex class but GS never forced me to add the field to the repository
-
What if the target is an org, or a metadata API repo?
Would you want the behavior to be only for SFDX source format repos?
The biggest question I have is "Would you be able to deploy that selection?" I understand that you cannot deploy a field on a object that does not exist. -
Rachel Purkett commented
This is really important