As we’ve mentioned in previous blog posts, Documentation can be google docs, word documents, zoom recordings of strategy sessions, pictures of a whiteboard showing technical design sketches, and even internal chats among the Salesforce team.  

Basically, anything that helps illuminate why a certain part of the system was built the way it was, how it interacts with other parts of the system, and who to contact in case there are questions is Documentation.  It doesn’t need to be fancy or overly complicated.
‍

But, how should we even begin?

I know this can seem like a daunting task, especially if you are working out of a complex mature org. You are probably looking at hundreds of custom objects, thousands of custom fields, automations, and page layouts and thinking to yourself “How am I ever going to document all of this?”

My advice for getting started would be to take it one piece at a time.  Are you currently working on a project for Sales to add some new fields?  Start by documenting this new process.  Document the object the fields are going on, the fields (and what each one is for), and then who in Sales is requesting these changes.  Then, as you are doing that, you remember the project you did last year that touched this same object, and you document that process (from what you can remember).

Then, the following week you get an email from a user saying they can’t edit a certain field, which jogs your memory about why that field was created, and you document that field.  This is how you get the ball rolling, just begin documenting as parts of the system come up naturally through your work, and before long you have a solid base of Documentation to build from.
‍

What form should Documentation take?

There is no definitive answer to this question.  Documenting your Salesforce org is not about adhering to a strict process or protocol (in fact, I would argue this is what makes admins avoid documentation), it’s just about getting information down and making it shareable among various stakeholders (at the minimum, your Salesforce team and anyone makes changes in the org).

The first recommendation I’ll make is that it’s in the cloud.  Since this information needs to be shared and should be updated regularly, it needs to be in a place where when it’s updated, it’s updated across all users and devices.  Google docs is a great option since it’s free, in the cloud, can track changes over time, and has collaboration features.

Whichever cloud option you go with, start with a blank document, and using the example from above, write down a structure like this:

‍

‍

Documentation is a living thing

Lastly, documentation is a LIVING document and is only as good as how often it’s maintained.  

As business use cases change, requirements change, and the system is altered to match, the documentation needs to be updated along with it.  This ensures it’s always up to date and can be referenced by anyone on the team, knowing it’s accurate to the current state of the org (and the organization use case it supports).

After starting out with the above structure and putting your first piece of Salesforce documentation in, I would recommend calling a meeting with anyone who makes changes to your Salesforce org.  If possible, also get buy-in from your manager or whomever ultimately is in charge of the whole Salesforce org, this will ensure accountability from all team members involved and that this process is adopted org wide.  Explain the process and how going forward every time a change is made or someone is reminded of a past project and its details, to update the living Documentation.

Ultimately, hopefully over the following months and years, you end up with a thorough documentation database for your Salesforce org.  If you ever need to onboard a new Salesforce admin, have IT help with some code, or just remind yourself of what is currently built and why it was built, you just have to pull up your Documentation!

Get Documentation Template sent to your email.

‍