A Guide to 6 Salesforce Anti-Patterns

Isn’t it interesting how some decisions can seem right at the moment, but as time rolls by, we realize our actions unintentionally led us down a thorny path? Welcome to the world of anti-patterns!

Anti-patterns aren’t your typical bad practices; they can be surprisingly sneaky and can stem from decisions that initially feel like just the ticket to a seamless solution. Such decisions appear quite attractive under pressure, especially during the later stages of a project. However, as time passes, it becomes evident that these anti-patterns, instead of navigating us towards success, have only contributed to negative results. Let’s take a closer look at them.

What Are Anti-Patterns?

As mentioned above, anti-patterns are more than just bad practices – they’re a bit more complex than that. Anti-patterns can emerge in various forms – from code to communication to project management – and today, we are about to navigate through the challenging terrain of Salesforce anti-patterns.

In this blog post, we will uncover six of the top Salesforce anti-patterns and explore scenarios that contribute to their occurrence, the repercussions, as well as strategies to overcome or sidestep these traps. Our intention is to equip you with insights to recognize potential issues and sharpen your decision-making skills for your Salesforce projects.

With every pitfall we explore, we’ll attempt to equip you with the necessary tools to steer away from these common traps and ensure a smoother experience in your Salesforce projects. So, whether you’re a seasoned Salesforce scion or a newcomer to this ecosystem, this guide promises to shine a light on the potential pitfalls that might be lurking in the shadows of your Salesforce actions.

1. Spaghetti Sharing Model

The Spaghetti Sharing Model is a Salesforce-specific anti-pattern that emerges when the sharing model becomes overly complex and difficult to manage. Salesforce offers a wide variety of sharing mechanisms to accommodate complex requirements such as those related to competition law, privacy, and cross-divisional boundaries. However, without proper planning and control, this flexibility can lead to a convoluted sharing model that is hard to comprehend, even for those who created it.

This anti-pattern often manifests as inconsistent record sharing, where it’s unclear why a record is or isn’t shared with a given user. It’s not uncommon to find situations where figuring out the sharing logic requires a deep dive into the system’s intricacies.

Avoiding the Spaghetti Sharing Model requires a shift from an incremental approach to a more robust upfront design for the sharing architecture. Here are a few steps you can take:

1. Establish Clear Principles: Define rules for your sharing model, such as employing a minimum number of sharing mechanisms or favoring certain mechanisms over others.
2. Create a Review Process: Consider implementing a review process for any complex sharing rules or when a different kind of sharing mechanism is proposed. This could involve an architectural review board or design authority.
3. Invest in Training: Ensure those managing the sharing model are well-trained and understand the implications of their decisions. They should be equipped to push back on stakeholders proposing unviable solutions.
4. Implement Strict Governance: Maintain control over changes to the sharing model to prevent additional complexity from sneaking in. Remember, sharing information that shouldn’t be shared can have serious repercussions.

By adopting a more deliberate and organized approach to sharing architecture and implementing robust governance measures, you can avoid falling into the Spaghetti Sharing Model anti-pattern.

2. Pieism

The next anti-pattern we’re going to discuss is Pieism. This anti-pattern is not exclusive to Salesforce, but it’s one that can have a significant impact on your Salesforce projects.

Pieism, in essence, is the belief that you can have your pie and eat it too. In the context of Salesforce projects, it manifests when we fail to make critical trade-offs during the implementation process. A common example is when we have multiple business units with different business processes. Each unit does things in their unique ways, and we have a global IT department that wants to create a standardized system across all divisions.

Instead of making a decision on this global versus local trade-off, we attempt to accommodate both. We say, “Yes, it’s a global system, but yes, we will also accommodate the local requirements.” The result is a system that fails to do both effectively. This is a classic case of Pieism.

The problem with Pieism is that it attempts to avoid the reality of having to make crucial trade-offs by not making them at all. However, most engineering problems (especially those in software architecture) are about balancing trade-offs between different factors. These trade-offs are often uncomfortable and you can’t please everyone at once. Believing that you don’t have to make these trade-offs is an attractive option, particularly in political organizations or situations where project leadership is weak and lacks senior support.

The negative consequences of Pieism are substantial. Not making a trade-off doesn’t make it go away. It just means that you’re going to experience the conflict. Whether that is on a technical level, where different parts of the system compete with each other, or on a team level, where different teams work at cross purposes. The end result tends to be an unwieldy system with a long implementation timeline and low user adoption. You try to handle all stakeholder concerns and you end up not really meeting anyone’s needs.

To avoid falling into the Pieism trap, you have to acknowledge trade-offs. Be open, honest, and constructively engage with stakeholders about the options. There are often ways of giving people more of what they want, maybe at an additional cost or a longer timeline, but a perfect solution that satisfies everyone at once is almost never possible in software architecture. You can, generally, come up with a solution that satisfies enough of the requirements of enough stakeholders to make it work.

3. Automation Bonanza

The Automation Bonanza anti-Pattern emerges when there is a lack of governance around how automations are used on key objects in your Salesforce org. It’s like a buffet where everyone can pick and choose their favorite automation tools without considering how they all fit together on the plate.

In Salesforce, we have a variety of automation tools at our disposal, such as Flows, Apex Triggers, and various asynchronous methods. Each has its strengths and is suited to particular tasks. However, without clear guidelines and governance, teams can end up implementing a mishmash of automation tools on the same object. This can lead to conflicting automation rules, complex debugging, and ultimately, a system that’s difficult to manage and maintain.

The Automation Bonanza anti-pattern can lead to significant issues. These include:

1. Inefficiency: When multiple automation tools are used on the same object they can conflict with each other, leading to inefficient processes.
2. Increased Complexity: With different automation tools in play, debugging becomes a complex task. It can be hard to determine which tool is responsible for a particular action or error.
3. Maintenance Nightmare: Without clear governance, maintaining your Salesforce org can become a daunting task. Any changes or upgrades can potentially disrupt multiple automation rules, leading to unexpected consequences.

Avoiding the Automation Bonanza anti-pattern requires a strong focus on governance and architecture. Here are a few steps you can take:

1. Define Automation Guidelines: Establish clear guidelines on which types of automation should be used for specific use cases. This can help prevent the use of multiple automation tools on the same object.
2. Implement Robust Governance: Ensure there is a process in place for reviewing and approving the use of automation tools. This can help maintain consistency and prevent the system from becoming overly complex.
3. Train Your Team: Ensure your team is well-versed in the different automation tools and their appropriate use cases. This can help prevent misuse and overuse of automation.

While automation can be a powerful tool in Salesforce, it’s important to use it judiciously. By understanding and avoiding the Automation Bonanza anti-pattern, you can maintain a clean, efficient, and manageable Salesforce org. Remember, the goal is not to use all the tools at your disposal, but to use the right tools for the right tasks.

4. The Golden Hammer

The Golden Hammer anti-pattern occurs when a particular tool or technology, which might be a perfect solution for certain use cases, is mistakenly assumed to be a perfect solution for all use cases. This is often due to the success of the tool in previous projects, leading to an over-reliance on this one solution.

In the world of Salesforce, it’s not uncommon to come across a variety of tools and technologies that could potentially solve your business problems. However, falling into the trap of the Golden Hammer anti-pattern can lead to costly mistakes and unnecessary complexity.

For example, imagine you’ve just started using OmniStudio. You have great success in implementing it at first, building some cool processes that work really well. You then fall in love with this tool and start building everything in OmniStudio, even replacing standard record pages with stuff that you build in OmniStudio. Over time, this approach starts breaking down because you’re using it for everything, even perfectly simple things that don’t require complex customisation, and you’ve got way too much legacy to maintain.

The key to avoiding the Golden Hammer anti-pattern is to analyze and evaluate the suitability of a tool to a specific problem or requirement. Just because a tool has worked well in the past, doesn’t mean it’s the right solution for every problem.

Here are some strategies to avoid falling into this trap:

1. Conservative Adoption: Be quite conservative about adopting new tools and technologies at scale. Test things out gradually, implementing them in smaller projects to gain learning and experience before scaling to larger use cases.
2. Continuous Evaluation: Regularly evaluate your tools and technologies to ensure they are still the most suitable solutions for your business needs.
3. Diversify Your Toolset: Encourage the use of different tools and technologies within your team to avoid over-reliance on a single solution.

The Golden Hammer anti-pattern can lead to costly mistakes and a lot of technical debt if not recognized and addressed early. By adopting a more deliberate and organized approach to tool selection, you can avoid falling into this trap and ensure that your Salesforce environment remains effective and efficient.

5. Big Ball of Mud

The Big Ball of Mud is an anti-pattern that occurs when a system loses all internal structure and coherence, turning into a tangled, unmanageable mess. It’s like trying to break apart a literal ball of mud to find the smaller mud balls that went into creating it in the first place.

This anti-pattern typically arises due to a lack of governance, discipline, and best practices. It’s often the result of tight deadlines, high pressure, and insufficient resources, leading to a ‘just get it done’ mentality. This short-term focus on delivering functionality without considering the long-term consequences often leads to a system that is virtually impossible to understand or modify.

When a system reaches the Big Ball of Mud stage, the results can be catastrophic. It’s usually an end state where the only option is to keep the system operational using firefighting techniques and relying on the few individuals who still understand parts of it.

The system becomes a single point of failure, with a high risk of burning out those individuals who are keeping it running. It also disempowers and demotivates the rest of the team who can’t contribute in any meaningful way due to the system’s complexity and lack of documentation.

Avoiding the Big Ball of Mud requires a focus on good technical discipline, standards, practices, and governance. It’s essential to foster a culture of technical craftsmanship within your organization.

Here are some specific steps to avoid this anti-pattern:

1. Embrace DevOps Culture: Implement smaller, incremental releases and foster a culture of collaboration and knowledge sharing within your team.
2. Distribute Knowledge: Ensure that knowledge and understanding of the system are spread across the team, rather than being held by a select few.
3. Implement Robust Governance: Establish clear processes for decision making, code reviews, and quality assurance.
4. Value Long-term Stability Over Short-term Gains: Resist the temptation to take shortcuts for immediate results at the expense of long-term stability.
5. Continual Learning and Improvement: Always be on the lookout for ways to improve your processes and practices.

Remember, the goal is to create a stable, sustainable Salesforce environment that can grow and evolve with your business needs. By keeping an eye out for the telltale signs of the Big Ball of Mud and taking proactive steps to avoid it, you can ensure the long-term success of your Salesforce projects.

6. Hero

The final anti-pattern that we’ll delve into in this blog post is perhaps the most relatable of all. Known as the Hero anti-pattern, it’s a phenomenon that most of us who’ve spent more than a few years in the IT industry can relate to.

The Hero anti-pattern occurs when a project or system becomes heavily reliant on a single individual or a small group of individuals. These ‘heroes’ are typically those with deep knowledge of a particular system and are often the ones called upon to solve critical issues or carry out feature upgrades. In essence, these individuals are the ones who keep the wheels turning, often working long hours and going above and beyond their normal responsibilities.

Now, you might be thinking, “What’s so bad about that? Isn’t it good to have dedicated, knowledgeable individuals who can step up when needed?” Well, while it’s certainly beneficial to have such individuals on a team, the problem arises when a system or project becomes overly reliant on them.

Over time, this can lead to several negative consequences. Firstly, these ‘heroes’ can become single points of failure. If they burn out, leave the company, or are otherwise unavailable, there’s often no one else who can step in to fill their shoes. Secondly, this scenario can also disempower and demotivate the rest of the team, who may feel that they can’t contribute in any meaningful way. Lastly, the over-reliance on ‘heroes’ often means that there’s no time for proper documentation or handovers, leading to a lack of understanding among the wider team and making the system more difficult to maintain in the long run.

So, how can we avoid the Hero anti-pattern? A good starting point is to foster a culture of knowledge sharing within the team. Encourage team members to document their work and share their knowledge with others. This not only helps to distribute knowledge more evenly across the team, but also empowers all team members to contribute in a meaningful way.

Another key aspect is to adopt a more transparent, repeatable, and manageable process for handling critical issues and feature upgrades. Rather than relying on ‘heroes’ to step in and save the day, work towards creating a system where anyone on the team could handle these tasks. This might involve more upfront work in terms of training and documentation, but it pays off in the long run in terms of a more resilient and maintainable system.

In conclusion, while ‘heroes’ can certainly be valuable assets to any team, it’s important to avoid falling into the trap of the Hero anti-pattern. By fostering a culture of knowledge sharing and adopting more transparent and manageable processes, you can create a more resilient and sustainable system that doesn’t rely on the heroic efforts of a few individuals, but where your heroes enable your whole team to grow.

Summary

Understanding and identifying Salesforce anti-patterns is crucial for Salesforce professionals. It’s not just about knowing what to do, but also about understanding what not to do. Anti-patterns are decisions that might seem beneficial in the short term but can lead to negative consequences in the long term. They can occur in various forms and can pertain to communication, code, or project management.

However, it’s not all doom and gloom. By recognizing these anti-patterns and understanding their potential impacts, you can make better decisions and avoid falling into these common traps. Adopting deliberate and organized approaches, having solid architecture governance, and cultivating a culture of technical craftsmanship within your organization are some of the ways to steer clear of these anti-patterns.

For more information, check out this webinar on the common mistakes of Salesforce architecture: