Book Image

Salesforce Anti-Patterns

By : Lars Malmqvist
Book Image

Salesforce Anti-Patterns

By: Lars Malmqvist

Overview of this book

Salesforce Anti-Patterns teaches you to spot errors in Salesforce patterns that may seem like a good idea at first but end up costing you dearly. This book will enable Salesforce developers and architects to understand how ingenious Salesforce architectures can be created by studying anti-patterns and solutions to problems that can later lead to serious implementation issues. While there are several books on the market that start with the question, “How do I create great Salesforce architecture?” and proceed to a solution from there, this book instead starts by asking, “What tends to go wrong with Salesforce architectures?” and proceeds to a solution from there. In this book, you’ll find out how to identify and mitigate anti-patterns in the technical domains of system architecture, data architecture, and security architecture, along with anti-patterns in the functional domain of solution architecture as well as for integration architecture. You’ll also learn about common anti-patterns affecting your Salesforce development process and governance and, finally, how to spot common problems in how architects communicate their solutions. By the end of this Salesforce book, you’ll have gained the confidence to architect and communicate solutions on the Salesforce platform while dodging common mistakes.
Table of Contents (15 chapters)
1
Part 1: Technical Anti-Patterns
6
Part 2: Solution Anti-Patterns
9
Part 3: Process and Communication Anti-Patterns

Knowing the takeaways

In this section, we will abstract a bit from the specific patterns and instead try to pull out the wider learning points you can use in your day-to-day work as a Salesforce architect or in preparing for the CTA Review Board.

When architecting Salesforce solutions, you should be mindful of the following:

  • Don’t put all your eggs in one basket. Plan smaller releases wherever possible to de-risk and get feedback.
  • Confront the tough decisions that can come from having to break down functionality into smaller buckets. Don’t just accept a statement that everything must be there from day one.
  • Always confront the key architectural trade-offs early on in your project timeline. They usually don’t get easier to manage as time goes by.
  • Communicate clearly and openly about the trade-offs that need to be made and the options for doing so. Trying to please everybody and sweep things under the rug is a recipe for disaster.
  • Don’...