Building Resilient Architecture in Salesforce: Lessons from Murphy’s Law

“Anything that can go wrong will go wrong.” You’ve probably heard this before. Maybe you said it yourself. Perhaps you work in one of the many industries that use the idea as a key building principle. This timeless phrase is known as Murphy’s Law, although the full saying actually reads: “If there are two or more ways to do a job, and one of those ways will result in disaster, then somebody will do it that way.”

For decades, it has guided engineers, developers, and architects in building more robust and reliable systems. But how can this principle transform your Salesforce implementations?

Murphy’s Law in the Digital Age

In the digital era, Murphy’s Law is now more relevant than ever. Complex systems, unpredictable users, and any unhandled failure all ripple across entire organizations. This is particularly true in Salesforce environments, where mission-critical business processes depend on seamless integration, data integrity, and user adoption.

Applying Murphy’s Principles to Salesforce Architecture

1. Design for Failure, Not Just Success

The Murphy Mindset: Your starting assumption should be that everything will eventually fail. Whether it’s integrations breaking, users finding new and unusual ways to break your carefully crafted process, or data migrations encountering unexpected edge cases.

Salesforce Application:

  • Implement robust error handling in your Apex code with try-catch blocks and meaningful error messages.
  • Design flows with fault paths that gracefully handle exceptions.
  • Build monitoring and alerting systems that notify administrators before users discover issues.
  • Create fallback mechanisms for critical integrations.

2. Governance That Prevents Human Error

The Murphy Mindset: If a user can input incorrect data, they will. If a developer can deploy untested code, they will. If a configuration can be accidentally changed, it will be.

Salesforce Application:

  • All mission-critical data has to have validation rules that prevent bad data at source.
  • Permission sets and profiles follow the principle of least privilege.
  • Establish mandatory code review processes and deployment checklists.
  • Conduct regular health checks of your org.
  • Create change management processes that require testing and approval.
  • Use Change Sets or DevOps tools that prevent direct production changes.

3. Data Integrity by Design

The Murphy Mindset: If there is a way for your users, admins, and integrations to corrupt your data, you have to assume that they will. Plan for what you will do when data is deleted, overwritten, or imported incorrectly.

Salesforce Application:

4. Testing Murphy’s Scenarios

The Murphy Mindset: Test not just what should happen, but what could go wrong.

Salesforce Application:

  • Create test classes that cover negative scenarios, not just happy paths.
  • Test with invalid data, missing data, and edge cases.
  • Implement user acceptance testing with real users performing real tasks.
  • Test integrations with system downtime scenarios.
  • Test integration scenarios where your org or your integration partner changes the field config at one end of the integration.
  • Load test your solutions with realistic data volumes. Not just average usage, how much data do you need to cope with at the busiest times of day/year?

5. Documentation That Assumes Nothing

The Murphy Mindset: Be kind to your future self. Always document for someone who has your technical knowledge but not your context. That might be someone new to the org – or maybe you in six months, who can’t remember the meeting where what you implemented today was agreed upon.

Salesforce Application:

  • Document not just how something works, but why decisions were made.
  • Create runbooks for common troubleshooting scenarios.
    • If your solution means that extra steps are needed in future builds, add that to the documentation. Common examples include critical reports using buckets or formulas that need to be updated when a field is changed. Integration partners need to update their configuration to accept a different field format. 
  • Maintain up-to-date architecture diagrams and data models.
  • Write code comments that explain the business logic, not just the syntax.
  • Use proven frameworks and checklists as part of the documentation.
  • Create user guides that anticipate common mistakes. If you get tickets for the same user error over and over again, add that to the user guide too.

Real-World Murphy’s Law Scenarios in Salesforce

The Integration That Worked… Until It Didn’t

A company built a beautiful integration between Salesforce and their ERP system. It worked flawlessly in testing. It worked flawlessly for the first six months in production. Then the ERP system had a minor update that changed the date format from MM/DD/YYYY to DD/MM/YYYY. The integration began creating records with incorrect dates, and some records couldn’t be created because the date format was invalid. After shipping delays and customer complaints, the CRM team eventually found the error and fixed it, but they couldn’t fix the bad will generated by the incident. 

The Murphy Solution: Build integrations with data validation that checks for expected formats and ranges. Implement monitoring that alerts when data patterns change unexpectedly.

The Validation Rule That Broke Everything

An administrator created a validation rule to ensure phone numbers were properly formatted. The rule worked great for new records, but prevented updates to existing records that didn’t meet the new format. Critical business processes ground to a halt.

The Murphy Solution: Test validation rules against existing data before deployment. Create data cleanup processes as part of any new validation implementation.

The Custom Object That Exceeded Limits

A growing company built a custom solution using custom objects. It worked perfectly until they hit Salesforce’s object limits, causing new records to fail silently. The issue wasn’t discovered until month-end reporting showed missing data.

The Murphy Solution: Monitor system limits proactively. Build solutions that scale and alert administrators when approaching limits.

Building Your Murphy’s Law Checklist

Before any Salesforce implementation or major change, ask yourself:

Architecture Questions:

  • What happens if this integration fails?
  • How will we know if this process stops working?
  • What’s our rollback plan if this change breaks something?
  • Have we tested this with realistic data volumes?

User Experience Questions:

  • How might users misuse this feature?
  • What happens if users skip steps in this process?
  • Have we made it impossible to enter bad data?
  • Is the error messaging helpful and actionable?

Operational Questions:

  • Who will maintain this when I’m not here?
  • How will future administrators understand why we built it this way?
  • What happens during peak usage periods?
  • Do we have monitoring in place to detect issues?

Murphy’s Paradox

While the potential for errors might seem overwhelming, it’s worth noting a positive paradox that engineers have recognized since 1949. The more you apply Murphy’s Law by anticipating and mitigating failures, the less likely you are to experience their effects. By assuming things will go wrong and building systems that can handle failure gracefully, you create more robust, reliable, and maintainable Salesforce implementations.

Organizations that embrace Murphy’s Law in their Salesforce strategy don’t just avoid disasters; they build systems that inspire confidence, reduce technical debt, and scale effectively. They sleep better at night knowing their systems are prepared for the unexpected.

Summary

Edward Murphy could not have anticipated the digital era or today’s engineering challenges. But his insight from that frustrating day in 1949 remains as relevant today as it ever was. Our Salesforce implementations must be designed for the reality of human error, system failures, and unexpected edge cases. By building with Murphy’s Law in mind, we create not just functional systems, but resilient ones, Systems that stand the test of time and the creativity of users finding new ways to break things.

Remember: Murphy’s Law is not about pessimism. It is about being prepared. And in Salesforce, preparation is the difference between a system that merely works and one that thrives under pressure.

What Murphy’s Law scenarios have you encountered in your Salesforce implementations? Share your stories and solutions in the comments below.

The Author

Nathaniel Sombu

Nathaniel is a freelance Salesforce Consultant, and has been building and looking after Salesforce systems since 2009. He has worked on Sales Cloud, Service Cloud, and Pardot for several companies, and is a regular speaker at Salesforce events, including London’s Calling, Czech Dreamin’ and Dreamforce.

 


 

This Pardot article written by: 

Salesforce Ben | The Drip

Lucy Mazalon is the Head Editor & Operations Director at Salesforceben.com, Founder of THE DRIP and Salesforce Marketing Champion 2020.

Original Pardot Article: https://www.salesforceben.com/building-resilient-architecture-in-salesforce-lessons-from-murphys-law/

Find more great Pardot articles at www.salesforceben.com/the-drip/

Pardot Experts Blog

We have categorized all the different Pardot articles by topics.

Pardot Topic Categories

More Pardot Articles

See all posts

 


 

This Pardot article written by: 

Salesforce Ben | The Drip

Lucy Mazalon is the Head Editor & Operations Director at Salesforceben.com, Founder of THE DRIP and Salesforce Marketing Champion 2020.

Original Pardot Article: https://www.salesforceben.com/building-resilient-architecture-in-salesforce-lessons-from-murphys-law/

Find more great Pardot articles at www.salesforceben.com/the-drip/