Better Than You Found It
Like many in the community, my first Salesforce job was an accidental admin role. What I applied for was a marketing data analysis role, and what I got was my first Salesforce administrator job with a 5-year-old org. I had never heard of Salesforce before the interview for the job. I walked into the middle of a massive data cleanse and org refresh, but there was nothing to help me along - no documentation, no project plan, and no memory on the team of why things had been done the way they had been done. Thus when it was time for me to move on, I wanted to leave behind something a little better.
It’s not news that documenting an org is important. There are multitudes of blog posts, previous Dreamforce sessions, and webinars all about how to document a Salesforce org. There are templates. There are guides. There are apps that do this for you. Essentially there is no excuse for not doing this, but here’s a bit of a breakdown of what you should include.
Descriptions
Use the Description fields generously and for everything - Permission Sets, Custom Fields, Custom Objects, automation, and anything else you create. This isn’t just for those that come after you; 6 months after you create it, you may very well forget why you did.
A good description will list what the configuration does, if it’s used in a larger process, and perhaps why it was added or who requested the new item. For example, if a sales user requested a field to identify the job level of a Contact, I would include a description for the new field along the lines of “Picklist values for identified job levels, as requested by sales to track the individuals that they wish to target. Used in PB flow Assign Job Level based on Title.” If that’s more than you feel comfortable with, remember that something is still better than nothing.
Training Materials
Training users is important for adoption, and if you have training materials, this can also serve as an introduction to an incoming admin of your processes. If the new admin has experience, then they will be able to make some assumptions about automation and configuration based on the information provided in the training documentation.
End user training is a whole other topic, but materials to keep on hand could include a written user manual, a series of videos, or a full formal training program. The depth, breadth, and complexity of your training documentation depends entirely on your organization; if you are large enough to have a training team that can help manage it, go big. If you’re a solo admin, do what you can manage, but at the very least you should have a training manual. Regardless of the medium, it can be a helpful resource for an incoming admin to help answer user questions, understanding why configuration was done, or even just to learn more about your business.
Configuration Workbook
A configuration workbook is a breakdown of your org from a metadata perspective -- custom objects, custom fields, custom automation, etc. This might be in a spreadsheet format or a Word document; regardless of the format, it should be maintained regularly.
The good news is that there are multiple apps that will do this for you automatically.
The first place to start is the new Optimizer from Salesforce, which can be run directly in Setup.
For a very basic list of object and field metadata, you can utilize the Schema Lister from sftoolkit.co.
There are solutions on the AppExchange, such as Octopus, which will generate a PDF or Word file for you directly with the customization that has been done in your org. For a little bit more in-depth review, there is also Config Workbook, which will also show you utilization of those items.
All the Extras
Chances are your org is not just a singular entity; there are installed, managed packages, maybe some integration, or even other systems that the Salesforce Administrator might be expected to learn. Make a list of these things. What integrations are there? What does the app or additional system do? Is the admin expected to maintain it, or is there another team they need to work with?
For each of these things, Salesforce and any additional platforms that work with it, make a list of expiration or contract renewal dates and a list of your contacts at those places. Who is your Salesforce AE? Make sure you share that information. Who do they contact for questions about Conga? Provide names, numbers, and email addresses for all of those people.
Do you have a Center of Excellence or internal User Group? Make sure to include that information, as well. List the members, how frequently they meet, and the communication expectations that they have with you.
Salesforce is a great place to include all of this information, even if it’s just documents added to a Library.
Beyond Documentation
Of course all the documentation in the world can’t fix issues. Consider projects and goals that you had identified for the org before you leave. If you’re able to make the fixes before your last day, you should do your fellow admin a solid and address them. If you have a major project ongoing that you’ll be handing off, try to leave it at a good place for someone to come in and pick it back up.
As you move onto the next step in your career, remember that we are all part of this Salesforce Ohana; we have a whole community of people who want to support your learning, your career. You can pay it forward by leaving behind something you’d be proud to put your name on and that sets up your fellow, future admin for success.
Have you recently left a role and spent time preparing the org for its new caretaker? Have you ever taken on a new role and had a mess to clean up? Share your stories with us on Twitter, on the Salesforce Community, Facebook, or chat with me @thesafinhold .
