Let’s start with the simple question of “what exactly is Documentation?”

Documentation in its simplest form is anything that helps explain why a technical system was built a certain way, how it interacts with other parts of the system, and possibly who to talk to in the event there is a question.

What we are really trying to get at is:  what is the underlying business need that led to this build, what was actually built, and what information should a future admin / project manager / developer (or a future you) know?

In practical day-to-day Salesforce administration, this could come in the form of 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.

For example, let’s say you have an existing Salesforce org that is being used for Sales (Sales Cloud) and Service (Service Cloud).  A new sales manager who’s team is not currently using Salesforce comes to you and wants to begin using Salesforce to capture their accounts, contacts, and opportunities.  They have seen how other teams are using Salesforce, and want something similar but with some advanced features (like specialized sharing, custom code for when an Opportunity is closed, etc…).

In your head, you are probably already listing out the things you might need to build this:

1. New Opportunity Record Type
2. New Field(s) on Account, Contact, and Opportunity objects
3. New Page Layout(s)
4. New Role(s)
5. New Public Group (for specialized sharing)
6. New Sharing Rule (for specialized sharing)
7. New Profile(s) (if necessary)
8. New Permission Set (for specialized perms for managers for example)
9. New Custom Code (to handle after Opportunity close functionality)
10. New Workflow(s) (to send emails to a managers for highly prized Opportunities)
11. New Email Alert(s) (for new workflows above)

The list you have just created in your head, is in fact, Documentation.

Some might call it a requirements document, a spec document, a technical design document, or a build blueprint.  All are acceptable and all are a form of documentation.

When viewed in this light, documentation does not feel like a foreign concept at all.  It’s probably something you are already doing when building in your org, it’s just about putting it down in an organized, accessible, and shareable format!