Top 61 Salesforce Interview Questions with Answers

A Profile in Salesforce controls what a user can see and do inside the system. It defines permissions, like which objects, fields, or tabs a user can access. You can think of it like a security badge that decides which rooms a person can enter in a building.

For example, a Sales User Profile might allow access to Leads, Opportunities, and Contacts, while a Support User Profile allows access to Cases and Knowledge Articles. Each user must have one profile, and it helps ensure the right people see the right data.

A Role in Salesforce defines how much data a user can see within the organization. It works in a hierarchical structure, meaning users higher in the role hierarchy can view and manage records owned by users below them.

For example, a Sales Manager role can see the opportunities owned by their Sales Representatives, but not vice versa. Roles help control record-level access and make sure data visibility follows the company’s reporting structure.

their main profile. It allows admins to extend permissions for specific tasks, such as editing certain records or accessing special apps.

For example, if a user’s profile doesn’t allow them to export reports, but they need that feature, you can assign a “Report Export Access” Permission Set to them. This way, you can add permissions easily without creating a new profile.

A Public Group in Salesforce is a collection of users, roles, and other groups that helps manage data sharing and permissions more easily. Instead of assigning access to each user one by one, you can assign it to the group as a whole.

For example, you can create a Public Group called “Marketing Team” that includes all marketing users. Then you can share reports, dashboards, or records with this group — saving time and keeping access organized.

A Queue in Salesforce is like a waiting area where unassigned records stay until someone takes ownership of them. It helps teams share and manage work efficiently, especially when dealing with leads, cases, or custom objects.

For example, when new Customer Support Cases come in, they can be placed in a “Support Queue.” Any support agent can then pick a case from the queue and start working on it. This ensures no record is forgotten and work is distributed fairly among team members.

To create a many-to-many relationship in Salesforce, you need to use a Junction Object. A junction object connects two other objects using two master-detail relationships. This setup allows multiple records from one object to relate to multiple records from another.

For example, imagine you have Students and Courses. One student can join many courses, and one course can have many students. To link them, you create a junction object called “Enrollment.” It will have two master-detail fields — one linked to Student and another linked to Course — forming a many-to-many relationship.

In Salesforce, custom fields let you store additional information that standard fields don’t cover. When you create a custom field, you can choose from several field types depending on the kind of data you want to capture.

Some common custom field types are:

• Text – To store names or short descriptions (e.g., “Project Name”).

• Number – For numeric values (e.g., “Discount Percentage”).

• Checkbox – For true/false options (e.g., “Active Customer”).

• Date or Date/Time – To capture specific dates (e.g., “Contract Start Date”).

• Picklist – For dropdown options (e.g., “Status: New, In Progress, Closed”).

• Currency – To store money values (e.g., “Total Revenue”).

• Lookup Relationship – To link related records between objects.

These field types help you tailor Salesforce to fit your business data needs.

Yes ✅, a user can add their own custom logo while creating a custom application in Salesforce. When setting up a new app in the App Manager, Salesforce allows you to upload a logo or choose one from the Documents folder.

For example, if you’re building a custom app called “Student Management System,” you can upload your organization’s logo to display it in the top-left corner of the app. This feature helps brand your application and make it look more professional and personalized.

A Page Layout in Salesforce controls how information appears on a record’s detail page. Admins can customize it to make data entry and viewing easier for users.

Here are some things you can customize on Page Layouts:

• Fields – Add, remove, or reorder fields to match your business process.

• Sections – Group related fields together for better organization.

• Buttons and Links – Add custom buttons, links, or actions.

• Related Lists – Choose which related records (like Contacts or Opportunities) appear on the page.

• Visualforce Pages or Lightning Components – Embed custom components or apps.

• Read-Only and Required Fields – Control how users interact with fields.

This customization helps ensure that each user sees only the most relevant information for their role.

A Self Relationship in Salesforce is a type of relationship where an object is related to itself. It allows records within the same object to be linked together, creating a parent-child hierarchy using a Lookup Relationship.

For example, in the Employee object, you can create a field called “Manager” that looks up to another Employee record. This means each employee can be linked to their manager within the same table.

Self relationships are very useful for creating hierarchical structures, such as employees reporting to managers, or accounts related to parent accounts.

A Master-Detail Relationship tightly links two objects, where one is the Master (parent) and the other is the Detail (child). The child record depends completely on the parent record — meaning if the parent is deleted, the child is also deleted.

Here are the main things to consider:

• The child record cannot exist without the parent record.

• Ownership and sharing settings of the child are controlled by the parent.

• You can create Roll-Up Summary fields on the master object to calculate totals from the detail records.

• Each detail record can have only one master, but one master can have many details.

• The relationship is required, so the parent field cannot be left blank.

This type of relationship is ideal when two objects are closely connected, like Invoice (Master) and Invoice Line Item (Detail).

Both Triggers and Workflows are used to automate processes in Salesforce, but they work in very different ways.

A Workflow is a declarative automation tool — meaning it works with clicks, not code. It can perform simple actions like updating fields, sending emails, creating tasks, or sending outbound messages when specific conditions are met. However, it cannot handle complex logic or multiple related records.

A Trigger, on the other hand, is written in Apex code and runs before or after records are saved in the database. Triggers can handle complex logic, update multiple objects, and perform cross-object operations that Workflows can’t.

Example:

• Workflow → Automatically send an email when an Opportunity is closed.

• Trigger → When an Opportunity closes, also update related Account and custom records.

A Wrapper Class in Salesforce is a custom Apex class that allows you to combine multiple data types or objects into a single structure. It’s especially useful when you need to display complex data in a Visualforce page or Lightning component.

You can think of it like a container that holds related pieces of information together — even if they come from different objects.

Example:
Suppose you want to display Accounts along with their related Contacts on a Visualforce page. Instead of querying them separately, you can create a Wrapper Class that includes both Account and Contact fields in one structure.

Both SOQL (Salesforce Object Query Language) and SOSL (Salesforce Object Search Language) are used to fetch data from Salesforce, but they serve different purposes.

• SOQL is used to query data from a specific object (like a SQL SELECT statement). You can use it when you know exactly which object and fields you want.
  👉 Example:

  SELECT Name, Industry FROM Account WHERE Industry = 'Banking';

  This query returns all Accounts in the Banking industry.

• SOSL is used to search text across multiple objects at once, even if you don’t know where the data exists. It’s useful for global searches.
  👉 Example:

  FIND 'John' IN ALL FIELDS RETURNING Contact(Name), Account(Name);

  This finds all records containing “John” in both Contacts and Accounts.

In short, SOQL = structured query on one object, while SOSL = keyword search across many objects.

Both insert() and Database.insert() are used to add new records into Salesforce using Apex, but they handle errors differently.

• insert() → This is a DML statement that stops execution immediately if an error occurs. For example, if one record in a list fails to insert, none of the records are saved, and Salesforce throws a System.DmlException.
  👉 Example:

  insert accountList; // Fails completely if one record is invalid

• Database.insert() → This is a DML method that gives you more control. You can use the allOrNone parameter to decide whether Salesforce should insert valid records even if some fail.
  👉 Example:

  Database.insert(accountList, false); // Inserts valid records, skips errors

In short:

• Use insert() when you want all records to succeed or fail together.

• Use Database.insert() when you want to handle partial success and avoid losing good data due to one bad record.

A Static Resource in Salesforce is a way to store external files — such as images, CSS, JavaScript, or ZIP files — directly inside Salesforce so they can be used in Visualforce pages, Lightning components, or apps.

It helps developers manage and load web-related files efficiently without needing an external server. Static Resources are stored in Salesforce under Setup → Static Resources, and they can be referenced by name in your code.

Example:
If you upload a logo as a static resource named “CompanyLogo”, you can display it on a Visualforce page like this:

This keeps your assets centralized, version-controlled, and accessible across all environments.

To call a JavaScript file from a Static Resource in a Visualforce page, you first upload your .js file to Setup → Static Resources, then reference it using the special $Resource global variable.

Here’s a simple example 👇

1. Upload your JavaScript file, say “customScript.js”, as a Static Resource.

2. Then, include it in your Visualforce page like this:

And inside your customScript.js file:

✅ Explanation:

• $Resource.customScript points to the uploaded file in Salesforce.

• is used to include that script in your Visualforce page.
  This approach keeps your JavaScript reusable, secure, and easily manageable across different pages.

In Salesforce, there are five main ways to share a record. Each method gives users access based on business needs and security settings. Here’s a simple breakdown 👇

1. Role Hierarchy – Users higher in the hierarchy automatically get access to records owned by users below them.
   Example: A Sales Manager can see all records owned by their Sales Representatives.

2. Organization-Wide Defaults (OWD) – Defines the baseline access level (Private, Public Read Only, Public Read/Write) for each object.

3. Sharing Rules – Automatically share records with specific roles, public groups, or territories based on conditions.

4. Manual Sharing – Allows record owners or admins to share individual records manually with another user.

5. Apex Sharing (Programmatic Sharing) – Developers can write Apex code to share records dynamically using custom logic.

👉 In short, Salesforce gives both admins and developers flexible control over who can access what — ensuring security and collaboration go hand in hand.

A Workflow in Salesforce is an automation tool that performs specific actions automatically when certain conditions are met. Once a workflow rule is triggered, it can perform one or more workflow actions.

Here are the four main workflow actions:

1. Email Alert – Sends an automatic email to users, customers, or teams when a condition is met.
   Example: Send a “Welcome Email” when a new Lead is created.

2. Field Update – Automatically updates a field value on a record.
   Example: Change the Opportunity Stage to “Closed Won” when a deal is finalized.

3. Task Creation – Creates a task and assigns it to a user or team for follow-up actions.
   Example: Assign a “Call the client” task after a lead converts.

4. Outbound Message – Sends information to an external system using a web service (SOAP message).
   Example: Send customer data to an ERP system when an order is placed.

⚙️ Though Flow Builder has replaced Workflows for new automation, understanding Workflow Actions is still important for legacy Salesforce projects.

In Salesforce, you can make a field required in four main ways, depending on how and where you want the rule to apply. Each method has its own purpose and level of control 👇

1. Field-Level Requirement (during creation) –
   When creating or editing a custom field, you can check the “Required” box.
   Effect: The field must always have a value — no matter how the record is created (UI, import, API).

2. Page Layout –
   On the page layout editor, you can mark a field as Required.
   Effect: The field is required only when a user edits or creates a record through the Salesforce interface (not via API or import).

3. Validation Rule –
   You can create a Validation Rule that forces a field to have a value under certain conditions.
   Example:

   ISBLANK(Phone) && ISPICKVAL(Status, "Active")

   Effect: Makes “Phone” required only when the Status is “Active.”

4. Lightning App Builder (Dynamic Forms) –
   You can make a field required dynamically based on record data or user profile.
   Effect: Gives flexibility to show or require fields only when needed.

✅ In short:

• Use Field-Level Required for strict enforcement.

• Use Page Layout or Dynamic Forms for UI-based control.

• Use Validation Rules for conditional requirements.

A Profile and a Role both control access in Salesforce, but they serve different purposes — one controls what a user can do, and the other controls what data they can see.

Here’s an easy way to understand 👇

✅ In short:

• Profile = Permissions (what you can do)

• Role = Data visibility (what you can see)

When you use the renderAs="pdf" attribute in a Visualforce page to generate a PDF file, Salesforce limits the maximum size of that PDF to 15 MB.

However, if you try to generate the PDF as part of an email attachment, the limit is even smaller — around 3 MB.

Example:

✅ Quick Facts:

• 15 MB → Maximum size for a Visualforce-generated PDF.

• 3 MB → Maximum size if used as an email attachment.

• It’s best to compress images or simplify the content in your Visualforce page to stay within these limits.

In a Visualforce page, you can use only one main controller, but you can also include multiple extension controllers to add extra functionality.

Here’s how it works 👇

• One Standard or Custom Controller – This is the main controller that handles the page’s core logic.

• Up to 10 Extension Controllers – These can be added to extend or customize the main controller’s behavior.

Example:

✅ In short:

• You can use 1 main controller (standard or custom).

• You can add up to 10 extension controllers, giving a total of 11 controllers maximum per Visualforce page.

Both ActionSupport and ActionFunction are Visualforce components used to make pages more interactive, but they serve different purposes.

Here’s the simple difference 👇

Example of ActionSupport:

Example of ActionFunction:

✅ In short:

• ActionSupport = Automatically fires on user events.

• ActionFunction = Manually called from JavaScript for custom behavior.

In Salesforce, you can call or execute an Apex class in several ways depending on where and how you need it to run. Here are the most common methods:

1. From a Visualforce Page –
   You can call an Apex class using a controller or extension directly in Visualforce.

   <apex:page controller="MyApexClass"> <apex:commandButton value="Save" action="{!saveRecord}" /> apex:page>

2. From a Lightning Component (LWC or Aura) –
   You can use the @AuraEnabled annotation to make Apex methods callable from client-side JavaScript.

   @AuraEnabled public static List getAccounts() { return [SELECT Name FROM Account LIMIT 10]; }

3. From a Trigger –
   Apex classes can be called from triggers to handle logic cleanly.

   MyApexClass.processAccounts(Trigger.new);

4. From the Developer Console or Anonymous Apex –
   You can test or execute Apex directly using:

   MyApexClass.doSomething();

5. From a Batch Class (Asynchronous Execution) –
   Use Apex classes to perform long-running operations in the background.

   Database.executeBatch(new MyBatchClass());

6. From a Scheduled Job –
   You can schedule Apex classes to run at specific times.

   System.schedule('Nightly Job', '0 0 23 * * ?', new MyScheduler());

✅ In short: You can call an Apex class in six main ways — Visualforce, LWC/Aura, Trigger, Anonymous Apex, Batch Apex, and Scheduled Apex — depending on your use case.

Creating a Master-Detail Relationship between existing records requires a few careful steps because Salesforce enforces strict data dependency rules between parent and child records. You can’t directly create it if the object already has existing data that doesn’t meet relationship requirements.

Here’s the step-by-step process:

1. Convert the existing Lookup Relationship to Master-Detail

   • First, create a Lookup Relationship between the two objects.

   • Make sure all child records already have a parent record assigned (the lookup field must not be blank).

2. Check for missing parent values

   • Run a report or SOQL query to find any child records without a parent record.

   • Example:

     SELECT Id, Name FROM ChildObject__c WHERE Parent__c = NULL

   • Assign parent records where missing.

3. Convert the Relationship Type

   • Go to Setup → Object Manager → Child Object → Fields & Relationships.

   • Edit the lookup field you created earlier.

   • Click Change Field Type → Master-Detail Relationship, and follow the conversion wizard.

4. Save your changes

   • Once converted, the relationship behaves like a Master-Detail, meaning if the master is deleted, all related child records will also be deleted.

A Permission Set in Salesforce is a tool that gives additional access to users without changing their profile. It’s like giving someone an extra key to unlock new features or data they couldn’t access before.

For example, if a user’s profile doesn’t allow them to edit Opportunities, you can assign a “Opportunity Edit Access” permission set to that user — instead of creating a whole new profile.

Key points about Permission Sets:

• They extend user permissions beyond what’s defined in the profile.

• A user can have multiple permission sets at once.

• They can control access to objects, fields, tabs, apps, and system permissions.

• They are great for giving temporary or role-based access.

✅ In short:
A Profile defines the base level of access, while a Permission Set adds extra permissions on top — helping admins manage access more flexibly and efficiently.

Manual Sharing in Salesforce allows users to share individual records with specific people or groups when needed — even if those users wouldn’t normally have access through roles, profiles, or sharing rules. It’s a flexible, record-level sharing method used to handle special cases.

For example, suppose a Sales Representative owns an Opportunity but wants their Manager or a colleague to view or edit it. They can manually share that specific record with those users.

Key points about Manual Sharing:

• It’s available only when the Organization-Wide Default (OWD) setting for the object is Private or Public Read Only.

• You can share records with individual users, roles, or public groups.

• Manual sharing is done by clicking the “Sharing” button on a record (if enabled).

• It provides Read Only or Read/Write access.

✅ In short:
Manual Sharing lets you manually open access to specific records — giving flexibility for collaboration while keeping overall data security intact.

In Salesforce, the “Grant Access Using Hierarchies” setting controls whether users higher in the role hierarchy automatically get access to records owned by users below them.

For standard objects, this setting is enabled by default and cannot be changed. Salesforce enforces this to ensure proper visibility for key business objects like Accounts, Contacts, Opportunities, and Cases.

However, for custom objects, you can modify this setting:

• Go to Setup → Object Manager → [Custom Object] → Edit.

• Uncheck “Grant Access Using Hierarchies” if you don’t want higher roles to automatically see lower users’ records.

✅ In summary:
You cannot disable it for standard objects, but you can control it for custom objects.

The “Transfer Record” permission in a profile allows users to transfer ownership of records they do not own, provided they have access to the record.

For example, a Sales Manager can transfer an Opportunity or Account record from one Sales Representative to another using this permission.

Key points:

• It can apply to specific objects like Leads, Cases, and Custom Objects.

• The user must have read access to the record before transferring it.

• This helps manage workload distribution and ownership changes within teams.

✅ In short: The “Transfer Record” permission enables users to reassign ownership of records to maintain proper record management.

A Field Dependency in Salesforce defines a relationship between two picklist fields, where the value in one field (the controlling field) determines which values are available in another (the dependent field).

For example, if you have a “Country” field controlling a “State” field:

• Selecting “USA” shows only states like “California” or “Texas.”

• Selecting “India” shows “Telangana” or “Karnataka.”

Steps to create a Field Dependency:

1. Go to Setup → Object Manager → [Object] → Fields & Relationships.

2. Click Field Dependencies → New.

3. Choose the controlling and dependent fields, then map the values.

✅ In short:
Field dependency ensures data accuracy and user convenience by showing only relevant options based on previous selections.

A Roll-Up Summary field in Salesforce is used to calculate values (like count, sum, min, or max) from related records in a Master-Detail relationship. It automatically summarizes data from the detail (child) records into the master (parent) record.

Example:
If you have an Account with multiple Opportunities, you can create a Roll-Up Summary field on the Account to show the total value of all Opportunities or the number of Opportunities linked to that Account.

Supported Calculations:

• COUNT – Number of related records.

• SUM – Total of a numeric field.

• MIN/MAX – Smallest or largest value from related records.

✅ In short: A Roll-Up Summary helps aggregate data from child records automatically into the parent record for better insights.

By default, Salesforce allows Roll-Up Summary fields only on Master-Detail relationships, not on Lookup relationships.

However, you can achieve this functionality in three ways:

1. Convert Lookup to Master-Detail (if possible) – Only if business rules allow.

2. Use Apex Triggers – Write custom Apex code to calculate and update parent fields based on related child data.

3. Use Declarative Tools like Flow or the Rollup Helper App (AppExchange) – These tools let you simulate roll-up summaries on lookup relationships without coding.

✅ Example: Use a Flow to calculate the total number of child records linked to a parent record and store it in a custom field.

Record Types in Salesforce allow you to create different business processes, page layouts, and picklist values for the same object — all in one place.

They help tailor Salesforce to fit different teams or use cases within the same organization.

Example:
On the Opportunity object, you can have:

• A “New Sales” record type for sales reps.

• A “Renewal” record type for account managers.

Each can have different page layouts and picklist options (like sales stages).

✅ In short: Record Types customize the user experience and process flow based on different business scenarios.

The Setup Audit Trail in Salesforce helps track changes made to the organization’s setup or configuration. It shows who made the change, what was changed, and when it was changed.

Key points:

• Tracks up to 6 months of configuration changes (last 20 entries per user).

• Accessible via Setup → View Setup Audit Trail.

• Shows actions like changes to fields, layouts, workflows, profiles, and more.

✅ In short: Audit Trail provides visibility into system changes for better security, accountability, and compliance.

A Report Type in Salesforce defines the structure and relationships between objects that determine what data can be included in a report.

There are two main types of report types:

1. Standard Report Types – Automatically created by Salesforce for all standard and custom objects.
   Example: “Accounts with Opportunities.”

2. Custom Report Types – Created manually by admins to define specific relationships and fields.
   Example: A report showing “Contacts with Cases and Related Opportunities.”

Key benefits:

• Helps combine related data from multiple objects.

• Determines which fields and records are available for reporting.

✅ In short: Report Types define what data you can report on and how objects are linked — making reports more flexible and meaningful.

A Dashboard in Salesforce is a visual representation of reports and business metrics. It allows users to see key performance indicators (KPIs), charts, and summaries all in one place. Each component in a dashboard is based on a report and helps you monitor real-time business performance.

Example:
A Sales Dashboard might include charts for “Total Revenue by Region,” “Top Opportunities,” and “Closed Deals This Quarter.”

Key features:

• Supports different chart types: bar, pie, funnel, and gauge.

• Can display up to 20 components per dashboard.

• Dashboards can be scheduled for email delivery or filtered for different users.

✅ In short: A dashboard gives a quick, visual summary of data trends and performance across your organization.

In Salesforce, the Contact and Account objects have a standard Lookup relationship, which behaves like a one-to-many relationship.

• One Account (company) can have many Contacts (people).

• Each Contact is usually linked to one Account.

Example:
If “BNY Mellon” is an Account, its Contacts could be “John Doe” (Manager) and “Mary Smith” (Analyst).

Special case:
Salesforce also supports Person Accounts, which combine both Account and Contact information into a single record for B2C (business-to-customer) use.

✅ In short: Account represents the organization, and Contact represents the people linked to that organization.

Organization-Wide Defaults (OWD) define the baseline level of access users have to records they don’t own. It’s the foundation of Salesforce’s record-sharing model.

Here are the main OWD settings:

1. Private – Only the record owner and users above them in the role hierarchy can view and edit the record.
   Example: Sales reps can see only their own Opportunities.

2. Public Read Only – Everyone can view records, but only the owner can edit them.
   Example: All users can see Accounts, but only the Account owner can modify them.

3. Public Read/Write – All users can view and edit all records.
   Example: Common for shared data like “Company Announcements.”

4. Controlled by Parent – Access is inherited from the parent object.
   Example: A Contact’s access depends on its related Account’s access.

✅ In short: OWDs ensure a balance between data security and collaboration by controlling record visibility.

Yes ✅, Salesforce allows you to create a new profile from scratch without cloning an existing one — but it’s not recommended.

When creating a profile from scratch, you must manually configure all settings, including object permissions, field-level security, tab visibility, and system permissions, which can be time-consuming.

The preferred approach is to clone an existing profile, as it provides a template you can modify easily instead of starting from zero.

✅ In short: You can create a new profile manually, but cloning saves time and ensures consistency.

The “Grant Access Using Hierarchies” setting ensures that users higher in the role hierarchy automatically get access to records owned by users below them.

Example:
If a Sales Manager is above a Sales Representative in the hierarchy, enabling this option allows the manager to see all records owned by their reps — like Leads or Opportunities.

Key points:

• This setting is always enabled for standard objects (like Account, Opportunity).

• For custom objects, admins can choose to enable or disable it based on security needs.

✅ In short: It ensures visibility flows upward in your org’s structure, supporting better supervision and collaboration.

In Salesforce Data Loader, both options help you export data from objects, but they differ in which records they include:

• Export → Extracts only active records from Salesforce (records that are not in the Recycle Bin).

• Export All → Extracts both active and deleted records (including those in the Recycle Bin).

Example:
If you want a backup of all Account data, including deleted ones, use Export All. If you only need current data, use Export.

✅ In short:

• Export = Active records only

• Export All = Active + Deleted records

An App in Salesforce is a collection of tabs, objects, and functions that work together to serve a specific business purpose. You can think of it like a workspace where users can manage related data and processes in one place.

Salesforce provides two types of apps:

1. Standard Apps – Prebuilt by Salesforce (like Sales, Service, and Marketing).

2. Custom Apps – Created by admins or developers to meet unique business needs.

Example:
A company can create a “Recruitment App” that includes tabs for Jobs, Candidates, Interviews, and Reports — all under one app for HR users.

✅ In short: An App in Salesforce is a bundle of related tabs and objects designed to simplify navigation and organize business processes efficiently.

An Object in Salesforce is like a database table that stores specific types of information. Each row is a record, and each column is a field.

Salesforce has two main types of objects:

1. Standard Objects – Built-in objects like Account, Contact, Opportunity, and Lead.

2. Custom Objects – Created by users to store additional business data (e.g., “Student” or “Invoice”).

Example:
The Account object stores company details, while the Contact object stores information about people related to those companies.

✅ In short: Objects are the foundation of Salesforce data, storing all business information in a structured way.

A Junction Object in Salesforce is a custom object used to create a many-to-many relationship between two other objects. It connects them using two Master-Detail relationships.

Example:
If you have Students and Courses:

• One Student can take many Courses.

• One Course can have many Students.

You can create a junction object called “Enrollment” that links Students and Courses. Each Enrollment record connects one Student to one Course.

✅ In short: A Junction Object acts as a bridge between two objects to manage many-to-many relationships in Salesforce.

A Master-Detail Relationship in Salesforce defines a tight bond between two objects — a parent (master) and a child (detail). The child record depends completely on the parent record.

Key features:

• If the parent is deleted, all related child records are also deleted.

• The child inherits the parent’s sharing and security settings.

• You can create Roll-Up Summary fields on the master to summarize child data.

Example:
In a Project (Master) and Task (Detail) setup:

• If a Project is deleted, all related Tasks are deleted too.

• You can calculate the total number of Tasks on the Project using a Roll-Up Summary.

✅ In short: A Master-Detail relationship connects two objects so that the child record’s life and visibility depend entirely on its parent.