Salesforce Interview Questions That Trip Candidates — Triggers, Governor Limits, Relationships & Packages Explained With Real World Examples

📅 Admin

Salesforce Admin & Developer Interview Questions — Clouds, Automation, Relationships, Packages Explained

⚙️ Admin & Developer

Salesforce Admin & Developer Interview Questions — Clouds, Automation, Relationships & Packages Explained

Sales Cloud vs Service Cloud, Record Types, Governor Limits, Triggers, Packages & More — Real Scenarios for Interviews

Intermediate Advanced 16 Questions

Questions Index

1Sales Cloud vs Service Cloud 2When to Suggest Page Layout vs Record Type 3Why Can't Profiles & Roles Do It? 4Different Types of Lookup Relationships 5Max Lookup & Master-Detail Per Object 6Count Lookup Child Records on Account 7Workflow & Process Builder vs Flow 8Types of Exceptions in Apex 9What Are 101 & 151 Errors? 10Getting 101 Error — How to Resolve? 11Governor Limits in Salesforce 12How Many Triggers Per Object? 13Why Only 1 Trigger — Salesforce Design? 14Ways to Make a Field Required 15Managed vs Unmanaged Packages 161 Advantage of Managed Package

Question 01 · 🟠 Intermediate

What is the difference between Sales Cloud and Service Cloud in Salesforce?

✅ Answer

Both are CRM products on the same Salesforce platform — but Sales Cloud is built for closing deals (pipeline, leads, opportunities) while Service Cloud is built for resolving issues (cases, support, agents). 🎯

📋 Core Comparison

Feature	Sales Cloud	Service Cloud
Primary Focus	Lead → Opportunity → Revenue	Case → Resolution → Satisfaction
Key Objects	Lead, Opportunity, Quote	Case, Entitlement, Work Order
Key Features	Forecasting, Territory Mgmt	Omni-Channel, Live Agent, Knowledge
Console	Sales Console	Service Console
SLA Tracking	❌	✅ Entitlements & Milestones
CTI / Telephony	❌ Limited	✅ Built-in support
Field Service	❌	✅ FSL Add-on

✅❌ What Each Actually Controls

✅Sales Cloud → Manages the revenue pipeline from Lead to closed deal
✅Service Cloud → Manages post-sales customer support and case resolution
❌Neither is "better" — many companies use both together in the same org
✅Both share the same platform, Apex, LWC, and core objects like Account & Contact

🌍 Real World Example (XYZ Company)

Your company uses Sales Cloud — Leads from IndiaMART → Opportunity → Quote → Order. If you added after-sales complaint management with SLA tracking, that would be Service Cloud territory.

🔑 Key Points for Interviewer

🔥Both run on the same Salesforce platform and can be in the same org
💡Service Cloud adds Case Management, Omni-Channel, Knowledge Base, Entitlements
💡Sales Cloud adds Forecasting, Opportunity Splits, Territory Management
💡They are licensed separately — you pay for what you need

🎤 One-Line Answer for Interview

"Sales Cloud focuses on the lead-to-revenue process, while Service Cloud focuses on post-sales support and case resolution — both run on the same Salesforce platform but are licensed separately."

Question 02 · 🟠 Intermediate

When will you suggest to the client to go for Page Layout vs Record Type?

✅ Answer

Use Record Type when users need different Picklist values or Business Processes. Use Page Layout when only field visibility or arrangement needs to change. 🎯

📋 When to Use What

Scenario	Use
Different fields visible for different teams	Page Layout
Different picklist values for different teams	Record Type ✅
Different Sales / Support processes	Record Type ✅
Same data, just different field order	Page Layout
A/B user experience on same record type	Page Layout assigned to Profile
Multiple business units using same object	Record Type ✅

✅❌ What Each Actually Controls

✅Page Layout → Field order, Required fields, Related Lists, Button visibility
✅Record Type → Picklist values, Page Layout assignment (per profile), Business Process
❌Page Layout alone cannot restrict picklist values
❌Record Type alone doesn't reorder fields — it assigns a layout

🌍 Real World Example (XYZ Company)

Your Quote object — Domestic and Export quotes may need different currency picklist values and approval processes → that's a Record Type call. But if the Export team just needs a few extra fields visible, a separate Page Layout assigned to their profile is enough.

🔑 Key Points for Interviewer

🔥Record Type is the parent, Page Layout is assigned under it per profile
💡You need at least 2 Record Types to assign 2 different Page Layouts per profile
💡Record Types also drive Business Processes for Opportunity, Case, Lead, Solution
💡Default Record Type matters — users without a choice get the default

🎤 One-Line Answer for Interview

"I suggest Page Layout when only UI arrangement changes, and Record Type when the business process, picklist values, or user experience fundamentally differs between groups."

Question 03 · 🟠 Intermediate

Why can't we do it with Profiles and Roles — why do we need Record Types?

✅ Answer

Profiles control access/permissions, Roles control data visibility — neither can control picklist values or page layout per business process. That's what Record Types exist for. ❌

📋 Layer Responsibilities

Feature	Profile	Role	Record Type	Page Layout
Field-level Security	✅	❌	❌	✅ (visibility only)
Picklist Values per group	❌	❌	✅	❌
Record Visibility	❌	✅	❌	❌
Page Layout Assignment	✅ (basic)	❌	✅ (with profile combo)	✅
Business Process	❌	❌	✅	❌

✅❌ What Each Actually Controls

✅Profile → Login access, Object CRUD, FLS, App visibility
✅Role → OWD-based record sharing upward in hierarchy
❌Role has zero impact on UI or field visibility
❌Profile alone can assign a layout but cannot restrict picklist values

🌍 Real World Example

If Domestic Sales and Export Sales are on the same profile, you cannot give them different Stage picklist values using Profile. You need a Record Type for that.

🔑 Key Points for Interviewer

🔥Profiles are security-layer, Roles are data-access-layer
💡Record Types bridge the gap for business process differentiation
💡This is a very common interview trap — know the boundary clearly

🎤 One-Line Answer for Interview

"Profiles handle permissions and Roles handle record visibility — neither can control picklist values or process-level differentiation, which is why Record Types exist."

Question 04 · 🟠 Intermediate

What are the different types of Lookup Relationships in Salesforce?

✅ Answer

There are 5 types of Lookup-style relationships in Salesforce — each with different behavior around deletion, ownership, and sharing. 🔗

📋 Relationship Types Comparison

Relationship	Cascade Delete	Sharing Inherited	Required on Child	Roll-up Summary
Master-Detail	✅	✅ From Parent	✅ Always	✅
Lookup	❌ Optional	❌	❌ Optional	❌
Hierarchical	❌	❌	❌	❌
External Lookup	❌	❌	❌	❌
Indirect Lookup	❌	❌	❌	❌

✅❌ What Each Actually Controls

✅Master-Detail → Tight coupling, child cannot exist without parent
✅Lookup → Loose coupling, child survives parent deletion (optional clear/restrict)
✅Hierarchical → Only for User object (e.g., Manager field)
✅External Lookup → Links to External Object via External ID
✅Indirect Lookup → Links Standard/Custom object to External Object via unique field

🌍 Real World Example (XYZ Company)

Your Order → Account is likely a Lookup. Your Order Line Items → Order is a Master-Detail (OLI can't exist without an Order).

🔑 Key Points for Interviewer

🔥Hierarchical is only for the User object — this is a very common trick question
💡External & Indirect Lookups are for Salesforce Connect / External Objects
💡A Lookup can be made required to behave almost like MD — but still no roll-up

🎤 One-Line Answer for Interview

"Salesforce has 5 lookup-style relationships: standard Lookup, Master-Detail, Hierarchical (User only), External Lookup, and Indirect Lookup — each differing in cascade behavior, sharing, and roll-up support."

Question 05 · 🟠 Intermediate

How many Lookup and Master-Detail relationships can an object have?

✅ Answer

Max 2 Master-Detail and up to 40 total relationship fields (including Lookups) per object. ✅

📋 Relationship Limits

Relationship Type	Maximum Allowed
Master-Detail	2
Lookup	40 (shared with MD in total count)
Total Relationship Fields	40 per object

✅❌ What This Actually Controls

✅2 MD max → object becomes a junction object when both slots are used
✅40 total relationship fields per object (MD + Lookup combined)
❌You cannot add a 3rd MD — Salesforce will block it at setup

🌍 Real World Example

Junction Object like Campaign Member has MD to both Campaign and Contact — that uses both MD slots. It creates a Many-to-Many relationship.

🔑 Key Points for Interviewer

🔥When an object has 2 MDs → it's called a Junction Object (Many-to-Many)
💡Roll-up Summary fields are only available on MD parent, not Lookup parent
💡Converting MD to Lookup is possible but Roll-up Summaries must be deleted first

🎤 One-Line Answer for Interview

"An object can have a maximum of 2 Master-Detail relationships and up to 40 total relationship fields including Lookups — when both MD slots are used, it becomes a Junction Object for Many-to-Many relationships."

Question 06 · 🔴 Advanced

Account has 2 Master-Detail relationships and 1 Lookup relationship. How do you get a count of Lookup child records on Account?

✅ Answer

Use a Roll-Up Summary for MD children. For the Lookup child, Roll-Up Summary doesn't work — use a Trigger, Flow, or DLRS to maintain a count field on Account. 🔢

📋 Method Per Relationship Type

Child Relationship	Count Method
Master-Detail Child 1	✅ Roll-Up Summary (COUNT) directly on Account
Master-Detail Child 2	✅ Roll-Up Summary (COUNT) directly on Account
Lookup Child	❌ No native Roll-Up → Use Trigger / Flow / DLRS

🔧 Option 1 — Apex Trigger (Most Reliable)

// On the Lookup child object — After Insert, After Delete, After Undelete
trigger CountLookupChildren on LookupChild__c (after insert, after delete, after undelete) {
    Set<Id> accountIds = new Set<Id>();
    List<LookupChild__c> records = Trigger.isDelete ? Trigger.old : Trigger.new;
    for (LookupChild__c r : records) {
        if (r.Account__c != null) accountIds.add(r.Account__c);
    }
    List<Account> toUpdate = new List<Account>();
    for (AggregateResult ar : [
        SELECT Account__c accId, COUNT(Id) cnt
        FROM LookupChild__c
        WHERE Account__c IN :accountIds
        GROUP BY Account__c
    ]) {
        toUpdate.add(new Account(
            Id = (Id)ar.get('accId'),
            Lookup_Child_Count__c = (Integer)ar.get('cnt')
        ));
    }
    update toUpdate;
}

📋 All 3 Options Compared

Approach	Works on Lookup?	No Code?	Best For
Roll-Up Summary	❌ MD only	✅	Master-Detail only
Apex Trigger	✅	❌	Complex logic, insert+delete+undelete
Record-Triggered Flow	✅	✅ Mostly	Simple count, no-code teams
DLRS (AppExchange)	✅	✅	Declarative, enterprise orgs

🌍 Real World Example (XYZ Company)

If Account has a custom Lookup child like Complaint__c, you'd write a trigger on Complaint__c to keep Account.Total_Complaints__c up to date — handling insert, delete, and undelete events.

🔑 Key Points for Interviewer

🔥Classic interview trap — show you know Roll-Up doesn't work on Lookup
💡DLRS (Declarative Lookup Rollup Summary) is the go-to declarative AppExchange solution — mention it for extra points
💡Trigger approach must handle insert + delete + undelete all three events

🎤 One-Line Answer for Interview

"Roll-Up Summary works only on Master-Detail. For a Lookup child count on Account, I'd use an Apex Trigger handling insert/delete/undelete, a Record-Triggered Flow, or the DLRS AppExchange tool — DLRS is the most elegant declarative solution."

Question 07 · 🟠 Intermediate

What was the advantage of Workflow Rules and Process Builder over Flow?

✅ Answer

Historically they were simpler for basic automations — but Salesforce has officially retired both in favor of Flow. The real answer today is: there is no advantage — Flow covers everything they did and more. 🚨

📋 Historical Comparison

Feature	Workflow Rule	Process Builder	Flow
Complexity	Very Simple	Moderate	Full Power
Learning Curve	Low	Low-Medium	Medium-High
Multi-object update	❌	✅ Limited	✅
Loops / Collections	❌	❌	✅
Before-save logic	❌	❌	✅
Callouts / Apex	❌	✅ Apex	✅
Retirement Status	⚠️ Retired	⚠️ Retired	✅ Active

✅❌ Historical Advantages (Past Tense Only)

✅Workflow → Extremely fast to set up, Time-Based Actions were simpler to configure
✅Process Builder → Visual click-based UI, easier for non-developers
❌Both had severe governor limit issues at scale
❌Neither supported loops, complex logic, or subflows

🔑 Key Points for Interviewer

🔥Workflow & PB are officially retired — Salesforce wants everything in Flow
💡The only relevance today is legacy orgs that haven't migrated yet
💡Knowing this shows maturity — never recommend Workflow/PB for new builds

🎤 One-Line Answer for Interview

"Workflow and Process Builder were simpler for basic automations, but Salesforce has retired both — Flow now covers all their functionality with far more power and flexibility, so there's no reason to use them in new implementations."

Question 08 · 🔴 Advanced

What are the different types of Exceptions in Salesforce Apex?

✅ Answer

Salesforce has System-defined and User-defined (Custom) exceptions in Apex — with LimitException being the only one that cannot be caught. 🚨

📋 Exception Types Reference

Exception Type	When It Occurs	Catchable?
DMLException	Insert/Update/Delete fails (validation rule, duplicate)	✅
QueryException	SOQL returns 0 or 2+ rows when 1 expected	✅
NullPointerException	Accessing property on a null object	✅
ListException	Accessing index out of bounds in a List	✅
LimitException	Governor limit exceeded	❌ Cannot be caught!
CalloutException	HTTP callout fails or times out	✅
MathException	Division by zero	✅
TypeException	Invalid type cast	✅
JSONException	JSON parsing / serialization error	✅
Custom Exception	User-defined business logic	✅

🔧 Custom Exception Example

// Custom exceptions must extend Exception class
public class InsufficientStockException extends Exception {}

// Usage
if (availableQty < requestedQty) {
    throw new InsufficientStockException('Not enough stock available!');
}

// Catching specific before generic
try {
    insert myOrder;
} catch (DMLException e) {
    System.debug('DML Error: ' + e.getDmlMessage(0));
} catch (Exception e) {
    System.debug('Generic Error: ' + e.getMessage());
}

🌍 Real World Example (XYZ Company)

In your BC integration triggers — a CalloutException needs to be caught so that a failed BC API call doesn't crash the whole Apex transaction and roll back unrelated record updates.

🔑 Key Points for Interviewer

🔥LimitException cannot be caught — it's platform-enforced and causes full rollback
💡Always catch specific exceptions before generic Exception in try/catch blocks
💡Custom exceptions must extend Exception class — mention this clearly
💡DMLException has .getDmlMessage(i) and .getDmlStatusCode(i) helper methods

🎤 One-Line Answer for Interview

"Apex has system exceptions like DMLException, QueryException, NullPointerException, and CalloutException — plus user-defined custom exceptions — with LimitException being the only one that cannot be caught since it's enforced at the platform level."

Question 09 · 🟠 Intermediate

What do 101 and 151 errors mean in Salesforce?

✅ Answer

These are Apex Governor Limit errors — 101 error = too many SOQL queries (limit is 100), 151 error = too many DML statements (limit is 150) in a single transaction. 🚨

📋 Error Reference Table

Error	Limit	Root Cause
101 Error	100 SOQL queries per sync transaction	SOQL query inside a for loop
151 Error	150 DML statements per sync transaction	DML (insert/update/delete) inside a for loop

✅❌ What This Actually Controls

✅100 SOQL queries per synchronous transaction
✅150 DML statements per synchronous transaction
❌These limits cannot be caught — LimitException is thrown and transaction rolls back
✅Async (Batch/Queueable/Future) methods get fresh governor limits

🌍 Real World Example (XYZ Company)

Classic mistake — putting a SOQL inside a for loop in a trigger. If 101+ records are processed at once, the query fires 101+ times → 101 error. The fix is always bulkification.

🔑 Key Points for Interviewer

🔥Root cause is almost always SOQL or DML inside a for loop
💡Fix = bulkify the code (collections + single query outside loop)
💡Use Limits.getQueries() to debug how many queries have been used at runtime

🎤 One-Line Answer for Interview

"101 and 151 are Apex governor limit violations — 101 means more than 100 SOQL queries fired in one transaction, and 151 means more than 150 DML statements, both caused by non-bulkified code with queries or DML inside for loops."

Question 10 · 🔴 Advanced

I'm getting a 101 error but my code has only 100 lines. How do I resolve it?

✅ Answer

Line count has nothing to do with it. A SOQL inside a loop can fire 100+ queries in just 5 lines if a trigger runs on 100+ records. Resolve it by bulkifying the code. 🔧

📋 Resolution Steps

Step	Action
1	Identify SOQL or DML inside for loops
2	Move SOQL outside the loop
3	Use Collections (List, Set, Map) to gather IDs first
4	Query once, store in Map, access in loop
5	Use `Limits.getQueries()` to verify count at runtime

🔧 Before & After Bulkification

// ❌ WRONG — triggers 101 error on bulk (SOQL inside loop)
for (Opportunity opp : Trigger.new) {
    List<Contact> contacts = [
        SELECT Id FROM Contact WHERE AccountId = :opp.AccountId
    ]; // FIRES 1 SOQL PER RECORD!
}

// ✅ RIGHT — 1 SOQL regardless of record count (Bulkified)
Set<Id> accIds = new Set<Id>();
for (Opportunity opp : Trigger.new) accIds.add(opp.AccountId);

Map<Id, List<Contact>> accContactMap = new Map<Id, List<Contact>>();
for (Contact c : [SELECT Id, AccountId FROM Contact WHERE AccountId IN :accIds]) {
    if (!accContactMap.containsKey(c.AccountId))
        accContactMap.put(c.AccountId, new List<Contact>());
    accContactMap.get(c.AccountId).add(c);
}
// Now loop Trigger.new and use accContactMap — 0 SOQL in loop ✅

🔑 Key Points for Interviewer

🔥Always bulkify triggers — assume 200 records minimum as the batch size
💡Use Limits.getQueries() and Limits.getLimitQueries() to debug
💡Async methods (Future/Queueable) reset governor limits but still can't have SOQL in loops

🎤 One-Line Answer for Interview

"A 101 error is a governor limit violation from SOQL inside a for loop — line count is irrelevant. The fix is bulkification: collect all IDs first, query once outside the loop using IN clause, and use a Map to access results inside the loop."

Question 11 · 🔴 Advanced

What are Governor Limits in Salesforce?

✅ Answer

Governor Limits are Salesforce's runtime guardrails to ensure fair resource usage in the multi-tenant shared platform — preventing one org from degrading performance for others. ⚙️

📋 Key Limits — Sync vs Async

Limit	Synchronous	Asynchronous
SOQL Queries	100	200
DML Statements	150	150
DML Rows	10,000	10,000
SOQL Rows Returned	50,000	50,000
CPU Time	10,000 ms	60,000 ms
Heap Size	6 MB	12 MB
Callouts	100	100
Future calls per transaction	50	—
Queueable jobs enqueued	50	—
Batch Apex concurrent jobs	5	—

✅❌ What This Actually Controls

✅Every Apex transaction (trigger, class, batch) has its own limit counter
✅Batch Apex gets fresh limits per execute() chunk
❌Limits reset per transaction — not per record
❌LimitException cannot be caught — transaction rolls back entirely

🌍 Real World Example (XYZ Company)

Your BC integration uses a Queueable to avoid SOQL limit issues from the INR Dated Conversion logic — exactly why async gets more CPU time (60s vs 10s sync).

🔑 Key Points for Interviewer

🔥Use System.Limits class to check limits in real-time during debugging
💡Batch Apex is the go-to solution when processing 10,000+ records
💡Always design for bulkification first — assume worst-case record volume

🎤 One-Line Answer for Interview

"Governor Limits are Salesforce's per-transaction resource caps — like 100 SOQL queries, 150 DML statements, 10,000 DML rows, and 10 seconds CPU time — enforced to protect the shared multi-tenant platform from resource abuse."

Question 12 · 🟠 Intermediate

How many Triggers can you write on an object in Salesforce?

✅ Answer

Technically you can write multiple triggers on one object — but best practice is exactly 1 trigger per object using the Trigger Handler pattern. ✅

📋 What Happens With Multiple Triggers

Scenario	What Happens
2 triggers, both on after insert	Both fire — but order is NOT guaranteed
Logic depends on execution order	Can cause bugs and data corruption
One trigger + handler class	Full control over execution sequence ✅

🔧 Trigger Handler Pattern — Best Practice

// 1 Trigger on Account — all events, zero logic
trigger AccountTrigger on Account (
    before insert, after insert,
    before update, after update,
    before delete, after delete, after undelete
) {
    AccountTriggerHandler handler = new AccountTriggerHandler();
    if (Trigger.isBefore && Trigger.isInsert)  handler.beforeInsert(Trigger.new);
    if (Trigger.isAfter  && Trigger.isInsert)  handler.afterInsert(Trigger.new, Trigger.newMap);
    if (Trigger.isBefore && Trigger.isUpdate)  handler.beforeUpdate(Trigger.new, Trigger.oldMap);
    if (Trigger.isAfter  && Trigger.isUpdate)  handler.afterUpdate(Trigger.new, Trigger.oldMap);
}

// All logic lives in AccountTriggerHandler class
public class AccountTriggerHandler {
    public void beforeInsert(List<Account> newAccounts) { /* logic here */ }
    public void afterInsert(List<Account> newAccounts, Map<Id,Account> newMap) { /* logic here */ }
}

🔑 Key Points for Interviewer

🔥This is a very commonly asked question — answer = technically unlimited, but 1 is the standard
💡Always follow the Trigger Handler Framework pattern — single entry point, all logic in handler class
💡Frameworks like Kevin O'Hara's Trigger Framework enforce this at org level

🎤 One-Line Answer for Interview

"Salesforce allows multiple triggers per object but doesn't guarantee execution order between them — so best practice is one trigger per object with all logic delegated to a handler class for predictable, maintainable execution."

Question 13 · 🔴 Advanced

Why only 1 Trigger per object? Why did Salesforce design it this way?

✅ Answer

Salesforce didn't enforce 1 trigger — the community established this as best practice because of non-deterministic execution order between multiple triggers. ⚠️

📋 Why Multiple Triggers Are Problematic

Problem	Real Impact
Trigger A sets a field value	Trigger B may overwrite it unpredictably
Trigger B depends on Trigger A's output	May fail silently or give wrong result
Deployed at different times	Order can change after any metadata deploy
Debugging	Near impossible to trace which trigger caused the bug

📌 Salesforce's Design Philosophy

Salesforce designed triggers as event-driven handlers
— not as business logic containers.

The platform assumed developers would self-govern
the number of triggers per object.

Community response → 1 trigger per object standard:
Trigger → Handler Class → Individual Methods
            ↓
Full control of execution order ✅
Clean unit testing (single entry point) ✅
Easy to enable/disable via Custom Metadata ✅

✅❌ What This Actually Controls

✅Single trigger gives you explicit control over order of operations
✅Makes unit testing cleaner — one entry point for all test scenarios
❌Multiple triggers = race condition equivalent in Apex
✅Some orgs use Custom Metadata to enable/disable trigger logic without deployment

🔑 Key Points for Interviewer

🔥This is a design maturity question — shows you understand the "why" not just "what"
💡Mention Kevin O'Hara's Trigger Framework for extra depth
💡Custom Metadata toggle pattern = zero-deployment way to enable/disable trigger logic

🎤 One-Line Answer for Interview

"Salesforce allows multiple triggers but doesn't guarantee their execution order — so the community standardized on one trigger per object to ensure deterministic, maintainable logic flow. It's a best practice enforced by developers, not the platform."

Question 14 · 🟠 Intermediate

In how many ways can you make a field Required in Salesforce?

✅ Answer

4 ways to make a field required — each enforced at a different layer, with different strength and bypass-ability. ✅

📋 All 4 Methods Compared

Method	Where Enforced	Can Be Bypassed?	Conditional?
Field Definition (checkbox in field setup)	UI + API + Apex	❌ No — database-level	❌ No
Page Layout (drag to required section)	UI only	✅ Yes — API/Apex skip it	❌ No
Validation Rule	UI + API + Apex	❌ Hard to bypass	✅ Yes
Apex Code (programmatic check)	Only when Apex runs	✅ Depends on code path	✅ Yes

✅❌ What Each Actually Controls

✅Field-level required = most powerful — enforced at database level, no bypass
✅Page Layout required = UI only — integrations and API completely bypass it
✅Validation Rule = most flexible — can add conditions ("required only if Status = Active")
✅Apex = context-dependent — must be in the execution path to have any effect

🌍 Real World Example (XYZ Company)

Your KYC validation uses Validation Rules — not field-level required — because KYC should be mandatory only when the opportunity reaches a certain stage, not always.

🔑 Key Points for Interviewer

🔥Most interviewers want to hear all 4 with the distinction between them
💡Field-level required is permanent and affects all interfaces including API
💡Validation Rules are the most flexible required enforcement mechanism

🎤 One-Line Answer for Interview

"A field can be made required in 4 ways: via field definition (database-level, strongest), page layout (UI-only, weakest), validation rule (conditional and flexible), or Apex code (context-dependent) — and interviewers expect you to know the difference in where each is enforced."

Question 15 · 🟠 Intermediate

What is the difference between Managed and Unmanaged Packages in Salesforce?

✅ Answer

Managed packages protect IP and support upgrades. Unmanaged packages are open-source deployments with full code visibility and no upgrade path. 📦

📋 Full Comparison

Feature	Managed Package	Unmanaged Package
Code Visibility	❌ Hidden (protected)	✅ Fully visible
Upgradeable	✅ Yes	❌ No
Namespace Required	✅ Yes	❌ Optional
IP Protection	✅ Yes	❌ No
Modifiable after install	❌ Locked	✅ Full control
Best For	ISV Products, AppExchange	Internal templates, one-time deploys
Post-install scripts	✅ Supported	❌ Not supported
License Management	✅ Yes (via LMA)	❌ No

✅❌ What Each Actually Controls

✅Managed → What ISVs (AppExchange vendors) use for commercial products
✅Unmanaged → What you'd use for sharing a project template internally
❌Managed code cannot be modified by the installing org
✅Unmanaged code becomes the installing org's own code after install

🌍 Real World Example (XYZ Company)

DLRS (Declarative Lookup Rollup Summary) from AppExchange is a Managed Package — you can't see its Apex code, but you get version upgrades whenever the vendor ships improvements.

🔑 Key Points for Interviewer

🔥Managed packages require a Developer Edition org with namespace to create
💡Managed packages can have subscriber-specific license types via LMA
💡Unmanaged = like a ZIP deploy — no ongoing relationship with the publisher

🎤 One-Line Answer for Interview

"Managed packages protect source code and support version upgrades — ideal for AppExchange products. Unmanaged packages expose all code and are best for internal reusable templates with no upgrade path needed."

Question 16 · 🟠 Intermediate

Tell me 1 advantage of using a Managed Package.

✅ Answer

The biggest advantage is IP Protection combined with Upgradability — your code is hidden from subscribers and they can always receive the latest version automatically. 🔒

📌 Why This Is The #1 Advantage

Publisher releases Managed Package v1.0
              ↓
Subscriber installs it — code is HIDDEN 🔒
              ↓
Publisher fixes bugs → releases v1.1
              ↓
Subscriber upgrades with ONE CLICK
OR Publisher PUSHES upgrade automatically ✅

Competitor installs it → STILL can't steal the code 🔒

📋 What This Enables

Capability	Unmanaged Package	Managed Package
Sell on AppExchange	❌	✅
Push upgrades to all subscribers	❌	✅
Hide proprietary logic	❌	✅
License Management App (LMA)	❌	✅
Beta version before GA	❌	✅

🌍 Real World Example

If XYZ Company built a custom Salesforce app for pharma order management and wanted to sell it to 50 other pharma companies — a Managed Package means competitors can't steal the code, and all 50 customers stay on the latest version via push upgrades.

🔑 Key Points for Interviewer

🔥For ISVs this is non-negotiable — it's how AppExchange works
💡Managed packages enable the License Management App (LMA) for tracking subscribers
💡You can have beta versions before going GA — useful for staged rollouts

🎤 One-Line Answer for Interview

"The biggest advantage of a Managed Package is IP protection combined with upgrade support — your code stays hidden from subscribers and you can push updates to all of them simultaneously without them redeploying anything."