With Salesforce.com’s inherent ease of configuration comes the temptation to skimp on documenting your org. My experience working with companies that are rushing to migrate over to Salesforce.com is that they are not willing to spend the extra time and dollars to fully document not only the implementation, but also the ongoing “care and feeding” (updates) of their Salesforce.com instance. Even worse is not fully documenting an integration with Salesforce.com beyond the business requirements (what does it need to do). A good Administrator can look and see how Salesforce.com is configured, but reading someone else’s code can be a lot more involved.
The risk is one that I think most businesses have experienced at one time or another. Down the road someone asks a question of why is the process was changed or when did a change occur. To solve this I encourage you to keep a running milestone document. For example, when did we make that big update to our web-to-lead form? When did we change our Opportunity stages? When did our Portal go live?
Have a workflow “playbook” – what’s the trigger, who gets notified, and what happens (email, task, field update, or outbound message). The playbook is beneficial when you have lots of constituents impacted by a business process. It also allows users to know “who has the football” in a process and lets Users know why their getting notifications and tasks. This type of playbook works well as a companion in User training – it will let them know why the system is assigning them work!
Additionally, create a Visio of your business processes along with your security settings by both Role and Profile. Archive these documents along with any end-user training materials in the Document folder.
Lastly, keep a log of all requests for changes and updates to the system. Better yet – open a case!