Salesforce Best Practices: System Documentation
Imagine you’re a car enthusiast. You started with a basic model and have the manual for it. On top of that, you’ve worked with a body shop to make this your dream car customizing it to your specifications.
You’ve added a custom engine to get more power.
You upgraded the sound system for better performance.
You chose custom tires and hubcaps with special sensors that alert your phone of any issues.
It’s far from the basic model you started with at this point. So when your body shop closes and your car needs work, it’s going to take extra time and money to identify the issue and determine how to fix it.
Salesforce and its add-ons are just like this custom car. There’s robust documentation about how to use Salesforce out of the box and how to install AppExchange solutions. But without information that ties the pieces and customizations together, a new staff member or admin will have to “take apart the engine” to troubleshoot issues, tweak existing functionality, or build new functionality.
If you aren’t documenting your customizations and processes, there’s no better time to start than now. Think of it as a custom manual for your car — with it, any new shop that works on it could find and resolve issues quickly and easily.
Key Documentation to Create
Documentation can seem tedious, and it’s possible your admin won’t know where to start. Trust us, when there’s an issue that needs your attention, it’ll be worth the investment you made in documenting your system and processes.
Let’s break down one of the ways you can think through it.
Standard Salesforce Documentation
Value: Salesforce allows for built-in documentation within setup. Use this as much as you can!
Best Practices We Recommend
Populate Help Text and Descriptions on Fields
Follow a naming convention for validation rules that includes an identifier for the object (Ex OPP001) and put this in the validation rule name AND error message
Populate description on process builder versions
Stakeholder Groups, Their Leaders, and High-Level Workflows
Value: Understand who the key groups and key contacts are to triage requests from that group more quickly.
Questions to Answer
How do you group your users? (Example: Inside Sales, Sales Engineers, Customer Care)
How are these reflected in Salesforce? (Example: Role, Profile, Permission Set, Groups, etc.)
Who is the point-of-contact in case you need to check in with this group?
What functionality and integrations of Salesforce do they most use? Are there any tricky parts?
Bonus: document their process and call out what tools support it
Integrations and Add-Ons
Value: You can manage your integrations without digging through old emails or emailing generic support aliases. This also ensures no integrations turn off due to a lack of bill pay and helps you understand your spend against integrations.
Questions to Answer
What integrations exist?
Who is the business stakeholder?
How do you get support for this integration?
How do you manage licenses for this integration?
Who is the connecting Salesforce user?
Are updates installed automatically or do they need to be manually applied? What is the process for manually applying them?
Is there a recurring cost? How is this paid and when does it come up?
What groups use this feature?
Custom Functionality
Value: Understand custom functionality and know where to start troubleshooting an issue.
Questions to Answer
What functionality is business-critical?
How is it unique?
What technology does it use to run and how do they relate to one another? (Classes, Triggers, Process Builders, Workflows, Flows, etc.)
What are the sticky points? (Any areas where you’ve seen issues in the past, known gaps/workarounds, complex or interconnected solutions)
How do you solve common problems?
Who was the original business requestor and group?
Link to related requirements and process diagrams.
Governance
Value: Be able to answer questions about how someone can make a change, the typical timeline and the security of your org.
Questions to Answer
How does someone request a new user?
How does someone request an enhancement to the system or report a bug?
What is your SLA for tracking requests and what system do you use to do this?
How do you communicate about changes and train users?
What ongoing or repetitive cleanup efforts do you have in place to keep your system clean? (Example: Archiving old reports, reviewing users who have not logged in recently, analyzing old objects and fields and evaluating for removal)
Documentation is going to feel overwhelming when you’re starting from nothing. If you start by setting aside an hour a week to work on historical documentation and make it a priority to build documentation as you go for new functionality and features, you’ll be feeling the momentum in no time.
Because the whole point is to create a shared library of documentation that can serve your organization for the long term, we also recommend storing documentation in an easy to access, shared location, creating a table of contents, and enabling history tracking.
Custom Help within the Lightning interface is an ideal place to store user-facing documentation like FAQs and release information.
And if you’re already partnered with another Salesforce consulting firm (we won’t be mad), make sure to connect with them about their documentation practices. After all, they should leave your team more prepared for future Salesforce work no matter what shop you go to for it.
Curious how Cloud Giants can help create the manual for your Salesforce org? Get in touch with us today!