Archive

Posts Tagged ‘salesforce.com’

Administrative pre-work for any major Salesforce development project

November 25, 2010 Leave a comment

By Andrew Sinclair

As a Salesforce consultant I like to add value to an orginization through their use of Salesforce, but that quickly gets complicated when my first recommendation is to cleanup Salesforce, before any significant feature development can take place.

It’s always a challenge when the client wants new features to drive efficiencies and increase adoption, but they’re stuck in a situation where they need to crawl out of debt first. My recommendations to clean up Salesforce – and keep it clean – are the following:

1. De-duplicate Salesforce records
Dupes not only make finding records hard, it causes users to lose trust in the system, killing adoption. When users don’t trust the system, it’s pointless to enhance your Salesforce instance. With a little time, this can be easily fixed using DemandTools. While this will take time and money for the DemandTools licence, it’s well worth the investment.

2. Purge fields that are no longer used
Your text field labeled “2008 promo campaign” is no longer valuable (and shouldn’t have been there in the first place). These fields clutter page layouts and reports, and will ultimately lead to bad data. If there is data in these fields that you need to keep, find other fields to push this data into, and remove or delete the field.

3. Delete or deactivate unused workflow rules
If you have a great deal of active workflow rules, look these over to be sure they are still doing something of value. Before additional functionality can be added, we must be sure that we don’t run into workflow rule excepts creating complex errors that need to be debugged.

4. Clean up or simplify your security and sharing model
Over time we create profiles, add field level security, tweak our security sharing rules. While these are necessary, it becomes very easy to trip over complex security models. Again this can create complex debugging activities if your security model is too complex.

5. Verify if validation rules are still required
While validation rules are implemented for good reasons, over time the data that they protect may or may not be useful anymore. Audit these rules to ensure they add value, otherwise you will trip over these rules as you introduce enhancements or new data sources.

6. Implement some of your high demand nice to haves
While it might seem strange to include the introduction of new features in a list like this one, delivering those features which are low(er) effort but deliver value quickly, is a great way to win support from users and other stakeholders. I just hope you’ve been keeping a list of these, because asking users now, will lead to chaotic feature creep.

7. Stop adding fields so Marketing / Sales / or any other department can track and segment records
I’ve seen standard objects with 20-30+ fields that no longer serve any purpose. Many of them were originally created because of some obscure request by sales managers or marketing people to track a campaign. These fields confuse sales people, and cause them to miss critical fields. In the long run, these excess fields lead to poorer data not better.

When faced with requests for these fields going forward, think of other ways that allows the user to track what they want. Often the association to a campaign, a creation date, or setting field history is enough.

8. Remover or archive unused reports
Let’s face it, end users just want to get to the data they care about, and get out. Take an inventory of the reports that are actually used, and start to remove those that are not. These unnecessary reports make report lists very long, and clutter the UI. At the very least move them to some kind of archived folder.