Congratulations, you implemented Salesforce! Now what? How do you make sure that all the hard work and time you put into a carefully crafted system does not immediately turn disastrous?
Below are some tips and best practices I recommend for establishing clear database improvement policies for your organization.
Don’t Go At It Alone
Admins, you don ‘t have to go at it alone. Establish a Governance Committee or Council, a group of individuals from key departments that hear cases for improvements or needs for additional fields to store data. This creates a system where users must formally request and present use cases for improvements. It allows a group to review, discuss and decide if the updates are in the best interest of the organization. When you have multiple users or areas utilizing the same Salesforce instance, you can sometimes see and allow for siloed improvements to happen. This presentation format allows an improvement that may have seemed like it was only suited for one area to flourish into a system wide improvement.
As long as you have a process for regular meetings, you can create a clear list that can be made available to the rest of the organization about pending and approved improvements. A great way to keep track of these requests is either the use of the Case object or creating a custom object. Document the process and expectations for improvement requests to users so they have a clear understanding of how to make their requests. Bug or functionality fixes (broken links, error messages etc) don’t have to be heard by the committee, as they impact current usage and should be fixed as they are discovered.
Use A Sandbox
The best way to create new features or fields is in a Sandbox. Ideally you will have access to a Full or Partial Sandbox so that you can test functionality on real subsets of your data. If you do have access to either one of these Sandboxes, a good rule of thumb is to keep them updated and in line with your Production instance. This means refreshing them at the allotted refresh intervals. If you don’t have access to these types of Sandboxes then a Developer or Developer Pro sandbox will work just as well. Use the Sandbox to create new functionality, create new fields, add new page layouts and all other improvements that get approved through your committee.
I know you’re probably wondering why you should create new fields in a Sandbox when it’s so easy to just create them directly in Production. Documentation, that’s why. Change sets are a pretty handy feature when it comes to database maintenance. When you have thoroughly tested your new features, you can add them into a change set, which you then get to name and describe. Make sure you include the names of the features you are implementing and what areas or objects are targeted. Your change sets can then live as a log of your completed work.
By setting up clear guidelines and expectations for improvements, you will save yourself from having a Salesforce instance that is overflowing with custom fields that aren’t populated, abandoned workflow rules that no one remembers creating, and other troublesome features that drive any Salesforce admin crazy.
Check out these other great posts:
Data Proofing Your Salesforce Data
Data Validation for Your Salesforce Project
The Secret to a Successful Nonprofit EcoSystem
