Platform Strategy for Salesforce in the Enterprise

1. Introduction

Salesforce, originally a CRM platform, has evolved into a multi-cloud enterprise ecosystem. Many organizations leverage Salesforce for sales and service and as a platform for building custom apps.

As a Salesforce CTA supporting large enterprises, I advocate adopting a Platform Strategy that aligns multiple teams and vendors on a shared Salesforce foundation, ensuring scalability, governance, and long-term maintainability.

2. Guiding Principles for Platform Fitness and Product Development

To maximize the value of the Salesforce platform to the enterprise, I propose to follow the following principles.

2.1 Keep the Platform Fit

Over time, Salesforce orgs can accumulate technical debt, and “bloat” in the form of too many fields, and complicated automation. Keeping the platform “fit” ensures performance, scalability, and maintainability.

Key Recommendations

• Govern Shared Resources: Shared resources must be governed to ensure proper use. Standard objects and features should be used as designed; avoid repurposing them for unintended uses (e.g., using Opportunity or Case just because you want to share records with a team).
• Restrain Field Bloat: Avoid adding hundreds of fields to core objects (e.g., Account, Contact, Opportunity). Use custom objects for specialized data. While it’s easy to add fields, it’s not easy to understand or maintain them once you get to hundreds of them.
• Control Technical Debt: Some amount of technical debt is inevitable but must be contained in its impacts, documented to avoid becoming snugs, and eliminated if it compromises data integrity or hinders new development.

2.2 Use the SaaS Product’s Sweet Spot (Don’t “Twist the Arm”)

A major benefit of a SaaS product (like Sales Cloud, or Service Cloud) is leveraging the vendor’s best practices and out-of-the-box functionality. Over-customizing or forcing it to operate outside its “mental model” leads to excessive complexity and stifles future innovation.

Key Recommendations

• Focus on Out-of-the-Box Value: Fully leverage the default data models and automation features. Adopt new platform releases quickly without worrying about breakage from extreme customizations.
• Adopt the Provided Business Process: Over-customization increases maintenance, testing, and deployment costs. Evaluate whether adapting business processes is cheaper than heavily customizing the platform. Align with standard processes if possible (e.g., lead-to-cash, case management) to leverage Salesforce’s continuous innovation.
• Avoid Complication: Avoid complicated configurations as well as customization. For complex business logic, code can be more modular and expressive, while complicated configuration can become an incomprehensible tangled mess.

2.3 Create Modular Solutions

Enterprises have essential complexity and scale. Since we are creating custom solutions for an enterprise, we need to pay the price of doing modular design and development. When each module encapsulates its data and logic and defines minimum interfaces, it can be integrated, deployed, evolved, and replaced more easily.

Key Recommendations

• Encapsulation and Loose Coupling: Keep data, logic, and UI self-contained. Expose functionality via minimal, well-defined interfaces.
• Second-Generation Packaging (2GP): Use 2GP to define package dependencies explicitly. Ensure each module can be readily deployed with its dependencies into a scratch org (essential for CI/CD). This way, the development and release process can be easily automated.
• Scratch Org Deployability: Make solutions scratch-org-friendly to streamline development and testing. Maintain robust test coverage for consistent deployments.
• Reusable Building Blocks: Build shared utility packages (e.g., Apex service classes, Lightning Web Components) that multiple modules can consume. Keep shared modules focused to avoid creating an unwieldy “mega package.”

2.4 Carefully Guard Data Integrity and Cultivate Data Quality

Poor data quality erodes user trust, increases maintainable costs, and poisons the blood of an enterprise. Salesforce organizations with ungoverned data models and scattered processes often spend excessive time on maintenance rather than innovation.

Key Recommendations

• Data Governance Framework: Assign clear ownership for each core object (Account, Contact, Opportunity). Enforce metadata documentation, data validations, and change controls.
• Master Data Management (MDM): Work with enterprise architects on an MDM strategy and implement it in Salesforce. Data Cloud offers a well-designed data model that can help to normalize Salesforce data.
• Metadata and Documentation: Document data are enriched from external data sources. For data with lifecycle, like opportunity and order, create state transition diagrams to document their changes. Document how asynchronous processes like batch jobs change data. The best place to put in the documentation is the Salesforce metadata. For example, Salesforce supports not only description for objects and fields but also data classification. (Data Classification Metadata Fields )
• Protect Data Integrity from APIs: Salesforce’s default REST/SOAP CRUD APIs can bypass business logic and lead to data inconsistencies if exposed openly. Design APIs deliberately to guard internal details and preserve data integrity.?

2.5 Design Record Sharing

Record sharing in an enterprise, especially for regulated industries, must be designed intentionally. An ad hoc approach leads to confusion or accidental security issues.

Key Recommendations

• Auditable Sharing Architecture: Define sharing rules for each object and each record. Use organization-wide defaults (OWDs), role hierarchies, and sharing rules. Minimize or eliminate manual sharing. Use Apex Sharing for complex scenarios but anchor it in well-documented business rules.
• Regular Sharing Audit Maintainance: When exceptions happen with Apex sharing, records sharing can be messed up, causing operating burden and security risk. So, it’s important to monitor sharing issues and fix them based on business rules.?

2.6 Build With Reliable, Well-Mastered Tools

Not all point-and-click tools scale gracefully for complex use cases. “Clicks before code” may not apply in the enterprise—true mastery of a tool (whether declarative or programmatic) is key.?

Key Recommendations

• Evaluate Tool Limitations: Declarative tools often make easy things easier, but hard things impossible. So, be aware. Choose tools that can handle future complexity. Reject tools that do not support modular development. In enterprise software development, modularity is non-negotiable. Tools must support automated deployments and source-driven development. If any tool forces manual post-deployment steps, it will entangle CI/CD pipeline and introduce project risk.
• Favor Tried & True Technologies for Complex Requirements: Apex and Lightning Web Components (LWCs) provide clarity, testability, and modular design for complex needs. Use declarative solutions (e.g., flows) where truly appropriate.
• Mastery Before Commitment: A new technology is a project risk and must be managed as such. Ensure the team fully understands a new tool before adopting it broadly. Conduct proof-of-concept projects to validate future requirements.?

2.7 Manage Assumptions, Dependencies, and Risks

In large enterprises, inter-team and external dependencies are common. Unclear or unvalidated assumptions can derail projects.

Key Recommendations

• Document Assumptions and Dependencies: Create a risk register at project kickoff. Map both external and internal dependencies explicitly.
• Collaborate With Project Management: Incorporate risk tracking into the project plan. Schedule regular checkpoints to validate critical assumptions.
• Communicate Risks Proactively: Share risk logs in status updates with stakeholders and leadership. Escalate critical risks early rather than after deadlines are missed.
• Plan for Mitigation: Build fallback options if external deliverables fail (e.g., vendor solutions). Maintain open channels with external teams to resolve or reduce dependencies.

3. Conclusion

By adhering to these principles—keeping Salesforce fit, solutions modular, and data integrity and quality paramount—we ensure the platform remains efficient, agile, and innovative in an enterprise context. While being principled requires discipline, it yields substantial business benefits:

• Maximize Value from Salesforce’s continuous innovation.
• Protect Data Integrity through robust governance, record-sharing frameworks, and well-defined APIs.
• Foster Modular, Reusable Solutions for long-term implementation efficiency.
• Control Technical Debt with disciplined design and governance practices.
• Enhance Collaboration by managing risks, assumptions, and dependencies across teams.

I’d value your feedback and thoughts on using Salesforce effectively in the enterprise.

Reference:

• The platform play: How to operate like a tech company | McKinsey, February 28, 2019