In my travels, I’ve come across many, many Salesforce orgs–some in great shape and well ordered, some quite chaotic and struggling with adoption. Almost always, the ones that are struggling with design and adoption are what I consider an “amateur” built org. By amateur, I don’t mean that the person didn’t know what they were doing, more that things were not managed and rolled out in an orderly and systematic fashion. This blog has a few tips on how to bring more order to your Salesforce design and deployment process.
Sandbox: If you’ve got it, flaunt it.
Design and build everything in your sandbox, without fail. Unless you’re just tweaking a report or making extremely minor changes, using your sandbox to design and test will save you and your users a lot of headaches. I was working in an org once and the Account page layout was changing each time I opened a new record. Someone who shouldn’t have been was obviously nosing around in the production settings. Imagine how it feels to a user when things suddenly start changing with no warning.
Release management ain’t no joke.
Salesforce is a piece of software. Software has lifecycles. Therefore, your Salesforce org needs to have a lifecycle. Applying a release management methodology is a must for any long term, productive Salesforce enhancement. It’s not hard. As you are tasked with enhancing parts of the platform, keep a log of what you’re building in the sandbox. As your business dictates, those sets of functionality can periodically be deployed to production as a set of features. These periodic updates are easier for users to process than continual, random changes.
Test, test, and retest.
Everything we build at Red Argyle (and everything you build) works best when it’s tested adequately. When a new feature is introduced, we write test plans to validate its use. Even a simple workflow rule needs to be tested for positive and negative situations (when it should and shouldn’t fire). These tests are documented so they can be repeated by different stakeholders. Then we run a test deploy to make sure the feature can validate and deploy smoothly. Lastly, we retest once it’s in production.
Deployment: Failing to plan is planning to fail.
Every deployment needs to come equipped with a deployment plan. A typical deployment plan contains the following pieces of information:
- Contents of what’s being deployed
- Schedule for deployment activities
- Any data work in production
- Testing in sandbox or production
- Deployment communications to all stakeholders
- Training schedule
- Task level detail for who’s doing what and any dependencies
- Test scripts required
- Link to user-facing documentation
Get social.
A professional Salesforce Admin socializes with their users. I love Mike Gerholdt’s concept of SABWA, or “Salesforce Administration by Walking Around.” As a part of the planning associated with the release, regular communications with affected users will minimize issues and help maximize adoption of the new features. At a minimum, users should be notified of the release and have access to release notes, so they know what’s changing. This can be accompanied by training or a recorded webinar demonstrating new features or changes. I also love to use Salesforce Files and Chatter to share deployment plans and training documents with users as it just keeps everything in one place.
Watch for issues.
Even with all the testing and communications, sometimes a surprise still pops up. If you’re on top of it and the user base knows what’s happening, you’ve probably done a good job building up some social capital with them. Continuing to keep the communications flowing with all parties and being transparent about issue root cause will help users plan around the issue and continue to trust you and your work.
I hope these tips are a helpful quick reference for managing successful lifecycle management of your Salesforce org. If you have any pointers or tips to share, please leave a comment!
