The document outlines the process of deploying Salesforce customizations using change sets, detailing the benefits, types of change sets, and best practices for deployment. It emphasizes the importance of validation and captures common deployment challenges and their solutions. The document also highlights the need for proper planning and documentation during the deployment process.

1. Salesforce
Deployment using
Change Set

2. About Company
Company Introduction – Dean Infotech is a leading and top-rated Salesforce Development
and Consulting company that specializes in all-inclusive Salesforce Services.
Mission - Instantly Increase our leadership presence across all verticals.
Vision - To be an outstanding globally recognized Salesforce Development and Consulting
company.
Values -
Customers
First
Continuous
Improvement
Trust and
Respect
Goal
Oriented
Honesty
High
Standards
Team
Works

3. During the session, we will discuss the following topics:
• Introduction to Change Set and Deployment in Salesforce
• Understanding Change Sets and their benefits
• Creating and uploading a Change Set
• Validating and Deploying a Change Set
• Common Deployment Challenges and their Solutions
• Best Practices for Change Set and Deployment

4. What is Change Set ??
● By using change sets we can deploy our customizations from one environment to other
environments in Salesforce.
● Change sets are available in Enterprise, performance, unlimited and Database.com editions.
We use change sets to send customizations from one Salesforce org to another.
● For example, you can create and test a new object in a sandbox org, then send it to your
production org using a change set. Change sets can contain only modifications you can
make through the Setup menu.
● For example, you can’t use a change set to upload a list of contact records. Change sets
contain information about the org. They don’t contain data, such as records.

5. What is outbound change set?
Outbound change set: An outbound change set is a change set created in Source
organization and that you want to deploy to target organization.
Sending an outbound change set to another organization doesn’t guarantee that the
changes will be implemented in that organization. The change set must be deployed
(accepted) by the target organization before the changes take effect.

6. What is inbound change set?
Inbound change set: An inbound change set is change set that is sent from source
organization to the target organization. A change sent must be deployed for the changes to
take effect. You can deploy the contents of an inbound change set as a whole, but not on a
component-by-component basis.

7. Permissions Needed
There are certain system permissions required to be able to create and manage change
sets. In most cases, a user with an admin profile will be creating and deploying the change
sets, so the specific permissions are already part of their profile.

8. Benefits of using Change Set
• The change set remains active in organization for a period of time allowing for an audit of changes
(beyond the setup audit trail).
• This functionality is in Salesforce setup.
• Change set can be include almost anything for example classes, pages, reports, objects, page layouts,
record types, email templates etc.
• Easy to deploy sandbox to production.
• Authorize deployment connection.
• Create outbound change set in sandbox environment.
• Upload from Sandbox environment.
• Review inbound change and deploy in production.
• Faster as compare to all other tool like Eclipse IDE.

9. Creating a Salesforce Change Set
To do this, go into Setup and find the Outbound Change Sets option, then select the new
button.
The screen will open something like this >>

10. Creating a Salesforce Change Set
Give it a name and description, then save.

11. Add your components to the change set
You will now be able to add your
components to the change set. Once you
have added a component the View/Add
Dependencies button will no longer be
grayed out and you will be able to search
for components related to what you have
added.

12. Uploading Your Salesforce Change Set
Once you have added all of your components to your change set, you’re ready to upload it
to your target org. To do this simply select the Upload button, then select the org you wish
to upload it to.
Once it has been uploaded, you will receive an email to say you are now able to deploy the
change set in your target org.
Please note that once a change set has been uploaded, it cannot be amended. If you need
to make any adjustments, you will need to clone the change set and then re-upload it to
your target org.

13. Deploying Your Salesforce Change Set
To deploy your change set, in the target org go into Setup and find the Inbound Change Sets
option. Now select the change set you want to deploy.
You will see there are three options:
■ Validate
■ Deploy
■ Delete.
Validate will run a validation over the change set and let you know if the change set is ok to deploy
or not. It is a good idea to run the validation first as this will show any errors you may face with
the deployment. Going back to our formula field example, if you didn’t add the dependent field,
this is where you would be shown an error message.

14. Continued
If you run the validation first and it succeeds, you will then see a Quick Deploy option on
the change set which will bypass the validation when actually deploying the change set.
Deploy will first run the validation and then attempt to deploy the changes.
Delete will delete the change set. This will mostly be used if you made a mistake in a
previous change set and had to clone and upload a different one.

15. Which test to run?
Once you’ve selected to validate or deploy, you will then have the option to choose a test option.

16. Common Deployment Challenges and their Solutions
Not Everything Can Be Deployed
Change Sets do not support all Salesforce components. An administrator will, therefore,
have to perform some changes manually.
Some examples of components not supported include standard picklist values, sales
processes, divisions, organization-wide email addresses, etc.

17. Common Deployment Challenges and their Solutions
Delivery Chains Can’t Be Maintained
Let’s say you deploy a change set from dev to QA. All of your QAs verify your design is
working correctly and ready to be moved to the production environment. But you can’t
move the exact change set to prod.
You will have to clone the change set, add the dependent components, and reupload it.
Especially in organizations with multiple test environments, pre-prod and then prod, you
can’t establish a chain when using change sets.

18. Common Deployment Challenges and their Solutions
If you run the validation first and it succeeds, you will then see a Quick Deploy option on
the change set which will bypass the validation when actually deploying the change set.
Deploy will first run the validation and then attempt to deploy the changes.
Delete will delete the change set. This will mostly be used if you made a mistake in a
previous change set and had to clone and upload a different one.

19. Common Deployment Challenges and their Solutions
● If you run the validation first and it succeeds, you will then see a Quick Deploy option
on the change set which will bypass the validation when actually deploying the change
set.
● Deploy will first run the validation and then attempt to deploy the changes.
● Delete will delete the change set. This will mostly be used if you made a mistake in a
previous change set and had to clone and upload a different one.

20. Best practices for improving Salesforce change sets
• Plan change sets deployments on a schedule
When you make changes outside of a regular schedule, you’re more likely to make
mistakes or cause unintended errors downstream in your other processes or
systems.
• Document your changes
Salesforce is limited in how well it tracks change sets, you should have your own
separate documentation for any changes you make.

21. Best practices for improving Salesforce change sets
• Test before and after deployment
When you validate a change set, you have the option to skip that step. However, if you do
choose to forego validation, it’s important to perform a meticulous quality assurance
process after deployment. Even if you perform a test in your Sandbox Environment , it’s
possible that it somehow fell out of sync with your production environment. The only way
to be sure is to perform a thorough evaluation.

22. Demo

23. Thank
You.