Did we forget something? Let’s say that everything has been set up (although it hasn’t—don’t worry, we’ll understand why shortly).
Click on the Upload button to send the change set to the destination organization:
The change set is now being uploaded to the Production organization and a notification email will be sent to inform you when the corresponding inbound change set is ready at its destination. This can take a few minutes, so don’t panic if you don’t see the email instantly.
Once a change set has been uploaded, it’s locked. Clone it to create a new change set so that you can add more components.
Jump to the destination organization and navigate to Setup | Environments | Change Sets | Inbound Change Sets. Find the new change set and click on it. You may encounter the following message:
Again, don’t panic… it’s just that Salesforce still isn’t ready to deploy it. Wait for a few more minutes. This is what you will see when the change set is ready to be deployed:
Click on the Validate button to validate the change set before deploying it. The system will provide you with a few choices regarding validation on the Apex test’s execution:
- Default: Depending on the current organization, Salesforce automatically runs all local tests (production) or not (sandbox).
- Run local tests: Salesforce automatically runs all local tests (I suggest this for complex change sets, even in sandboxes).
- Run all tests: Salesforce automatically runs local and managed tests (this is related to managed/AppExchange packages).
- Run specified tests: We can select the Apex test classes to be executed (to speed up deployment times; this is something your developers will tell you to do).
Leave the selection as the Default and watch the engine validate your package (from Setup | Deployment Status):
What happened? The new lead field (called Next_Action__c) has not been added to the outbound change set on the source organization, and thus Salesforce cannot deploy field updates nor workflow rules. The change set is not valid.
Let’s get back to the source organization, jump to the already uploaded change set, and click on the Clone button. Lastly, add the new custom field on lead (we called it Next_Action):
All the other components are still there; we have simply added a new item to the list.
We should not encounter any errors on the destination sandbox when validating the inbound change set.
Before uploading the change set, we also need to include permissions for the new field (so that we don’t have to set up an FLS (short for field-level security) on the new custom field manually).
We can do this in two ways:
- Add a new permission set to the change set components list (if the new features come with a permission set).
- Add the impacted profiles to the Profile Settings For Included Components list.
In both cases, only the permissions related to the components list are considered (for example, if you have a permission set that sets FLS for the case’s fields, they are not applied to the destination organization along with the change set because the case’s fields are not included in the change set. The same applies to profiles). The following screenshot shows that three profiles have been added to the change set:
When cloning a change set, use a different name for the newly created change set (such as an incremental version number) so that you’re not confused when dealing with different change sets.
Now, let’s upload this to production and validate it again. Go back to the destination organization and click on the Validate link next to our new inbound change set version:
We should get a green light upon validating the change set:
Jump back to the inbound change set details page and click on the Deploy button (leaving the Default value as it is for Apex tests). You should get a success message:
The components are now included in your organization, along with the necessary permissions.
Let’s go over some more advice regarding this process:
- Add all the dependent components for a given item (for example, all the custom fields for a given custom object or all the workflow actions for a given workflow rule), otherwise the deployment will fail.
- You can deploy along with validation, but validation is useful when you want to know whether the change set is okay ahead of its actual deployment (depending on release management policies, you may only have a given time frame to deploy a change).
- Limit change sets to 10,000 items to avoid long-running uploads and deployments.
Adding hundreds of items to a change set can be cumbersome, but you can find browser extensions that can help you manage your change sets, such as Organizer for Salesforce (for Chrome and Firefox: https://organizer.enree.co), Salesforce Change Set Helper (for Chrome: https://chrome.google.com/webstore/detail/salesforce-change-set-hel/gdjfanbphogooppaefebaaoohdcigpoi), and Salesforce Change Set Turbo (for Chrome: https://chrome.google.com/webstore/detail/salesforce-change-set-tur/dlcjllapchpeedkecmhfnpfenpbglioo).
Let’s move on and discuss using packages to deploy configurations.