Domain Grilling: D3 Data
AI-Generated Content — Use for Reference Only
This content is AI-generated and has only been validated by AI review processes. It has NOT been reviewed or validated by certified Salesforce CTAs or human subject matter experts. Do not rely on this content as authoritative or completely accurate. Use it solely as a reference point for your own study and preparation. Always verify architectural recommendations against official Salesforce documentation.
Data architecture decisions cascade through security, integration, and performance. Judges test whether you understand the downstream consequences of modeling choices, can handle LDV scenarios, and have a realistic data migration strategy. Every modeling choice has implications for sharing, reporting, and governor limits.
Type 1: Invalid — “Your Solution Won’t Work”
These questions challenge a flaw in your design. The judge believes your approach is technically incorrect or impossible.
Q1.1: Master-Detail with Cascade Delete Risk
Judge: “You used Master-Detail between Account and a custom Compliance Record object. If a sales rep deletes their Account, all Compliance Records are cascade deleted. In a financial services scenario, that violates regulatory retention requirements. Is that acceptable?”
What they’re testing: Whether you understand cascade delete behavior on Master-Detail and its regulatory implications.
Model answer: “That’s a critical flaw. Master-Detail cascade deletes all detail records when the parent is deleted, and for regulatory compliance records that must be retained for 7-10 years, that’s unacceptable. I would change this to a Lookup relationship, which orphans the child record instead of deleting it. The trade-off is that I lose roll-up summary fields and sharing inheritance. For roll-ups, I would use Flow or DLRS (Declarative Lookup Rollup Summaries). For sharing, I would design independent sharing rules on the Compliance Record object. Additionally, I would remove the Delete permission on Account from all non-admin profiles and implement a validation rule or trigger that prevents Account deletion when active Compliance Records exist, providing a belt-and-suspenders approach to protecting regulatory data.”
Q1.2: Skinny Tables with Full-Table-Scan Queries
Judge: “You mentioned using skinny tables for your 20-million-record Account table, but your list views use non-selective LIKE queries on Description. The query optimizer won’t use the skinny table for non-selective queries. How does this help your performance?”
What they’re testing: Whether you understand query selectivity and how the optimizer decides whether to use indexes or skinny tables.
Model answer: “You’re right — the query optimizer only uses skinny tables and custom indexes when the query is selective. A LIKE query on a non-indexed Long Text Area field like Description forces a full table scan regardless of skinny tables. I need to address the query pattern itself, not just the storage optimization. First, I would redesign the list view to use indexed filterable fields as the primary filter — Status, Region, OwnerId — and move the description search to a global search (SOSL) which uses the search index rather than SOQL. Second, for the selective queries that do use indexed fields, the skinny table still helps by reducing I/O since it excludes deleted records and contains only the subset of columns needed. The combination of selective indexed queries plus skinny tables is the correct LDV strategy — but the non-selective description search needs to be redesigned, not optimized.”
Q1.3: Big Objects in Standard Reports
Judge: “You archived historical Cases older than 2 years to a Big Object, but the compliance team runs standard reports on case history for annual audits. Big Objects aren’t available in standard reports. How do they get their data?”
What they’re testing: Whether you understand Big Object limitations around reporting and have a realistic access pattern.
Model answer: “That’s correct — Big Objects cannot be used in standard reports, dashboards, list views, or most declarative tools. They can only be queried via SOQL on the composite key fields, which makes them unsuitable for ad-hoc reporting. For the compliance audit requirement, I have three options. First, I could build a custom Lightning component backed by Apex that queries the Big Object and presents the data in a report-like format — this works for structured queries where the auditor knows what they need. Second, I could use an asynchronous process that extracts the required Big Object data into a temporary custom object before the annual audit, allowing standard reports to run on that snapshot. Third, and this may be the best fit, I could archive to an external data store like Snowflake instead of Big Objects, and use Tableau for the compliance reporting — Tableau can query the external archive directly. The right choice depends on the audit query patterns and frequency.”
Q1.4: External ID Without Uniqueness
Judge: “You’re using an External ID field for deduplication during data migration, but you didn’t mark it as unique. Without uniqueness enforcement, duplicate records can still be created during upsert operations. Doesn’t that defeat the purpose?”
What they’re testing: Whether you understand the difference between External ID (for upsert matching) and Unique + External ID (for dedup enforcement).
Model answer: “You’re right that without the Unique flag, the External ID field will still match for upsert operations, but it won’t prevent duplicate creation if two records with the same external ID are inserted (not upserted) or if the upsert processes records in parallel batches that haven’t committed yet. I should mark the field as both External ID and Unique. This gives me belt-and-suspenders: the upsert operation uses the External ID for matching, and the uniqueness constraint rejects any duplicates that slip through. For the migration, I would also use single-threaded serial mode on the initial load to avoid the race condition where parallel batches create duplicates before the uniqueness constraint is evaluated. After the initial load, the unique External ID prevents duplicates from any subsequent integration loads.”
Type 2: Missed — “You Haven’t Addressed…”
These questions point out a requirement you didn’t cover.
Q2.1: Data Skew Strategy
Judge: “Your data model has a custom Interaction object with a lookup to Account, and you mentioned some accounts will have over 100,000 child Interaction records. You haven’t addressed lookup skew. What’s your strategy?”
What they’re testing: Whether you understand data skew — account skew, ownership skew, and lookup skew — and its impact on performance and locking.
Model answer: “Lookup skew occurs when a single parent record has a disproportionate number of child records, which causes lock contention during concurrent DML on children and slows sharing recalculation. For accounts with 100,000+ Interactions, I would implement several mitigations. First, if the Interaction-to-Account relationship is Lookup rather than Master-Detail, I can decouple the sharing — the Interaction object can have its own OWD and sharing model without inheriting from the skewed Account. Second, I would optimize the Apex and Flow automation on Interactions to use ‘without sharing’ context where appropriate to avoid the sharing evaluation overhead. Third, I would configure the Interaction object with selective indexing on the Account lookup field to help the query optimizer. Fourth, for the data load pattern, I would batch Interaction inserts by Account to minimize lock contention. If the skew is extreme, I would consider an architectural pattern where Interactions reference Accounts via a text External ID field rather than a lookup, sacrificing referential integrity for performance — though this is a last resort.”
Q2.2: Data Quality and Deduplication
Judge: “You’ve designed a beautiful data model and migration plan, but you haven’t mentioned data quality or deduplication at all. How do you ensure clean data?”
What they’re testing: Whether you treat data quality as an architectural concern, not an afterthought.
Model answer: “Data quality should be designed into the architecture, not bolted on. I would address this at three layers. First, prevention: duplicate rules with matching rules on Account (using fuzzy matching on name, exact match on website or DUNS number) and Contact (email, phone, name). These fire on both UI entry and API loads, with alerts for potential duplicates and blocking rules for exact matches. Second, data profiling during migration: before loading any legacy data, I would run a data profiling exercise to identify nulls, orphaned records, format inconsistencies, and duplicates in the source system. The migration ETL would include transformation rules for standardization — address formatting, phone number normalization, status value mapping. Third, ongoing governance: a monthly batch job using Apex that runs deduplication matching and flags suspected duplicates for manual review, combined with validation rules that enforce format standards on critical fields. For the CTA scenario, I would also recommend a data steward role responsible for ongoing quality monitoring.”
Q2.3: Backup and Recovery Strategy
Judge: “What happens if someone accidentally mass-deletes 50,000 records? What’s your data recovery strategy?”
What they’re testing: Whether you have a recovery plan beyond the Recycle Bin.
Model answer: “The Salesforce Recycle Bin holds deleted records for 15 days, with a limit of 25 times your org’s storage (in number of records). For 50,000 records, the Recycle Bin would likely hold them if the org’s limit is not exceeded. But relying on the Recycle Bin alone is insufficient for a mission-critical system. I would recommend a third-party backup solution — OwnBackup or Grax — that performs daily full and incremental backups to customer-controlled cloud storage. This provides point-in-time recovery independent of Salesforce’s Recycle Bin. For the data model, I would also consider a soft-delete pattern for critical objects — a ‘Deleted’ checkbox field with a validation rule that prevents hard deletion, combined with list view filters that exclude soft-deleted records. The hard-delete permission would be restricted to a single admin profile. For the mass-delete scenario specifically, I would implement an Apex trigger that prevents deletion of more than a configurable threshold of records in a single transaction, requiring admin approval for bulk operations.”
Type 3: Suboptimal — “Have You Considered…?”
These questions suggest a potentially better approach.
Q3.1: Junction Objects vs Multi-Select Picklist
Judge: “You have three junction objects connecting Products to Categories, Regions, and Channels. Is that the simplest model that meets the requirements? Have you considered multi-select picklist fields instead?”
What they’re testing: Whether you can justify the added complexity of junction objects over simpler alternatives.
Model answer: “I considered multi-select picklists and they would simplify the data model significantly — one field on Product for each of Categories, Regions, and Channels. But I chose junction objects for three specific reasons. First, the scenario requires reporting on product performance by category, region, and channel combination. Multi-select picklist fields cannot be used in report groupings or cross-filters effectively — you would need formula fields or custom report types with complex filtering. Junction objects support native cross-object reporting. Second, the categories and regions have their own attributes — Category has a ‘Revenue Target’ field and Region has a ‘Territory Manager’ lookup — which cannot be modeled on a picklist value. Third, the assignment of products to categories changes over time, and the business needs an audit trail of when assignments changed. Junction objects with Field History Tracking provide this; picklist changes only show the full value change. If the requirement were simply tagging products with static labels for filtering, multi-select picklists would be the right simpler choice.”
Q3.2: Person Accounts vs Custom Individual Object
Judge: “You built a custom ‘Individual’ object for B2C customer records. Have you considered Person Accounts? They’re designed for exactly this.”
What they’re testing: Whether you evaluated the standard platform feature before building custom.
Model answer: “I considered Person Accounts and chose a custom object because the scenario has both B2B and B2C customers in the same org. Person Accounts fundamentally change the Account and Contact data model — they merge Account and Contact into a single record for individuals, which means every Apex trigger, Flow, validation rule, and report on Account and Contact must be tested for Person Account compatibility. The existing B2B implementation has 15 Apex triggers and 20 Flows on Account and Contact. Enabling Person Accounts would require regression testing all of them. The trade-off is that my custom Individual object does not get the native Person Account integrations with Marketing Cloud, campaigns, and other standard features. If this were a greenfield B2C-only implementation, Person Accounts would be the clear choice. In this mixed B2B/B2C org with heavy existing customization, the risk of enabling Person Accounts outweighs the benefit.”
Q3.3: Normalized vs Denormalized for Reporting
Judge: “Your data model is highly normalized — seven related objects to get from Opportunity to the final revenue figure. Have you considered denormalizing to improve reporting performance?”
What they’re testing: Whether you understand the normalization-denormalization trade-off in the context of Salesforce governor limits.
Model answer: “I considered denormalization and chose a normalized model because the data has clear referential integrity requirements — each of those seven objects represents a distinct business entity with its own lifecycle and permissions. However, you raise a valid concern about reporting. Standard reports support at most four-object joins in custom report types, so the seven-object chain cannot be reported on natively. I would address this with a hybrid approach: maintain the normalized transactional data model for data integrity, but create a denormalized summary object — a ‘Revenue Snapshot’ custom object — populated by a scheduled Flow or Batch Apex that flattens the seven-object chain into a single reportable record. This gives reporting users a simple, flat table while preserving the normalized model for transactions. The trade-off is data freshness — the snapshot runs nightly, so reports are 24 hours behind. If real-time reporting across the seven objects is required, CRM Analytics dataflows would be more appropriate.”
Q3.4: External Objects vs ETL Replication
Judge: “You’re replicating 2 million ERP records nightly into Salesforce custom objects. Have you considered External Objects via Salesforce Connect? You’d avoid the storage cost and the nightly ETL.”
What they’re testing: Whether you evaluated data virtualization as an alternative to replication.
Model answer: “I considered Salesforce Connect with External Objects and chose replication for three reasons. First, the scenario requires Salesforce users to filter, sort, and report on the ERP data using standard list views and reports. External Objects have limited support in standard reports — they work in custom report types but with restrictions on grouping, formulas, and joined reports. Second, the ERP data is used in Salesforce automation — record-triggered Flows reference ERP product data to set default values. External Objects cannot participate in formula fields, roll-up summaries, or be referenced in many declarative automation contexts. Third, offline access for field users requires the data to be in Salesforce. The trade-off is 2 million records consuming approximately 4 GB of data storage (at ~2 KB per record, the standard Salesforce allocation for most objects), which I mitigate by archiving ERP records older than 12 months to a Big Object. If the requirement were purely display-only — showing ERP data in a related list for reference — External Objects would be the simpler, cheaper choice.”
Type 4: Rationale Missing — “WHY Did You Choose…?”
These questions probe the reasoning behind a correct decision.
Q4.1: Relationship Type Choice Reasoning
Judge: “Why did you use a Lookup relationship between Opportunity and the custom Quote_Line__c object instead of Master-Detail?”
What they’re testing: Whether you deliberately chose Lookup over Master-Detail with specific reasoning.
Model answer: “I chose Lookup for three reasons specific to this scenario. First, the business process requires quote lines to occasionally exist without a parent Opportunity — during the pre-qualification phase, the sales team creates preliminary pricing that may or may not become a formal quote. Master-Detail requires the parent field to always be populated, which would break this workflow. Second, quote lines need their own sharing model independent of the Opportunity. The pricing team needs access to all quote lines for analysis, but they should not see the Opportunity details. With Master-Detail, sharing is inherited from the parent and cannot be independently controlled. Third, the existing integration with the ERP system creates quote lines via API before the Opportunity is created, then links them afterward. Master-Detail would require creating the Opportunity first, changing the integration sequence. The roll-up summary I lose by choosing Lookup is implemented via a Flow that calculates the total quote amount on Opportunity.”
Q4.2: LDV Archival Decision
Judge: “Walk me through your archival strategy. Why did you choose a 90-day threshold, and why Big Objects instead of an external archive?”
What they’re testing: Whether the archival design is driven by access patterns and business requirements, not arbitrary numbers.
Model answer: “The 90-day threshold comes from analyzing the actual data access patterns in the current system. Usage analytics showed that 92% of Case queries involve cases created within the last 90 days, and only 3% of queries reference cases older than 6 months. By archiving at 90 days, I keep the active dataset under 2 million records, which maintains query performance without LDV mitigations like skinny tables. I chose Big Objects over an external archive because the archived data needs to be accessible from within Salesforce — the compliance team has occasional but time-sensitive needs to pull historical case data during audits. Big Objects keep the data on-platform, queryable via SOQL on the composite key, without requiring an external system integration. The trade-off is that Big Objects lack standard reporting and ad-hoc query flexibility. If the compliance team needed full reporting capabilities on archived data, I would choose Snowflake as the archive target and Tableau for reporting, accepting the added infrastructure cost.”
Q4.3: Migration Tool Choice
Judge: “Why are you using MuleSoft for data migration instead of Data Loader? It seems like overkill for a one-time load.”
What they’re testing: Whether you can justify a complex tool choice for migration versus simpler alternatives.
Model answer: “Data Loader would be sufficient for a simple, single-object load with clean data. I chose MuleSoft because this migration involves 12 source systems with different formats — 3 SQL databases, 2 CSV exports, SAP BAPI calls, and legacy API endpoints. The migration requires real-time transformation logic: deduplication across sources, field value mapping from 8 different status taxonomies to one standardized set, and parent-child load sequencing across 15 objects. MuleSoft’s DataWeave transformations handle the format and value mapping, and the orchestration engine manages the load sequence — Accounts before Contacts before Opportunities before Quote Lines. Data Loader would require multiple separate loads with manual sequencing, external scripting for transformations, and no orchestration for error handling and retry. The trade-off is cost and complexity, but since MuleSoft is already in the architecture for ongoing integrations, I am leveraging the same infrastructure for migration rather than introducing a separate tool.”
Q4.4: Data Model: Custom Object vs Extending Standard
Judge: “You created a custom ‘Product_Configuration__c’ object. Why didn’t you extend the standard Product2 object with custom fields?”
What they’re testing: Whether you evaluated the standard object before creating custom.
Model answer: “Product2 is the standard product catalog object, and I use it for the base product definition — name, family, description, active status. Product_Configuration__c represents a specific configuration of a product for a specific customer — it has fields like configuration parameters, pricing overrides, and approval status that change per deal. This is a fundamentally different entity from the master product definition. If I added these fields to Product2, every product record would carry configuration fields that are irrelevant to the catalog definition, and I would need record types to distinguish catalog products from customer configurations. More critically, Product2 has a specific relationship with PricebookEntry and OpportunityLineItem that is tightly coupled to the standard pricing and quoting workflow. My configuration object participates in a different workflow — it flows through an approval process and feeds into a custom CPQ integration. Keeping them separate preserves the clean semantics of each object.”
Type 5: Cascading — “If You Change X, What Happens to Y?”
These questions test cross-domain dependency awareness.
Q5.1: Relationship Type Change Impact
Judge: “You just changed the Account-to-Project relationship from Master-Detail to Lookup. What else changes in your architecture?”
What they’re testing: Whether you understand the full cascade of switching relationship types.
Model answer: “Changing from Master-Detail to Lookup cascades through four areas. First, sharing: Projects no longer inherit sharing from Account. I need to set an independent OWD for the Project object and create sharing rules — likely criteria-based on the Project’s Business Unit field — to replicate the access that was previously inherited. Second, roll-up summaries: any roll-up summary fields on Account that aggregated Project data (total project value, project count) stop working. I need to replace them with Flow-calculated fields or DLRS. Third, ownership: Project records now have their own OwnerId field, whereas under Master-Detail they inherited the Account owner. I need a process to set the Project owner — either defaulting to the creating user or matching the Account owner via automation. Fourth, reporting: any reports that used the Master-Detail implicit join need to be rebuilt using custom report types with the Lookup relationship. Fifth, for the data migration, existing Project records need their OwnerId field populated before the relationship type can be converted.”
Q5.2: Archival Strategy Change Impact on Analytics
Judge: “You archived data to Big Objects after 90 days, but the analytics team just told you they need 5-year trending data for their CRM Analytics dashboards. How does your archival strategy accommodate that?”
What they’re testing: Whether you can reconcile short-term operational performance with long-term analytical needs.
Model answer: “The archival strategy and analytics requirement are in tension. CRM Analytics dataflows can connect to Salesforce objects but not directly to Big Objects. I have three options. First, before archiving records, I run a CRM Analytics dataflow that extracts the data into a CRM Analytics dataset. The dataset persists independently of the source records, so the 5-year trend is maintained in the analytics layer even after the operational records are archived. The trade-off is that CRM Analytics dataset storage has its own limits. Second, I could implement a dual-write pattern: when records are archived to Big Objects, they are simultaneously written to an external data warehouse like Snowflake, and CRM Analytics connects to Snowflake via an external connector for the historical data. Third, I could adjust the archival window to align with the analytics requirement — but keeping 5 years of operational data defeats the purpose of archiving. I would recommend option one — capturing the analytical footprint before archiving — because it keeps the analytics self-contained on-platform.”
Q5.3: Data Model Change Impact on Integration
Judge: “You just added a new junction object between Account and Product to model account-specific product entitlements. How does that affect your existing integrations?”
What they’re testing: Whether you recognize that data model changes ripple into every integration that touches the affected objects.
Model answer: “Adding the junction object affects integrations in three ways. First, the ERP integration that syncs product catalogs now needs to be extended to also create or update Account_Product_Entitlement__c records when the ERP assigns products to customers. This means new API calls, new field mappings in the MuleSoft dataflow, and new error handling for the junction object. Second, the existing Account sync integration needs to be aware that deleting or merging Accounts may orphan or conflict junction records — the integration must handle cascading deletes or reassignment of entitlements during account merges. Third, the reporting integration that exports account data to the data warehouse needs a new extract for the junction object, along with updated joins in the warehouse schema. Fourth, the load sequence for data migration now has a new dependency: Accounts and Products must exist before their junction records can be created. I would update the MuleSoft orchestration to add this step in the correct sequence and add error handling for missing parent records.”
Q5.4: Storage Limit Impact on Data Strategy
Judge: “The client just told you their data storage is at 85% capacity and growing. How does that change your data architecture?”
What they’re testing: Whether you can adapt the data strategy under storage pressure and identify the right levers.
Model answer: “Storage pressure cascades through multiple architectural decisions. First, immediate actions: audit storage usage by object to identify the largest consumers, delete orphaned records and clean up Recycle Bin items, and remove unused custom objects. Second, archival acceleration: move the archival threshold from 90 days to 60 or 45 days for the largest objects, moving older records to Big Objects which use separate storage. Third, data model optimization: evaluate whether any large-volume objects can use external objects via Salesforce Connect instead of local storage — the 2 million ERP records I replicated nightly are consuming approximately 4 GB and could be candidates for virtualization if we can accept the reporting trade-offs. Fourth, file strategy: if Salesforce Files are contributing significantly, evaluate moving to Files Connect with SharePoint or S3 as external storage. Fifth, integration review: ensure integrations are not creating unnecessary duplicate or temporary records. Sixth, long-term: evaluate purchasing additional storage versus upgrading to Unlimited edition which provides 120 MB per user versus Enterprise’s 20 MB. The architectural change with the biggest impact is usually shifting from data replication to data virtualization for non-transactional data.”
Related Topics
This is a personal study site for Salesforce CTA exam preparation. Built with AI assistance. Not affiliated with Salesforce.