sf-agent-framework

# Salesforce Data Model Reference ## Overview The Salesforce data model is built on a relational database architecture with standard and custom objects, relationships, and fields that support business processes and reporting. ## Core Data Model Concepts ### Objects **Standard Objects**: Pre-built objects provided by Salesforce - Account, Contact, Lead, Opportunity - Case, Solution, Campaign - Product, Pricebook, Quote - User, Profile, Role **Custom Objects**: Organization-specific objects - API names end with \_\_c - Up to 2,000 custom objects per org - Supports all standard features - Can have custom tabs and page layouts ### Fields **Standard Fields**: System and pre-defined fields - Id: Unique 15/18 character identifier - Name: Primary label field - CreatedDate, CreatedById - LastModifiedDate, LastModifiedById - OwnerId: Record ownership - IsDeleted: Soft delete flag **Custom Fields**: User-defined fields - API names end with \_\_c - Multiple data types available - Can be required or unique - Support validation rules - Field-level security ### Relationships **Lookup Relationships**: - Loosely coupled relationship - Child can exist without parent - No cascade delete - Up to 40 lookups per object **Master-Detail Relationships**: - Tightly coupled relationship - Child requires parent - Cascade delete - Roll-up summary fields - Sharing inherited from parent - Up to 2 per custom object **Many-to-Many Relationships**: - Junction object pattern - Two master-detail relationships - Enables complex associations ## Standard Object Model ### Sales Cloud Objects **Lead**: - Unqualified prospects - Converts to Account, Contact, Opportunity - Fields: Name, Company, Email, Status, Rating - Key Process: Lead conversion **Account**: - Companies or organizations - Parent for Contacts, Opportunities - Fields: Name, Type, Industry, Annual Revenue - Hierarchy support via ParentId **Contact**: - People associated with Accounts - Fields: Name, Email, Phone, Title - Multiple Contacts per Account - Can be related to multiple Accounts **Opportunity**: - Potential revenue-generating deals - Fields: Name, Amount, CloseDate, Stage - Links to Account and Contact - Products via OpportunityLineItem **Relationships**: ``` Account (1) ← → (∞) Contact Account (1) ← → (∞) Opportunity Opportunity (1) ← → (∞) OpportunityLineItem OpportunityLineItem → Product2 ``` ### Service Cloud Objects **Case**: - Customer service requests - Fields: Subject, Priority, Status, Origin - Links to Account and Contact - Parent-child case hierarchy **Solution**: - Knowledge base articles - Many-to-many with Cases - Fields: SolutionName, Status, IsPublished **Entitlement**: - Customer support agreements - Links to Account, Contact - Service contracts and SLAs ### Platform Objects **User**: - System users - Fields: Username, Email, Profile, Role - Owns records via OwnerId - Complex permission model **Profile**: - Base permissions and settings - Object/field access - Page layout assignments - Record type access **Role**: - Hierarchical structure - Data access via role hierarchy - Territory management ## Data Model Patterns ### Parent-Child Pattern ``` Account └── Contact └── Opportunity └── OpportunityLineItem ``` **Implementation**: - Use when clear ownership exists - Leverage roll-up summaries - Consider sharing implications ### Junction Object Pattern ``` Campaign ← → CampaignMember ← → Lead/Contact ``` **Implementation**: ```sql CampaignMember: - CampaignId (Master-Detail to Campaign) - LeadId (Lookup to Lead) - ContactId (Lookup to Contact) - Status (Member status) ``` ### Hierarchy Pattern ``` Account └── Account (via ParentId) └── Account └── Account ``` **Implementation**: - Self-relationship via lookup - Maximum 5 levels for roll-ups - Consider performance impacts ### History Tracking Pattern **Field History**: - Tracks changes to specific fields - Stores old and new values - Limited retention (18-24 months) **Custom History**: ``` Custom_Object__c └── Custom_Object_History__c - Parent__c (Master-Detail) - Field_Name__c - Old_Value__c - New_Value__c - Changed_Date__c - Changed_By__c ``` ## Data Types and Limits ### Field Data Types **Text Types**: - Text: Up to 255 characters - Text Area: Up to 131,072 characters - Rich Text: HTML formatting, images - Encrypted Text: Platform encryption **Number Types**: - Number: Decimal with precision - Currency: Respects org currency - Percent: Stored as decimal - Auto Number: System-generated **Date/Time Types**: - Date: Calendar date only - DateTime: Date and time - Time: Time only (beta) **Logic Types**: - Checkbox: Boolean true/false - Picklist: Single selection - Multi-Select Picklist: Multiple selections - Formula: Calculated fields **Relationship Types**: - Lookup: Loose coupling - Master-Detail: Tight coupling - External Lookup: External objects - Hierarchical: Self-relationship ### Object Limits - Standard Objects: ~100+ - Custom Objects: 2,000 (varies by edition) - Fields per Object: 500-800 - Relationships per Object: 40 lookups, 2 master-detail - Characters per Field Name: 40 - Characters per Object Name: 40 ## Data Modeling Best Practices ### Naming Conventions **Objects**: ``` Standard: Account, Contact Custom: Project__c, Invoice__c Junction: ProjectTeamMember__c ``` **Fields**: ``` Standard: Name, Phone, Email Custom: Total_Revenue__c, Project_Status__c Formula: Days_Open__c, Is_Overdue__c ``` **Relationships**: ``` Lookup: Related_Account__c Master-Detail: Invoice__c (on Line Item) Self: Parent_Case__c ``` ### Design Principles 1. **Normalize Appropriately**: Balance normalization with usability 2. **Think Reporting**: Design for reporting needs 3. **Consider Sharing**: Understand security implications 4. **Plan for Scale**: Design for data growth 5. **Minimize Complexity**: Simple is maintainable ### Relationship Guidelines **When to Use Lookup**: - Optional relationships - Need independent security - Circular dependencies - Maximum flexibility **When to Use Master-Detail**: - Required relationships - Need roll-up summaries - Inherit sharing - Cascade delete required ### Performance Considerations **Indexing**: - Standard fields auto-indexed - Custom fields selectively indexed - External IDs always indexed - Unique fields indexed **Query Optimization**: ```sql -- Efficient: Uses indexed fields SELECT Id, Name FROM Account WHERE Id = '001xx000003DHPh' -- Inefficient: Non-indexed field SELECT Id, Name FROM Account WHERE Custom_Text__c = 'Value' ``` **Skinny Tables**: - Improve query performance - Selected fields only - Contact Salesforce support - Read-only copies ## Complex Data Scenarios ### Product and Pricing Model ``` Product2 (Master catalog) └── PricebookEntry (Price in specific book) └── OpportunityLineItem (Products on deals) └── QuoteLineItem (Products on quotes) Pricebook2 (Price lists) └── PricebookEntry ``` ### Territory Management ``` Territory2 └── Territory2 (Hierarchy) └── UserTerritory2Association └── ObjectTerritory2Association └── Account/Opportunity ``` ### Person Accounts - Combines Account and Contact - B2C business model - Special considerations: - Can't convert back - Some features unavailable - Report considerations ## Data Architecture Patterns ### Multi-Org Strategy **Single Org**: - Shared data model - Unified reporting - Lower complexity - Cost effective **Multi-Org**: - Business unit isolation - Geographic separation - Acquisition integration - Regulatory requirements ### Large Data Volumes (LDV) **Considerations**: - > 10 million records - Performance impacts - Archival strategies - Query optimization critical **Strategies**: - Custom indexes - Skinny tables - Divisions - External objects - Big objects ### External Objects - Real-time integration - No data storage in Salesforce - OData protocol - Limited functionality - Good for reference data ## Metadata and Schema ### Schema Access ```apex // Describe objects Schema.DescribeSObjectResult describe = Account.sObjectType.getDescribe(); String label = describe.getLabel(); Boolean isCustom = describe.isCustom(); // Describe fields Map<String, Schema.SObjectField> fields = describe.fields.getMap(); for(String fieldName : fields.keySet()) { Schema.DescribeFieldResult field = fields.get(fieldName).getDescribe(); System.debug(field.getLabel() + ': ' + field.getType()); } ``` ### Dynamic SOQL ```apex String objectName = 'Account'; String fields = 'Id, Name, Type'; String query = 'SELECT ' + fields + ' FROM ' + objectName + ' LIMIT 10'; List<SObject> records = Database.query(query); ``` ## Best Practices Summary 1. **Understand Requirements**: Before designing 2. **Standard First**: Use standard objects when possible 3. **Relationships Matter**: Choose carefully 4. **Think Security**: Design with sharing in mind 5. **Plan for Growth**: Scalable architecture 6. **Document Design**: Maintain data dictionary 7. **Test Thoroughly**: Include volume testing 8. **Monitor Performance**: Regular health checks 9. **Iterate Design**: Continuous improvement 10. **Train Users**: On data model implications