Deploying Custom Objects via Metadata
Recently, a vendor uploaded a change set to one of our internal sandboxes. I tried to deploy the change set but it kept throwing an error – the fields on the object contained within the change set didn’t exist
Salesforce requires you to include new custom fields in change sets to deploy to a new org – not just the object itself. This object had nearly a hundred custom fields. I was on my way to bed, and I needed to run a script against the object before turning in for the night.
There was no way I was going to be staying up late to manually add every custom field to the change set, so I decided to simply deploy the metadata from the source org to the target.
While you can also do this with ANT scripts (and I will cover that in a future post), I did this simply enough from within my MavensMate IDE (you can do this within Eclipse as well).
First, I subscribed my source project to the CustomObject metadata, and downloaded the XML definitions for every object in the org.
Then I did the same thing in my target project – subscribe to the CustomObject metadata, and download the XML definitions for your custom objects.
In my project for my target org, I then created a new object and when the new file opened in MavensMate, I pasted in the XML from the source org and saved the file, thus uploading it into the target org.
After that, I could deploy the change set without issue as all the fields required by the class files in the same change set now resided on the target environment.
REMEMBER: If you have field level security that must be deployed, you’re going to have to bring over the profiles, either through change sets or by deploying the metadata. The other week I shared a trick that will make your life easier if you need to deploy FLS.