Growing and evolving your organization’s Salesforce environment can unlock enormous opportunities, but getting there often proves challenging. I’ve seen this firsthand, having fielded a lot of requests for advice from organizations that have run into issues.
Usually, these organizations have self-implemented or worked with a junior implementation partner that relied on the organization to articulate their requirements rather than developing an understanding of the business value behind the requirements. These partners will take the path of least resistance and simply build what they’re being asked to build.
The problem with this approach is that when business users articulate their requirements in the form of a design solution, they skip talking about the business value driving the requirement. It’s easy to think that skipping this step increases efficiency, but it can actually create more problems in the long run. That’s because if you’re not asking questions that get to the “why?” behind the requirement, such as “what problem am I solving?”, “what are the design options?” and “what are the pros and cons of those options?”, you may implement a solution that works in the short term but doesn’t actually grow and evolve with your business.
There are plenty of other reasons why Salesforce implementations can fail (lack of input from the business, lack of end user training, minimal implementation budget, etc.), but in this article, I want to focus on three mistakes that are specific to the application build and customization that I encounter far too often.
1. Deviating from the Standard Object Structure
Having an understanding of the Salesforce standard object model is important. For example, if you want to track a company, you should use the Account object; if you want to track a person, it belongs as a Contact, Lead or Person Account.
Too often, I see companies use a custom object to track something where a standard object already exists. When digging into the reason(s) why, they don’t hold much weight. The pros rarely ever outweigh the cons.
Let’s take the example of Accounts, in a case where you’re tracking Customers and Partners. A business user may advocate introducing a custom object for Partners to have a separate tab, or by saying that using record types doesn’t give enough “separation” between the two concepts of Customer and Partner. But there are plenty of other ways to solve that challenge that don’t involve hacking the data model.
Why is this such a big deal? Scalability! Continuing with the Accounts example, using a custom object for Partners limits your ability to use standard tools like Partner Community or AppExchange products. It also means that you can’t use the Partner relationship on Accounts and Opportunities. Granted, this is a drastic example, but the same theory applies with every standard object.
2. Integrating to Address a Small Requirement
When it comes to integrations, there are lots of design options – and the selection process shouldn’t be taken lightly. It’s important to think beyond the current integration requirement(s) and consider your future integration needs.
Packaged integrations are great because you can stand them up in a short amount of time. But you can run into trouble when you have one simple requirement that you can’t achieve with the packaged integration. Then you have to augment or replace it completely with a custom integration.
In these cases, you simply can’t underestimate the complexity of the requirement. You may say, “all I need to do is push a closed-won opportunity to my ERP to create an invoice.” It sounds simple, but what about the customer record? We should sync that too. But if we do that, which system is the source of truth? We don’t want early-stage Accounts as Customers in the ERP, so at what point should an Account be created? Does it need to be in real-time? What is the volume of records? Will we hit API limits?
If the scope of the integration is small, you may be tempted to code a few web service calls, but you need to think long term. As your needs grow, it’s too easy to fall into the trap of adding more web service calls and other external systems, but from there it’s a slippery slope to the point where the technical debt is unmanageable.
3. Designing Without Data Quality in Mind
An interesting solution that I’ve seen many times is the concept of “intentional duplicates.” When digging deeper into the reasons why they exist, they’re often related to how relationships are set up.
A common scenario is a Contact that belongs to one Account but is also an advisor/consultant/attorney/etc. for a different Account. Much like the arguments with the object model, there is definitely a more elegant solution to solve that problem. If you’re starting fresh on Salesforce and/or have a small volume of data, it may be manageable to have duplicates. But it doesn’t take very long before the duplicates become a huge problem.
Unintentional duplicates can be a problem too. For instance, it’s common for users not to have visibility into all records and then unintentionally create a duplicate because they simply don’t have access to the record that already exists.
Regardless of whether the duplicates are intentional or not, having them in the system can create challenges as your data grows. As this happens, disparities between the two records become nearly impossible to avoid as users update one but not the other. This can then create confusion among users who are unsure which record is correct and which one to update. Often, this leads to each record having some elements of updated data but neither being fully accurate. To avoid these challenges, it’s important to familiarize yourself with your options for maintaining data quality and then apply them where they make the most sense.
Designing a Best Practice Salesforce Instance
Ideally, you can avoid these design mistakes altogether by taking the time upfront to understand the business value behind your Salesforce requirements. However, ideal scenarios aren’t always possible, and if you’ve already implemented Salesforce and are now finding shortcomings like these in your own environment, it’s not too late to turn things around.
If that’s the case for your organization, designing a best practice Salesforce instance that can scale with your business as it grows and evolves starts with three key steps:
- Reinforce the value of the platform that led you to implement Salesforce in the first place, while recognizing the mistakes made during your initial implementation that are now stunting program growth.
- Engage an experienced partner who can help fix these problems and introduce solutions based on the business value behind your requirements so that you can move forward and take full advantage of Salesforce.
- Continue to build and iterate in ways that improve your data and analytics so you can optimize what you’re doing and make informed decisions off the data.
Ultimately, these steps should position your organization to implement additional Salesforce clouds and improve usability of the platform to increase user adoption — both of which can help maximize your return on investment.
Jay Datta is a manager of solution engineering at AllCloud, a global professional services company providing organizations with the tools for cloud enablement and transformation.
Author
Get our newsletter and digital focus reports
Stay current on learning and development trends, best practices, research, new products and technologies, case studies and much more.
