TECH **Salesforce Administrator: Custom Objects, Fields, and Field Types – Zero-Fluff Study Guide**

Salesforce Administrator: Custom Objects, Fields, and Field Types – Zero-Fluff Study Guide

(Picklist, Formula, Roll-Up Summary, Lookup vs. Master-Detail)

1. What This Is & Why It Matters

You’re a Salesforce Admin. Your org is growing, and users are drowning in spreadsheets, sticky notes, and "shadow IT" (Google Sheets, Notion, or worse—Excel macros). Leadership wants a single source of truth for things like: - Project tracking (not just Opportunities) - Employee onboarding (beyond standard HR objects) - Custom inventory management (for a retail team) - Event registrations (for a marketing team)

Custom Objects are your Lego blocks. Fields are how you store data inside those blocks. Field Types determine what kind of data you store (text, numbers, relationships, calculations) and how it behaves.

Why this matters in production:
- If you mess up relationships (Lookup vs. Master-Detail), data integrity breaks. Example: Deleting an Account deletes all related Contacts (Master-Detail) vs. leaving them orphaned (Lookup).
- If you misuse Roll-Up Summaries, reports slow to a crawl. They recalculate in real-time—great for accuracy, terrible for performance if overused.
- If you hardcode picklist values, global changes become a nightmare. (Ever had to update 50 picklists manually? Don’t.) - If you don’t use Formulas, users waste hours on manual calculations. Example: A "Discount %" field that auto-calculates based on Opportunity Stage.

Real-world scenario:
You inherit a Salesforce org where the Sales team tracks "Deals" in a custom object, but: - The "Deal Amount" field is a text field (users type "$10,000" instead of 10000).
- The "Deal Owner" is a text field (users type names, leading to duplicates).
- The "Total Deals Won" on the Account page is manually updated (and always wrong).
- The "Deal Stage" picklist has 15 values, but only 3 are used.

Your mission: Fix this mess without breaking existing reports, dashboards, or integrations.

2. Core Concepts & Components

? Custom Object

• Definition: A database table in Salesforce that stores data not covered by standard objects (Account, Contact, Opportunity, etc.).
• Production insight: Custom objects are the foundation of any custom app in Salesforce. If you need to track something not in the standard data model, you’ll use these.
• Example: Project__c, Employee_Onboarding__c, Event_Registration__c.

? Field

• Definition: A column in a custom (or standard) object that stores a specific piece of data.
• Production insight: Fields determine what data you capture and how it’s validated. A poorly designed field (e.g., text instead of picklist) leads to dirty data.

? Field Types (Critical Ones)

3. Step-by-Step Hands-On: Building a Custom "Deal" Object

Prerequisites

• Salesforce org (Developer Edition is fine).
• System Administrator permissions.

Task:

Create a custom "Deal" object with: 1. A Master-Detail relationship to Account (so deleting an Account deletes its Deals).
2. A Roll-Up Summary on Account to show "Total Deal Amount." 3. A Formula field to calculate "Discounted Amount." 4. A Picklist for "Deal Stage" with validation.

Step 1: Create the Custom Object

1. Setup → Object Manager → Create → Custom Object.
2. Label: Deal
3. Plural Label: Deals
4. Object Name: Deal__c (auto-filled, but confirm).
5. Description: Tracks sales deals not covered by Opportunities.
6. Record Name: Deal Name (auto-number: DEAL-{0000})
7. Check: Allow Reports, Allow Activities, Track Field History.
8. Save.

Step 2: Create a Master-Detail Relationship to Account

1. On the Deal__c object, go to Fields & Relationships → New.
2. Data Type: Master-Detail Relationship.
3. Related To: Account.
4. Field Label: Account
5. Field Name: Account__c (auto-filled).
6. Child Relationship Name: Deals (this is how the relationship appears on the Account page).
7. Sharing Setting: Read/Write (default).
8. Save.

✅ Verify:
- Go to an Account record → Related tab → You should see a "Deals" related list.
- Try creating a Deal → The "Account" field is required.

Step 3: Add Fields to the Deal Object

A. Currency Field (Deal Amount)

1. Fields & Relationships → New.
2. Data Type: Currency.
3. Field Label: Deal Amount
4. Field Name: Deal_Amount__c.
5. Length: 16 (default).
6. Decimal Places: 2.
7. Required: ✅ (check).
8. Save.

B. Picklist Field (Deal Stage)

1. Fields & Relationships → New.
2. Data Type: Picklist.
3. Field Label: Deal Stage
4. Field Name: Deal_Stage__c.
5. Values:
6. Prospecting
7. Qualification
8. Proposal
9. Negotiation
10. Closed Won
11. Closed Lost
12. Restrict picklist to the values defined in the value set: ✅ (check).
13. Default Value: Prospecting.
14. Save.

C. Formula Field (Discounted Amount)

1. Fields & Relationships → New.
2. Data Type: Formula.
3. Field Label: Discounted Amount
4. Field Name: Discounted_Amount__c.
5. Formula Return Type: Currency.
6. Formula:
   plaintext
Deal_Amount__c * (1 - Discount_Percent__c / 100)
   (Note: You’ll need to create a Discount_Percent__c Number field first if it doesn’t exist.)
7. Decimal Places: 2.
8. Save.

D. Roll-Up Summary (Total Deal Amount on Account)

1. Go to the Account object → Fields & Relationships → New.
2. Data Type: Roll-Up Summary.
3. Field Label: Total Deal Amount
4. Field Name: Total_Deal_Amount__c.
5. Summarized Object: Deals (the child relationship name from Step 2).
6. Select Roll-Up Type: SUM.
7. Field to Aggregate: Deal Amount.
8. Filter Criteria: (Leave blank to include all Deals.)
9. Save.

✅ Verify:
- Create 3 Deals under an Account with amounts: $100, $200, $300.
- Go to the Account → The Total Deal Amount should show $600.

4. ? Production-Ready Best Practices

? Security

• Master-Detail relationships enforce sharing rules. If a user can’t see the parent (Account), they can’t see the child (Deal).
• Use Field-Level Security (FLS) to restrict sensitive fields (e.g., Discount_Percent__c).
• Avoid hardcoding picklist values in formulas. Use TEXT(Deal_Stage__c) instead of "Prospecting".

? Cost Optimization

• Roll-Up Summaries are expensive. If you have 10,000+ records, consider:
• Scheduled Flows (run nightly instead of real-time).
• DLRS (Declarative Lookup Rollup Summaries) – a free AppExchange tool for complex rollups.
• Avoid overusing Formula fields. They recalculate on every record load—can slow down page performance.

?️ Reliability & Maintainability

• Naming conventions:
• Objects: PascalCase__c (e.g., Project__c).
• Fields: Snake_Case__c (e.g., Start_Date__c).
• Picklists: Verb_Noun (e.g., Closed_Won, In_Progress).
• Always add descriptions to fields/objects. Future you (or your successor) will thank you.
• Use Global Picklists for values used across multiple objects (e.g., "Status" picklist for Deals, Projects, and Cases).

? Observability

• Track field history on critical fields (e.g., Deal_Stage__c, Deal_Amount__c).
• Monitor Roll-Up Summary performance in Setup → Storage Usage (large rollups can cause timeouts).
• Use Reports & Dashboards to monitor:
• Deals with no Deal_Stage__c (data quality).
• Accounts with no Deals (adoption).

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus

Typical Question Patterns

1. "Which field type should you use for a calculated discount?"
2. ✅ Formula (correct).
3. ❌ Roll-Up Summary (only aggregates child records).

4. ❌ Text (not calculated).

5. "You need to ensure deleting an Account deletes all related Deals. Which relationship?"

6. ✅ Master-Detail (correct).

7. ❌ Lookup (child records remain).

8. "How do you standardize picklist values across multiple objects?"

9. ✅ Global Picklist (correct).

10. ❌ Copy-paste values (maintenance nightmare).

11. "A Roll-Up Summary isn’t calculating. What’s the most likely cause?"

12. ✅ The relationship is Lookup, not Master-Detail (correct).
13. ❌ The field is hidden (Roll-Ups work even if hidden).

⚠️ Trap Distinctions

7. ? Hands-On Challenge (With Solution)

Challenge:

You have a custom "Project" object with a Lookup relationship to Account. Users complain that deleting an Account leaves orphaned Projects. How do you fix this without breaking existing reports?

Solution:

1. Convert the Lookup to a Master-Detail relationship.
2. Go to Project object → Fields & Relationships → Edit the Account__c field.
3. Change Data Type from Lookup to Master-Detail.
4. Save.
5. Update sharing settings (if needed) to ensure users can still access Projects.

✅ Why it works:
- Master-Detail enforces cascading deletes, so deleting an Account deletes its Projects.
- Existing reports may need updates (e.g., filters on AccountId), but the data model is now correct.

8. ? Rapid-Reference Crib Sheet

9. ? Where to Go Next

1. Salesforce Custom Objects Documentation
2. Roll-Up Summary Fields Best Practices
3. DLRS (Declarative Lookup Rollup Summaries) – Free AppExchange Tool
4. Salesforce Trailhead: Custom Objects & Fields

Final Pro Tip:

Always test in a Sandbox first. Changing field types (e.g., Lookup → Master-Detail) can break integrations, reports, and Flows. Backup your metadata before making changes.

Now go build something awesome. ?