Data Modeling and Management

Relationships are the heart of data modeling in Salesforce and represent the most asked exam area in the Data Modeling domain.

Complete comparison table:

Feature	Master-Detail (MD)	Lookup
Required parent field	✅ Yes, always	❌ No, can be blank
Cascade delete	✅ Automatic (children deleted)	❌ No (orphan records created)
Roll-Up Summary Fields	✅ Available natively	❌ Not native (use Flow or Apex)
Child record OWD	Inherited from parent	Independent from parent
Maximum per object	2	40
Reparenting (change parent)	Configurable (disabled by default)	✅ Always possible
Child ownership	Controlled by parent	Own and independent
Required field	Always required	Configurable
Standard Objects as child	❌ Cannot create	✅ Yes

Hierarchical Relationship:
Special Lookup type that exists ONLY on the User object. Creates reporting hierarchies (Manager → Employee). Used to define reporting chains and for hierarchy-based Sharing Rules.

Self-Relationship:
A Lookup relationship where an object relates to itself. Example: Parent Account → Child Account (Account Hierarchy). Useful for modeling corporate structures.

Converting between types:
- Lookup → Master-Detail: Possible ONLY if all child records already have a value in the parent field (no null values).
- Master-Detail → Lookup: Possible at any time.

Golden exam rule:
- Need Roll-Up Summary or cascade delete? → Master-Detail
- Is the parent field optional or do you need independent OWD? → Lookup
- Is the child a Standard Object (Account, Contact, etc.)? → Lookup (MD doesn't allow standard objects as children)

Salesforce does not support direct many-to-many relationships. The solution is to create a Junction Object with two Master-Detail relationships.

Practical example: Student ↔ Course
1. Create custom object Enrollment__c (Junction Object).
2. Master-Detail #1: Enrollment__c → Student__c (primary parent).
3. Master-Detail #2: Enrollment__c → Course__c (secondary parent).

Junction Object behavior:
- The first Master-Detail created is the primary parent and controls:
- The OWD (Organization-Wide Default) of the Junction Object.
- The look-and-feel of the Junction Object's tab.
- The first Lookup in Data Loader operations.
- Both parents can show Related Lists from the Junction Object.
- Both parents can have Roll-Up Summary Fields calculating data from the Junction.
- Additional fields can be added to the Junction Object to store relationship data (e.g., Grade__c, Enrollment_Date__c, Status__c).

Other common Junction Object examples (asked in the exam):
- OpportunityLineItem (Standard): Junction between Opportunity and Product2.
- CampaignMember (Standard): Junction between Campaign and Lead/Contact.
- Project_Assignment__c (Custom): Junction between Employee__c and Project__c.

Important rules:
- A Junction Object needs exactly 2 Master-Detail relationships.
- An object can be a parent in multiple Junction Objects.
- You cannot create more than 2 Master-Detail on the same object.
- Related Lists on both parents automatically show Junction Object fields.

Deep knowledge of field types is essential for the exam.

Formula Fields:
- Read-only fields that calculate a value based on other fields.
- Support cross-object formulas: access parent fields (e.g., Account.Industry).
- Can cross up to 10 levels of relationships.
- Limit: 5,000 compiled characters (not visible characters, but compiled).
- Return types: Text, Number, Date, DateTime, Checkbox, Percent, Currency.
- CANNOT be used in: Record-Triggered Flow criteria (before save), or as report sorting fields.

Most asked formula functions:
- ISBLANK(field) / ISNULL(field): Checks if a field is empty. Use ISBLANK (ISNULL is legacy).
- ISPICKVAL(picklist, 'value'): Compares picklists. Do NOT use = for picklists.
- TEXT(picklist): Converts picklist to text for text operator usage.
- PRIORVALUE(field): Value before the change (updates only).
- ISCHANGED(field): TRUE if the field changed (updates only).
- ISNEW(): TRUE if the record is being created (not updated).
- CASE(field, 'val1', result1, 'val2', result2, default): Switch/equivalence.
- IF(condition, trueValue, falseValue): Basic conditional.
- HYPERLINK(url, label): Creates a clickable link.
- IMAGE(url, alt): Displays an image.
- NOW() vs TODAY(): NOW = current DateTime, TODAY = date only.
- DATEVALUE(dateTime): Extracts the date part from a DateTime.
- YEAR(), MONTH(), DAY(): Extract date parts.

Roll-Up Summary Fields:
- Calculate aggregate values on the parent object based on child records in a Master-Detail relationship.
- Available operations: COUNT, SUM, MIN, MAX.
- Filter criteria can be applied (e.g., only count 'Closed Won' opportunities).
- NOT available on Lookup relationships (use Flow to simulate).
- Only created on the parent object, never on the child.

Picklists:
- Standard Picklist: Simple value list.
- Multi-Select Picklist: Allows selecting multiple values (semicolon-separated). Has limitations: can't easily use in report criteria, doesn't support ISPICKVAL.
- Global Value Set: Reusable value set shared across multiple picklists on different objects. Changing a value in the Global Set changes it on all fields using it.
- Dependent Picklist: A picklist that displays different values based on another picklist's selection (controlling field). The controlling field can be a standard picklist or a checkbox.

Other important fields:
- Auto-Number: Generates sequential number automatically (e.g., CASE-{0000}). Read-only.
- External ID: Indexed field for identifying records in integrations. Enables Upsert operations. Maximum 7 External IDs per object. Text, Number, or Email fields can be External ID.
- Encrypted Field (Classic): Encrypted text field. Only users with 'View Encrypted Data' permission can see the value.
- Geolocation: Stores latitude and longitude coordinates.

Record Types allow offering different business processes, picklist values, and page layouts for different types of records within the same object.

When to use Record Types?
- When different user groups need to see different fields or layouts for the same object.
- When an object serves multiple purposes (e.g., 'Account' can be Customer, Vendor, or Partner).
- When you need different picklist values based on context.

Record Types control:
1. Page Layouts: Different page designs per Record Type + Profile.
2. Picklist Values: Each Record Type can display a different subset of picklist values.
3. Business Processes: For Opportunity (Sales Process), Lead (Lead Process), Case (Support Process).

Business Processes:
Subsets of standard stages for certain objects:

Object	Process	Controlled Field
Opportunity	Sales Process	Stage (StageName)
Lead	Lead Process	Lead Status
Case	Support Process	Case Status
Solution	Solution Process	Solution Status

Example: You can have a Sales Process 'Enterprise Sales' with detailed stages (Prospecting → Qualification → Proposal → Negotiation → Closed Won/Lost) and another 'Quick Sales' with only 3 stages (New → In Progress → Closed).

Record Type Assignment:
- Record Types are assigned to Profiles (and Permission Sets with the correct permission).
- A profile can have a default Record Type per object.
- If a profile only has access to one Record Type, the Record Type selector is NOT shown when creating a record.
- If a profile has access to multiple Record Types, a selector appears when creating.

Page Layout Assignment:
Page Layout assignment is a matrix of Record Type × Profile. Each combination can have a different layout.

Example:

Sales Profile	Support Profile	Admin Profile
RT: Customer	Sales-Customer Layout	Support-Customer Layout	Admin Layout
RT: Vendor	Sales-Vendor Layout	Support-Vendor Layout	Admin Layout

Schema Builder:
Visual tool showing objects, fields, and relationships as an interactive entity-relationship diagram.

What Schema Builder CAN do:
- Visualize relationships between objects (Standard and Custom).
- Create new custom objects directly in the diagram.
- Create new fields by dragging the field type to the object.
- View data type, API name, and label for each field.
- Filter which objects are displayed in the diagram.

What Schema Builder CANNOT do (frequent question):
- ❌ Create validation rules.
- ❌ Create flows or automations.
- ❌ Create page layouts.
- ❌ Create triggers or code.
- ❌ Import or export data.
- ❌ Create Record Types.

Data Import Tools:

Feature	Data Import Wizard	Data Loader
Record limit	50,000	Millions
Interface	Web (within Setup)	Desktop application / CLI
Supported objects	Accounts, Contacts, Leads, Solutions, Custom Objects	All objects
Deduplication	✅ Built-in (by Salesforce ID, Name, Email)	❌ Manual
Operations	Insert, Update, Upsert	Insert, Update, Upsert, Delete, Hard Delete, Export, Export All
Schedulable	❌ No	✅ Yes (command line)
Import Accounts+Contacts together	✅ Yes	❌ Separately
External ID for matching	✅ Yes	✅ Yes

When to use each tool?
- Data Import Wizard: Simple imports under 50,000 records, especially Accounts, Contacts, or Leads. Perfect for non-technical users.
- Data Loader: Massive imports, scheduled operations, data deletion, or when working with objects DIW doesn't support.

Upsert Operation (Update + Insert):
Combines update and insert in a single operation. Uses an External ID or Salesforce ID for matching:
- If it finds an existing record with that ID → Update.
- If not found → Insert (creates new record).

Data Export:
- Data Export Service: Native Salesforce tool for exporting all org data as CSV files. Available weekly (Professional) or monthly. Accessed from Setup.
- Data Loader Export: Exports records from a specific object with SOQL filters.
- Reports: Can also export data as CSV.

Maintaining clean data is critical in Salesforce. The exam asks about native data quality tools.

Duplicate Rules:
Control what happens when a user tries to create or edit a record that is a duplicate.

Configurable actions:
- Alert: Shows a warning to the user but allows saving.
- Block: Prevents the record from saving if it's a duplicate.
- Different actions can be configured for creation vs update.

Matching Rules:
Define the criteria for identifying potential duplicates. A Matching Rule specifies which fields to compare and with what logic.

Match types:
- Exact: Values must be identical.
- Fuzzy: Allows approximate matches (e.g., 'Jon' vs 'John', 'Acme Inc' vs 'Acme Inc.').

Salesforce includes preconfigured Standard Matching Rules for Account, Contact, and Lead using fuzzy matching on fields like Name, Email, Street, City, Phone.

Relationship between Duplicate Rules and Matching Rules:
1. Create a Matching Rule defining comparison criteria.
2. Create a Duplicate Rule referencing the Matching Rule and defining the action (Alert or Block).
3. When a user saves a record, Salesforce executes the Matching Rule → if duplicates detected → applies the Duplicate Rule's action.

Merge (Record Merging):
- Up to 3 Accounts or 3 Contacts or 3 Leads can be merged at once.
- When merging, a master record is chosen and the others are deleted.
- Related records (Opportunities, Cases, etc.) are reassigned to the master record.
- Master record fields are kept, but values from other records can be selected.

Other data quality concepts:
- Mass Transfer Records: Tool for changing the owner of multiple records at once.
- Mass Delete Records: Delete records in bulk based on search criteria.
- Recycle Bin: Deleted records remain in the recycle bin for 15 days and can be restored.

Both store custom configurations, but have crucial differences for the exam.

Custom Settings:
- Store configuration data at the organization, profile, or user level.
- Two types:
- List Custom Settings: Reusable data set (like a configuration table). Accessed with getAll(), getInstance(name) methods.
- Hierarchy Custom Settings: Have Org → Profile → User hierarchy. The most specific value wins. Accessed with getInstance() which automatically respects the hierarchy.
- They are data (not metadata), so they are NOT automatically migrated with Change Sets.
- Can be accessed in formulas with $Setup.SettingName__c.Field__c.

Custom Metadata Types (CMT):
- Store configurations as metadata (not as data).
- Suffix __mdt on the type name.
- Main advantage: They deploy with Change Sets and packages like any metadata.
- Can be used in:
- Formulas: $CustomMetadata.Type__mdt.Record__mdt.Field__c
- Validation Rules
- Flow Builder (Get Records)
- Apex code
- They are Salesforce's recommended option for deployable configurations.

Exam comparison:

Feature	Custom Settings	Custom Metadata Types
Data type	Data (records)	Metadata
Migratable with Change Sets	❌ No (only structure, not data)	✅ Yes (structure + records)
Hierarchy support	✅ Yes (Hierarchy type)	❌ No
Formula access	✅ $Setup	✅ $CustomMetadata
SOQL to query	✅ Yes	✅ Yes (doesn't count against SOQL limits)
Salesforce recommendation	Legacy (use CMT)	✅ Preferred

Exam rule: If a question mentions configurations that need to be deployed between environments → Custom Metadata Types. If you need different values per profile/user → Hierarchy Custom Setting.