Did you spend enough time planning the setup of your Salesforce.com instance? If you are like most of us, you did not. Most likely, you needed a database long before the purchase went through and now you’re in a hurry to get your data uploaded. You may not want to hear this right now, but you need to slow down. With the right pre-upload planning, you can avoid costly, time-consuming data cleanup – and I don’t mean a weekend’s worth of work. I’ve seen databases that require enough cleanup to keep an admin busy for years. So if you’re lucky enough to be starting from scratch, do yourself a favor and keep reading. And if you’ve already inherited someone else’s messy database, keep reading anyway – we can all learn from the mistakes of our predecessors.

Learn the language and the layout. Make sure you know what SFDC means by Lead, Contact, Account, Opportunity, Product, Asset… you already know what those things mean in your organization, but it’s crucial to understand how your database treats them, and how they relate to one another.

• Leads vs. Contacts – The most common mistake that I’ve seen is the tendency to mass create accounts and contacts from a spreadsheet of – well, contacts! SFDC’s “Contact” is really referring to a customer contact, or at least a potential customer. Every Contact should begin as a Lead. The most important reason for this is tracking.
• Lead Conversion – Remember how I just said tracking? If you begin with a Lead, you are on the right track. When you convert a lead, what began as a single piece of information is turned into an Account, a Contact, and an Opportunity – and what makes this so important is, there are reports you can run to track a customer from the Lead through every stage of the Opportunity in your sales process. If you create an Account from scratch, and add a Contact and an Opportunity to it afterward, you lose that level of reporting ability.

Know what you will need to track, long-term. Many objects (accounts, contacts, leads, etc.) in SFDC allow you to track the history on any field on that object. This means that you will be able to run reports on changes made to those fields. Some of the most common are in Opportunities – it’s good to have a recorded history of changes made to the Close Date or to the Amount. Decide now what to track – and it’s better to choose more than less. You can always end the tracking of a piece of info, but if you decide down the road that you wish you’d been tracking, say, changes to the “Billing Address” field in your Accounts – you’ll be out of luck.

Speaking of fields… There are several things to consider carefully in relation to fields. Of course, many are standard – Accounts have fields for the account name, address, phone number, fax, website, etc. There are many other standard fields that you may or may not need. (You can add or remove fields from page layouts as necessary.) You can also create custom fields – but ask yourself these questions first!

• Is there already a field that can give me this info? Look closely at all of the default fields that you already have – it’s easy to go overboard with custom fields and just create clutter.
• What type of info will my custom field contain? I cannot emphasize this enough: choose the right field type the first time! There are several types of text field. There is a field type of date, and one of date/time. There are picklists, and multi-select picklists. Let’s say you created a custom field that was a picklist (where you have to select a single option from the list). Years later, after that info is populated in thousands of records, you decide you need it to be a multi-select picklist so that your users can select more than one thing from the list. You can change the field type… but all of the existing data in that field will be erased when you do.
• Should this field be required? Whether or not to make a field mandatory doesn’t seem like a big deal now. However, what if you don’t make a field mandatory – and later on, you change that? Not a big deal. Unless you run reports based on that information and realize that it is missing from all of your previous records, leaving you with incomplete or inaccurate reports.
• How could future events change the way we use this field? This relates to all of the above points. If you are creating a picklist field, you’ll want to make sure that the values on the list will be relevant later on, perhaps as you add more to the list. If you are making a field mandatory, if you are making a text field a certain length, etc. – think about whether that will continue to make sense. You may not be psychic, but what if you knew that next year your company would release a brand new product and expand its marketing efforts? That info can shape the decisions you make about setting up your database.

Know your sales process. Do you have a rapid, simple sales cycle that only requires 3 or 4 stages of an Opportunity? Or is your process so complex that a potential sales deal generally goes through a dozen stages between qualifying and closed? Opportunity stages are fully customizable – it’s up to you to make them fit your unique process. You may want each Opportunity stage to have a set probability percent, or you may want the two to be independent of each other. You may need certain fields to be required only if the Opportunity has reached a specific stage – for this, you’ll want to put validation rules in place.

Know your users. Think about this before creating users in your SFDC instance. Who should have access to certain info, and how much access are we talking about? FYI – when you create custom fields, you can set what’s called “field-level security” based on user profiles. There is also a feature called “permission sets” – one of my favorites – that will allow you to add specific permissions to an individual user rather than setting them for an entire profile. What this means is, there is no need to create a ton of profiles that have very minor differences. Look at the profile permissions, and the standard profiles that SFDC provides, and map out which users will need certain profiles. This will save so much future cleanup!

Know that your data will not manage itself. How are you going to ensure data accuracy going forward? Will your database require minimal maintenance, or do you need someone to manage it on a daily basis? This is different for every organization, but really has nothing to do with the size of your company. Make sure you have a plan in place, and make at least one person responsible for data cleansing and updating. Keep up with the latest releases and make use of SFDC’s many support and training resources.

There’s no way I’ve covered absolutely everything you will want to think about prior to your SFDC implementation. (Come on, I’m not writing a book here!) These are just the things that I think are most crucial as a starting point – many of them things that make me shake my head and say, “I wish we had done it that way.” Hopefully you will be one of those that say, “I’m so glad we did it that way!”