Data Modeling and Data Management
Data Modeling and Data Management
This domain tests whether you can design a model that survives volume, sharing, and change - and then manage data across its whole lifecycle, from migration to archive to deletion.
Core modeling choices
- Reuse standard objects before creating custom ones; every new object adds reporting, sharing, and maintenance cost.
- Lookup versus master-detail: master-detail gives cascade delete, roll-up summaries, and inherited ownership, with a maximum of two master-detail relationships per object. Lookup gives independent sharing and an optional relationship.
- Junction objects for many-to-many. Avoid multi-select picklists for anything you must report on.
- Record types vary process, not data shape.
- External IDs, ideally unique, enable upsert and idempotent integration.
- Person Accounts versus the Individual model: Person Accounts simplify consumer reporting but cannot be disabled once enabled, and they consume account and contact storage.
Lifecycle management
Migration runs extract → profile → cleanse and dedupe → map → load in dependency order → reconcile. Deduplication uses matching rules, duplicate rules, and survivorship. Archiving moves the inactive window to Big Objects, an external store via Salesforce Connect, or a warehouse, keeping the active window in core objects. Retention and erasure obligations (for example GDPR deletion requests) must be designed, not improvised.
Worked example
A retailer has 25 million consumers and 300,000 B2B accounts. Person Accounts would reduce object count and simplify consumer reporting, but they double storage for the consumer base and complicate B2B sharing. The Individual model keeps party data separate with a lookup from Contact. Reasoning: if 80% of revenue is B2B and consumers are marketing-only, the Individual model wins. If consumer service is in scope, Person Accounts win because agents need one record. The decision hinges on the journey, not on schema elegance - and it is irreversible, so it must be made deliberately.
Traps that cost marks
Forgetting that master-detail cascade deletes remove children. Assuming record ownership equals access. Changing a field type on a large object while users are active. Reporting on multi-select picklists. Enabling Person Accounts without confirming irreversibility. Ignoring storage and field-history limits. Designing a model without a data-retention story.
Key points
- Choose lookup versus master-detail by deletion, ownership, and roll-up needs.
- Person Account enablement is permanent - decide with the journey in mind.
- Unique external IDs make integrations idempotent.
- Plan migration order and reconciliation before loading.
- Archive strategy belongs in the data model, not in a later phase.