The post The Guide to Salesforce Deployment Checklist appeared first on Cynoteck.
Introduction
All good admins know that unless there is an exceptionally good reason to do otherwise, changes should be made in a sandbox environment. Especially if the changes are many and big, such as a lightning migration. So, this means that once you are satisfied with the solution you have 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 dedication and hard work, and there is the potential for many things and stuff to go wrong in the process. So, what should you do to ensure that everything goes swiftly?
Below is my simple Salesforce deployment checklist to assist.
Deploying can be time-intensive, and with this, a lot of strange things happen. We definitely don’t want anyone working in production while these changes are taking place. There are following three main reasons:
a) We have to give ourselves more time to smoke test your changes in production so that we can ensure everything is deployed and working fine.
b) We want to ensure that no changes are made in production as you roll out ours, as deploying a changeset will overwrite any changes to production.
c) We don’t want the end-users to use the system before it is fully deployed, or before we have had a chance to brief them fully.
Instead, set a time in advance and let everyone in the organization know out of the user’s nonworking hours is usually best if possible, to avoid user impact and give us time to fix any issues, which means evening/weekend for most businesses.
Ensure all users are notified and asked not to log into the org during this time frame. If we are working in a big org, or our deployment is a particularly large one, we might want to consider actually freezing users until deployment, post-deployment steps, and until the testing is complete.
A sandbox gives you a safe place to test applications and build-out prior to deployment. Always make sure your sandbox is a true replica/copy of the production environment for the most accurate and best results.
Check the audit trail in the production environment to ensure that no changes/modifications were made that will be overwritten by deployment. If they have, we may want to delay or postpone our deployment in order to get these changes migrated over to the sandbox, or speak to the stakeholders involved. (It would be great to clarify with users that no changes are to be made in production before you start developing in the sandbox).
Prepare and validate the changeset in advance. This can take a significant amount of time if we have to patch things up between the sandbox and production, and we don’t want to miss your deployment window because you hadn’t prepared. There are a few things that may catch during validation, like renaming standard fields or any changes to API names, so watch out for these too.
Take a full export/backup of production data prior to deployment. If anything goes wrong, you want to make sure that your data remains intact, so a backup is necessary before any big changes.
Create a sandbox that’s a replica of 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 required.
Prepare the test script you need to 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 changeset, 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.
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. Make sure to note down what you’ve deactivated so you can reactivate it once your changeset has been deployed.
Deactivate Rules/ workflow rules /validation rules/flows /process builders– anything that might impact changes or prevent them from deploying correctly. Make sure that you run tests after we’ve re-activated these, to ensure we have a fully functioning environment.
If you are making big changes, your users may be confused afterward. Organize documentation and training sessions prepare for all users. Ensure users should know how to contact you or raise an internal Support ticket with any issues or questions.
If you are 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 and it really helped us to simplify the process.
Do you need 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 automation are not automatically activated. Activate your new validation rules/ Process Builders/ workflows– anything that might not be active on deployment.
Test your changes – is everything working? Are you able to complete all processes as desired? Are our workflows and validation rule functioning correctly? Use the ‘login as user’ feature to log in as different users and check their profile access and preferences – are you seeing what you had expected to? if possible, ask your users to help you test too.
Now that testing is complete and we are satisfied everything is working, you can enable email deliverability so your users can receive emails again.
If everything is working successfully, congratulations! We have completed a successful deployment. The final step now is to allow our 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 training support and resources they need and check in periodically to ensure they’re as thrilled with your awesome changes as you’d expect them to be.
If you are new to automation and confused about Workflow or Process Builder. Need not to worry, we have got you all covered. Talk to our experts and clear all the cloudy thoughts about automation.
The post The Guide to Salesforce Deployment checklist appeared first on Cynoteck.
Get updates delivered right to your inbox!
