2021 salesforce deployment thumbnail

6 Salesforce Deployment Tips

Your company has big plans for big changes, and the excitement is so thick in the air, you can hardly breathe! They know you’re the person for the job in putting those changes into motion, and trust you in making their dreams come true (or, at least to provide a solution that will make their lives easier).

Like most changes, your company needs them as soon as possible, and there is no time to waste! So, you log in to your Production org, make the changes, and email your stakeholders that their problems have been solved! You, my friend, have just made a huge mistake.

When it comes to deploying Salesforce changes, going directly into Production to enact those changes is a common practice, but is a recipe for disaster. Even if those changes are urgent in nature, this is never the right answer! This is a bad habit that must quickly be forgotten.

Poor deployment practices are the root of most problems when it comes to solutions failing in Production. Shoddy testing, rushed releases, and struggling to communicate effectively contribute to the panic that ensues when someone realizes their end-users cannot do their jobs, or there are major customer-facing issues.

Do you want to be the one to tell your C-level executives you contributed to losses in revenue because you didn’t follow Salesforce deployment best practices? Do not set yourself up for this conversation (or others that could go poorly) because you rushed changes along.

Always consider these Salesforce Deployment Best Practices before your next deployment!

Plan Accordingly

One of the best ways to prevent mistakes is to take time to plan for mishaps accordingly. The size of your Salesforce org and what kind of changes you are implementing may influence the type of plan you develop. Allowing for a buffer of time to correct mistakes is important.

Even if there is pressure to release your changes as soon as possible, bake in time to cover yourself should you need it. That way, if you release sooner than expected, you look like a hero, and hopefully, the worst-case scenario will be a release that is still on time.

Planning also allows for everyone to become aware of when the changes will be enacted, and what post-release steps will need to follow. Implementing a schedule and sticking to it is one of the best ways to ensure a smooth release.

Use Sandboxes for Testing

No, I’m not talking about the kind you used when you were a kid, but the concept is essentially the same. A sandbox allows you to implement and test out changes before deploying to production so you can see what works, and more importantly, what may break with those changes.

There should be a series of sandboxes in which changes are tested in, from a development sandbox, to a sandbox with data, and a sandbox for user acceptance testing. Once you know you’ve run the gamut, you can feel confident in pushing your deployment to production. This is a non-negotiable!

Test, Test, and Test some More

Not only should you run a series of tests on your changes before deploying, but you should also schedule user acceptance testing (UAT). UAT is key in allowing for your end-users to see the changes that will occur, and try them on for size.

It is imperative to test a variety of scenarios, and not just the ones that cover how the changes are expected to work. A lot of effort should be placed in scenarios that test if it should fail, and you should essentially try to “break it” like an end-user could.

Stress testing should be done, as well, to test large volumes of data against your changes, as well as any syncs that could indirectly affect your changes. If there are integration users, such as for third-party apps, those users should be tested, as well.

Training and Communication

When deploying changes to Production, time should be allotted to make sure the proper communications are sent both in advance and after the changes have been deployed. There should be no surprises for anyone, and all parties should be on the same page.

All stakeholders should be aware of the progress being made, and understand everything before the changes are deployed. A reminder should be sent the week of, the day of, and after everything has been checked in production. Documentation should be prepared for both Salesforce admins and end users.

Training should occur, both by cross-training other Salesforce admins or developers, and for end-users. They will be excited to know change is coming their way, and you should take every step to encourage their adoption for the best return on investment.

Test in Production

After changes have been deployed to production, it would be erroneous to activate those changes and walk away. Testing should be done in production (just as testing was done in lower environments) to ensure everything works as expected. Once you’ve had success, you can announce the changes to your company.

Document a Rollback Plan

There are times when mistakes happen and the solution just doesn’t work as planned. To eliminate the stress of having to figure out things in a panic, create a rollback plan before the changes are ever deployed.

A rollback plan is a document of steps to take should a sudden reversal need to occur. This can save you hours of trying to remember all of the steps you took in reverse since it all has to be done manually.

A checklist can be easy to work through, and you can have the production org back to its earlier state in a shorter amount of time.

Leslie Roberts
Latest posts by Leslie Roberts (see all)