Salesforce has made application development easier for users. Using “point-and-click” tools and custom workflows, teams can deploy small configurational changes within minutes. However, when it comes to large-scale deployments (like Lightning Migration), it requires considerable planning and effort.
Lack of planning during the deployment phase can lead to unpleasant consequences. Some of the challenges teams face when their deployment is unplanned is disruption in business continuity due to missing objects/validation rules, incompatible changes leading to malfunctions, and a decline in user adoption levels due to insufficient training.
This article is here to help you have a hassle-free deployment. In the following sections, we will discuss various deployment methods in Salesforce, as well as sharing best practices in order to accomplish success in a large-scale Salesforce deployment.
Salesforce Deployment Methods
Salesforce implementations begin in developer sandboxes. After this, changes are pushed to the testing team and then implementations are deployed in the production environment. There are three main methods to deploy in Salesforce:
- Change Sets
- Metadata API
- Ant Migration Tool
Let’s explore these options…
Change Sets
Change sets are a group of features, components, and customizations that can be moved from one Salesforce environment to the other. They are used to send and receive changes between different organizations (either sandbox to sandbox, or sandbox to production).
Change sets are a friendly option for non-tech users and smaller companies that need to implement changes with minimum developer assistance. However, there are some scenarios in which change sets are not suitable, such as:
- When many users are developing Salesforce and there are only a few environments, it is hard to cooperate in change sets.
- Change sets don’t support release management and version control which can cause difficulty in change tracking.
- There are certain customizations, such as sales processes and standard picklist values, that cannot be deployed via change sets.
Metadata API
The primary purpose of Metadata API is to move metadata between Salesforce orgs during the development process. Using Metadata API, you can deploy, retrieve, create, update, or delete customization-related information such as page layouts and custom object definitions.
To deploy tested customizations into production org, you can use the retrieve () or deploy () call. However, if you need to move changes only in metadata, you can use source push and pull commands.
Salesforce also offers an Ant Migration tool to simplify access to Metadata API functionality. Using this, you can:
- Export customizations from Salesforce organization as XML metadata files.
- Transfer configuration changes from one organization to another.
- Change existing customizations in your organization’s instance.
- Migrate metadata from a local file system to a Salesforce organization.
- Create tools for managing organizations and app metadata.
Ant Migration Tool
This is a Java-based CLI (command line interface) and is used for process automation. Using the Ant Migration tool, users can perform repetitive deployments with the same components. It is designed for less tech-savvy users and offers a fast learning curve – also providing better control over deployment, and supporting CI/CD.
Here are some scenarios when you can use this tool:
- Populating test environments with large-scale changes.
- Repetitive development with the same specifications.
- Incremental building, testing, and staging.
- Scheduling deployments in batches.
Best Practices for Large-Scale Salesforce Deployment
1. Select a time for the changes
The best Salesforce deployments are preplanned and executed during an agreed-upon time. Choose the time in advance and let everyone in the organization know about the working hours of the development team.
To ensure no user is working in production and nothing is overridden, it is best to select a quieter time such as evenings or weekends. If you are a large organization with big deployment requirements, you may consider freezing users until deployment, post-deployment steps, and testing are complete.
2. Opt for a full sandbox
The Salesforce platform has a multi-tenant architecture (i.e. it can run multiple instances of one application in a shared manner) which creates several limitations for developing custom applications. Some of these limits can only be tested if you have a large amount of data.
Having a full sandbox allows teams to overcome these limitations. The full sandbox allows users to have a testing environment that is a complete replica of your production org – containing all data (including metadata), object records, and apps. You can test UAT, performance testing, and load testing pretty easily in the full sandbox.
While many teams are hesitant to go for a full sandbox (due to cost reasons), it is worth it due to the invaluable test coverage it offers. If you want to reduce post-deployment risks and save time associated with such issues, consider choosing it over partial sandboxes.
3. Conduct necessary audits
Salesforce users/developers should check the audit trail in the production environment to confirm that no pre-made changes would be overwritten during the deployment process. To ensure there won’t be any conflicts, users should be told not to make any changes in the production before development begins in the sandbox.
4. Prepare your change sets
Change sets should be prepared and validated in advance. However, if you don’t prepare change sets or create deployment windows, you should be prepared to have more time on hand during the process, as patching things between sandbox and production may take some time. Other than this, teams should double-check the need for renaming fields or changes in API names.
5. Leverage test scripts
Every good Salesforce Admin tests changes in the sandbox environment before creating the change set. However, we suggest organizations also do this in production before deployment. If you can have a test script ready before checking changes, this would further simplify the testing process. Doing this will allow users to run through these scripts quickly to ensure everything is functioning as expected.
6. Disable email deliverability
Making bulk changes can trigger a lot of system emails and notifications. Disabling email deliverability before deployment can help teams ensure their users are not bombarded with never-ending email notifications.
Noting down what you have deactivated and what has to be done before deployment (be it workflow rules, validation rules, flows, or process builders) can help in overcoming unnecessary email triggers. Before you activate these triggers, don’t forget to conduct tests to ensure you are working in a fully functional environment.
7. Document everything and train users
Users can be surprised by the overwhelming changes in large-scale deployments. To ensure they work efficiently, teams should put resources for documentation and training. While documentation will help users understand why a change was carried out or what actions to take in a particular scenario, training will enable better license usage.
Supplementing documentation with training will help in making users more confident about system usage, and this will eventually translate into increased productivity. If you are considering making really big changes, you may want to consider having a help desk in your office.
