My parents liked to work with their hands – I learned to sew from my mother, and basic carpentry from my father. In both cases, the old adage of “measure twice, cut once” applied to what I was learning, and I often return to this principle when working with Salesforce. I’ve previously written about how organizations can support implementations for the long haul and considerations for best practice, but this blog is intended to be a reflection on how organizations can better “measure twice” when they implement Salesforce and extend its functionality. Because in Salesforce, it’s easy to “cut once,” but cutting twice or more can sometimes mean substantial amounts of time and effort revising data, data architecture, and programming within the platform.
Part of implementing Salesforce for any organization is an understanding at very high levels what the platform itself is capable of executing, and where its limitations are applicable to a project. Many of the Seasonal Releases are intended to not only add new functionality to Salesforce, but also remediate limitations based on the aggregate need of its clients – often some of the largest corporate organizations in the world. Where organizations get into trouble is when their expectations of what Salesforce will do for them overreach their capacity, exceed the functional capability of Salesforce, or violate best-practices. Expectations management is the easiest method of “measuring twice.” Salesforce can very capably handle data and information from within your organization, as well as integrations with outside donation, commerce, email/marketing engagement, and other types of applications. Time and again, however, two fallacies are often associated with expectations regarding an organizational migration to Salesforce:
- That Salesforce or any integrated applications will provide an out-of-the-box structure for creating missing business processes that Salesforce or these applications are being employed to support. Customizing Salesforce for nonprofit fundraising doesn’t suddenly impart any greater or better ability to run your fundraising program. Adding a volunteer App won’t give you a management strategy for them.
- That integrated applications (such as donation or email/marketing engagement applications), or custom integrations via API, will simply work on a plug-and-play basis. Many of these require ramp-up and configuration on their own accord, and each will impart a learning curve for your users.
Salesforce can only reflect that which exists at the time it is implemented – the onus is on your organization to clearly understand its business processes, metrics, and goals. Shifting organizational priorities, organizations in transition, or organizations implementing Salesforce as a Holy Grail to solve convoluted business processes that have segmented their data, compensate for a lack of internal IT governance, and/or otherwise don’t know what they yet want from the platform will be disappointed. I can’t more clearly state it than this: Salesforce is most successfully implemented when you know yourself first. Similarly, integrating applications to Salesforce is a common and often successful way of extending the platform’s reach across your organization. However, integrated applications, or custom integrations done directly via API, will occupy fields and Objects inside of Salesforce that your users commonly expect to be available. A great example is that most integrated email/marketing engagement applications can only read to/from the Salesforce standard email field on a Contact record – this means that giving users the ability to change this email address in Salesforce will suddenly have implications for your email marketing delivery. For every integration to/from Salesforce, an organization must spend time deciding who and how the integrated data is touched. Hence, why having a strong understanding of your own business processes can support this decision making process successfully. A few other ways to measure twice include:
- Design for Reporting: Salesforce is NOT a SQL database or a Data Warehouse. It is a highly functional object-oriented platform designed to support business-to-business sales processes. What nonprofits require Salesforce to accommodate is business-to-constituent engagement processes, and therefore, ensuring that data is placed in the system, via standard or custom Objects, to best support the desired outcomes of reporting on constituent behavior is critical. Just because Salesforce is highly customizable doesn’t mean that your customizations won’t have an impact on your reporting – a good implementation partner will keep this in mind by designing Object architecture for proper reporting outcomes, or creating data-transit strategies between Objects for easier reporting using the standard Salesforce report engine. That Salesforce is not a SQL database or data warehouse is why tools such as Apsona Multi-Step Reporting and Birst exist to co-exist with a Salesforce instance.
- Integration Business Process Development: As mentioned above, integrating applications (and API programming) to/from Salesforce will necessitate understanding not only who can use which fields and Objects inside of Salesforce, and under what conditions; it also requires developing new business processes internally for both Salesforce and your integrated application. The short point: don’t expect things to carry on as-is once you’ve started integrating with Salesforce.
- Integration Error Handling: If you’re doing your own API programming, remember to account for what happens when nothing wants to talk together because your Web site is down, your router overheated, or your server is offline for maintenance. Don’t just plan for best-case scenarios when doing API programming, account for the worst.
- Use the Right Application/License for the Right Job: Do you really need to see every single email sent and its status inside of Salesforce, or can you use reporting from within your integrated email tool to see this instead? Are the fine-grain details of an event seating plan necessary for all time inside of Salesforce, or just attendance at the event? Using the right features of the right tools that extend the Salesforce platform’s functionality can give you metrics without having to dump megabytes of information inside of Salesforce – a costly mistake that can add up over time. Especially when the right business processes are developed as the integrations take place to support them. Similarly, back in the “early days” of Salesforce, there were only a few available license types – however, more and more organizations are saving money and extending Salesforce’s reach by employing Chatter, Portal, Platform and a host of other license variations that provide for functional need, rather than full platform accessibility. Knowing who supports what business process can also tell you what type of license they need to access the platform, and save you money.
- Build to the Majority: Salesforce can support great variance in its structure, but should it really need to? Don’t look for the exceptions in your data or business processes before implementing them in Salesforce – look for the norms. You may find that by providing a home for the most critical, most normalized processes in Salesforce first, suddenly the need for the exceptions is questioned. Which will give you the opportunity to better understand why they exist at all. Does every person giving money always receive a membership, and when do the people who don’t give money receive memberships, if at all? Agile methodology is a good match for Salesforce implementations in this way: it forces organizations to prioritize needs in a tangible manner, and permits discussion of why this prioritization is happening.
Your organization’s data is your legacy to future staff and constituents, not just those folks who exist in the present. Ideally, a Salesforce instance that has had a substantial amount of measuring before cutting will give your organization a healthy and lengthy home for better understanding your constituents and your own programs.
