#JourneyToCTA Diaries Part 6 - Data Architecture Design Strategy

In the previous blog, we explored data categorization — a foundational concept that must be mastered before moving into data model design. Categorizing data correctly shapes every architectural decision that follows. Designing a data model that aligns with business needs, leverages Salesforce-native capabilities, and remains scalable over time depends heavily on understanding these core design principles.

As a Salesforce architect, your responsibility goes beyond configuring objects and fields. You must first understand the business processes end to end and translate them into a conceptual and logical blueprint. Only after that foundation is clear should you begin aligning those blueprints with Salesforce core data models for Sales and Service, along with supporting models such as Field Service, Scheduler, Authorization Management, and other capability-specific extensions.

Architecture must be business-led, not feature-led.

Conceptual Data Design: Modelling the Business, Not the Platform

At the conceptual stage, deep business understanding is critical. You are not yet designing for the database — you are designing for how the business operates.

This stage focuses on mapping data flows and business rules that create, transform, and consume data throughout a process. Business processes effectively act as data pipelines: they generate inputs, apply rules, enforce validations, and ultimately make data usable for different personas across the organization.

Industry context plays an equally important role. Telecom, banking, insurance, healthcare, and other industries each have domain-specific entities and lifecycle expectations. Aligning your conceptual entities to these industry patterns ensures the model reflects real-world operations and avoids unnecessary rework later.

At the conceptual level, architects must:

• Align on key data entities based on the business process (such as Accounts, Products, Orders, Cases, Assets, or industry-specific entities)

• Define entity relationships and integrity expectations

• Establish required security policies to ensure proper data segregation across personas

• Clarify ownership of each entity throughout its lifecycle

  
  

This stage defines what exists in the business domain and how it behaves, without yet committing to platform-specific implementation decisions.

Logical Data Design: Mapping Business to Platform

Once the conceptual model is validated, the logical design stage begins. The objective here is to map business entities to the underlying Salesforce architecture while considering standards, platform capabilities, best practices, and inherent constraints of a multi-tenant database environment.

At this stage, decisions become more technical. You are no longer asking what exists in the business — you are determining how it should be implemented responsibly within Salesforce.

A key focus is enforcing data integrity between operational data and reference data. This requires a clear understanding of Salesforce relationship types (master-detail, lookup, many-to-many via junction objects, external objects) and using them appropriately to reflect business rules without compromising scalability.

Data retention and archiving strategies must also be defined early. Master and reference data often have long lifecycles — for example, Accounts and Contacts may need to remain in the system until they are no longer prospects or until regulatory deletion is requested. In contrast, high-volume transactional records such as Orders or Cases may be archived more aggressively once their lifecycle concludes, particularly when analytics requirements can be satisfied through aggregated datasets.

Security and privacy requirements must be embedded into the logical design. This includes ensuring that data visibility and edit access align with persona-based access controls. In some cases, additional protection mechanisms may be required — such as encryption at rest or in transit for sensitive information like payment data. Selecting and correctly configuring the appropriate Salesforce tools becomes essential at this stage.

Although Salesforce abstracts much of the underlying infrastructure, data flows and integration pipelines still require deliberate design. Data transforms and replicates across systems and processes, and maintaining integrity throughout these flows is critical. Logical design must therefore account for how data is created, synchronized, enriched, and archived across the ecosystem.

Conclusion

Conceptual design defines the business truth. Logical design aligns that truth with platform reality.

Skipping either stage often results in rework, performance challenges, or governance gaps. Strong data architecture requires disciplined progression: categorize the data, model the business conceptually, and only then map it logically to the platform with full awareness of capabilities and trade-offs.