Large Data Volumes

💬 In plain words: Treat a Salesforce data migration like a precision flight operation. Always load parent records before child records so lookup IDs exist. Switch off automation using bypass flags and defer sharing calculations. Rehearse the entire load in a Full Copy Sandbox with production-size data, time every single step, and lock in a tested rollback plan. Cutover weekend should just be a boring replay of what you already practiced.

⚡ Key Points: 1-Minute Summary Data Skew: Having 10,000+ records assigned to a single owner, parent, or lookup target causes severe record locking and sharing recalculation storms. Skinny Tables : Specialized, pre-joined tables created by Salesforce Support to bypass complex database joins and dramatically speed up hot read paths. Custom Indexes: Applied selectively to high-traffic filters by Salesforce Support. Crucially, negative filters (e.g., != ) and leading wildcards cannot use indexes. PK Chunking: The secret weapon for extracting massive datasets via the Bulk API by slicing the export by Salesforce ID ranges. Query Plan Tool: The built-in Developer Console feature you must use to prove to Salesforce Support that a custom index is actually needed. 💬 In plain words: Once an object hits tens of millions of rows, normal Salesforce features start breaking. You must use specialized tools: Skinny Tables (pre-joined copies for fast ...

💬 In plain words: Big Objects are a cheap warehouse shelf for billions of old rows: fast to store. But no triggers, no flows, no standard reports, and limited queries. They are an ARCHIVE , not a working table — move cold data there and keep the hot data lean. 📌 Example: 7 years × 50M banking transactions can't live on a custom object. Keep 18 months hot, and let a nightly batch move older rows to Transaction_Archive__b (Big Object). The audit team queries the archive by AccountId + date via a custom LWC. 🎬 Real-Life Example: 40 Million Scans and a Dying Report Every parcel gets scanned at pickup, hub, van, and door. That is 40 million Scan__c rows a year. The Old/Bad Way: Keep every scan in the normal custom object forever. Storage costs climb. List views time out. Reports crawl. Every SOQL filter fights an ocean of dead rows. Why this is bad: Normal objects are built for records people work on today. Th...