Simple Salesforce Deployment Checklist

Introduction

All good admins know that unless there is an exceptionally good reason to do otherwise, changes should be made in a sandbox. Especially if the changes are many and large, such as a lightning migration. So of course this means that once you are satisfied with the solution you’ve built, and it has passed through testing (including UAT, if necessary), these changes will need to be deployed to production.

This final step is the cumulation of all your hard work, and there is the potential for many things to go wrong in the process. So what should you do to ensure everything goes smoothly? Here is my simple Salesforce deployment checklist to assist…

Before Deployment

Agree a time

Don’t just deploy when you’re ready. Deploying can be time-intensive, and can cause a lot of strange things to happen. You definitely don’t want anyone working in production while these changes are taking place.  There are three main reasons for this:

1) You want to ensure no changes are made in production as you roll yours out, as deploying a change set will overwrite any changes to production.

2) You want to give yourself enough time to test your changes in production so you can ensure everything is working correctly before your users get in.

3) You don’t want users starting to work in it before it is fully deployed, or before you’ve had a chance to brief them fully.

Instead, set a time in advance and let everyone using the org know (particularly any other administrators!). Out of hours is usually best if possible to avoid user impact and give you time to fix any issues, which means evenings/weekends for most businesses. Ensure all users are notified and asked not to log into the org during this window. If you’re working in a big org, or your deployment is a particularly large one, you might want to consider actually freezing users until deployment and testing is complete.

Check the audit trail
Check the audit trail in production to ensure no changes have been made that will be overwritten by your deployment. If they have, you may want to delay your deployment in order to get these changes copied over to the sandbox, or speak to the stakeholders involved. (This is a good argument for clarifying with users that no changes are to be made in production before you begin developing in the sandbox.)

Prepare your change set
Prepare and validate your change set in advance. This can take a significant amount of time if you have to match things up between the sandbox and production, and you don’t want to miss your deployment window because you hadn’t prepared. There are a few things that may catch you out in validation, such as renaming standard fields and any changes to API names, so watch out for these!

Do a Full Export
Do a full export of production data before deployment. If anything goes wrong, you want to make sure that your data remains intact, so a backup is essential before any big changes.

Build a Sandbox Copy
Create another sandbox that’s a copy of your production org, so you’ve got a record of your existing setup and metadata. Again, if anything goes wrong, you want to be able to revert back to the current state of play if necessary.

Prepare test scripts
Prepare the tests you will run after deployment to ensure everything is working correctly. Of course, as a good admin you’ll have already done your testing in your sandbox before creating the change set, but you should repeat it again in production to check everything has deployed as it should. Have these test scripts (step-by-step instructions on what to test and how) prepared in advance, so you and then your users can run through these tests quickly to check everything is functioning as expected.

Disable Email Deliverability
Mass changes can trigger lots of system emails and notifications, so disable email deliverability while you deploy to ensure your users aren’t bombarded with an avalanche of mail.
Deactivate Rules
Deactivate validation rules, workflow rules, flows, process builders – anything that might impact changes or prevent them from deploying correctly. Make a note of what you’ve deactivated so you can reactivate it once your change set has deployed. Make sure that you run tests after you’ve reactivated these (and your new ones!), to ensure you have a fully functioning environment.

Prepare Training and Documentation
If you’re making big changes, your users may be confused afterwards. Organise training sessions and prepare documentation for all users. Ensure users know how to contact you or raise an internal Support ticket with any questions or issues. If you’re making really big changes, consider setting up a physical help desk in the office users can approach for help – we’ve done this before for a client at EMPAUA and it really helped ease the process.

After Deployment

Data and Undeployed Changes
Do you have to make any manual changes or data updates? Now is the time. (Depending on the desired result, you will probably want to make sure workflow rules, process builders and validation rules remain deactivated for this).Reactivate Anything Paused
If you paused your workflows and validation rules during deployment, now is the time to reactivate them.
Activate Workflows
When deployed, rules and automations are not automatically activated. Activate your new Process Builders, workflows, validation rules – anything that might not be active on deployment.
Test

Test your changes – is everything working? Are you able to complete processes as expected? Are workflows and validation rules functioning correctly? Use the ‘log in as user’ feature to log in as different users and check their profile access and preferences – are you seeing what you’d expect to? Ask your champion users to help you test too, if possible.

Switch Email Deliverability Back On
Now that testing is complete and you’re satisfied everything is working, you can enable email deliverability so your users can receive emails again.

Reactive and Inform Users
If you’re happy everything is working successfully, congratulations! You’ve completed a successful deployment. The final step now is to allow your users to log in again if you disabled it, and to let them know the changes have taken place. Make sure they have access to all the support and training resources they need, and check in periodically to ensure they’re as thrilled with your awesome changes as you’d expect them to be.

Subscribe To The Monthly Newsletter

No Spam. No Rubbish. Just great content from the Salesforce Industry.

You have Successfully Subscribed!

Leave a Reply