Often Salesforce Consultants and in-house Salesforce specialists are lumped into an internal order-takers, to build out the functionality that program or development staff request.
In one case I spoke to a potential client who said she knew exactly what they wanted to build out for their organization, and just needed someone to build it.
The problem happens, of course, is when that person builds exactly what you tell them to build. Because often you know what you want the system to *do* or how you want it to help you in your work – but building it exactly the way we specify may not get us to where we want to go. Or even be the best practice of how it should have been built in the first place.
Here are some real life examples:
1) An organization called up the support line of their managed package, asked for a field to track board membership last year and this year, and they created two fields as requested.
Why is this a problem? Well first, this managed package has nothing to do with donor cultivation so really they weren’t expected to know best practice here, and were doing the client a favor. But what will happen next year for this organization – does a new field need to be created to track board membership? And in 10 years, will this org have ten unique fields to track each contact’s board membership for that year?
What’s best practice? Best practice for tracking board membership status using the Nonprofit Starter Pack is through affiliations. Create an Account record for your own organization, and link board members join date (and end date) through these records. For extra credit, create a Campaign of “Current Board Members” for an easy way to send a mass email, or ensure that those folks are added quickly onto mailings, events or other group efforts.
2) A foundation asked their IT and Salesforce specialist to create a new record type for each year’s grant application
Why is this a problem? First, creating new record types for each year’s application created a lot of junk in the system, that made reporting and list views more difficult. Second, it was a lot of work – essentially redoing the application each year. Third, it made ongoing maintenance of the system much more complex – page layouts, adding new fields, all had to be defined by record type. Finally, and most importantly, it avoided the difficult internal conversation around how and why should the foundation standardize, at least in part, their grant application process and questions from year to year?
What’s best practice? Creating different record types for different data buckets is okay – in this case by Fund type would be appropriate (but not year over year). Remember, record types are helpful when you’re using the same object, such as opportunities, for different business processes in the same data table. So, use them when your users want to have different fields available, or when you need different opportunity sales process values, or when you want to make wide scale definitions about an object’s use in Salesforce. But, they’re not meant for short-term data categorizations for things that happen “this year” or “this kind of thing” that would be better held reporting on date fields or creating a type picklist.
Often I look at Salesforce the way I’d look at trying to get good value from a local restaurant. I’ll say to a waiter – “I feel like a Sandwich, but I’d love French fries and salad instead of chips. What combo do you recommend?” It’s those moments where I state my general needs and preferences, and let the specialist get to work. “Order Combo #3 with a side salad – that’ll be cheapest and delicious.” Done.
Salesforce development work is no different. Know your preferences (hold the mayo!) but be open to the combination recommended by your guide in the process. And when you hire a Salesforce specialist (consultant or admin) or you’ve given that person the opportunity to grow from within your organization, be open to her telling you that she won’t build what you’re asking for. And then listen.
Up next: How to Work in Partnership with your Salesforce Specialist