Can't deploy fields from sandbox to production

[eulogiogallo]

I have fields that I've created in my sandbox that are showing up correctly in my project. However, when I try to deploy my metadata to the correct global production connection, the fields I want to deploy get removed from the list of available metadata components. I've tried to refresh my metadata and update my symbol table, but no luck. Any advice for this?

Thanks! Eulogio

[Scott Wells]

I just spoke with a user about this yesterday, I think. Let me repeat back my understanding of the problem you're seeing and then assuming so, I'll shed more light on what's going on.

Basically you have a set of custom fields stored in the corresponding *.object files locally. You want to deploy those fields to another org/connection, and those fields have never existed in that org. You're starting a deploy action and adjusting the dialog for the other org's connection, and when you do so these fields are removed from the list of selectable metadata. Is that correct?

This is a limitation of the way that the metadata tree is displayed currently. It doesn't reconcile local vs. server at the child metadata type, and CustomField is a child of CustomObject. As a result, it doesn't see those fields in the list of metadata from the server, and it doesn't inspect deeply enough to know that they exist in the local files because it's only looking at the type-level metadata, so it doesn't display them in the tree.

The workaround is to deploy the parent object type. Once the fields exist in the target org, they'll show up in the tree after that. Of course, the potential issue with that workaround is that you may have things in the .object file that you don't want to deploy into the other org yet...only the fields. Unfortunately if that's the case, you'll need to comment those out temporarily to deploy them. I would also highly recommend doing a Retrieve for Merge against the target org for the parent .object files to make sure that you know exactly what differences will be applied.

I hope this helps. I'll keep this issue open to track progress on the underlying issue of not allowing child metadata types to be deployed distinctly. Again, this was specifically requested by another user yesterday and has been requested a few times in the past as well.

[eulogiogallo]

Thanks for the explanation Scott! I'll stay tuned for any future updates regarding this.

[Scott Wells]

Issue tracker grooming. If this is still an issue, please feel free to reopen, ideally with a concrete reproduction scenario.