1. What is the difference between Trigger and Workflow?

Short answer (interview):

Workflow (declarative) does simple, pre-built actions (email, task, field update, outbound
message). Triggers (Apex) are code-based and handle complex logic, cross-object
operations, callouts, and advanced bulk processing. Triggers run before/after DML;
workflows run after the save and can cause additional trigger cycles if they update fields.

Health Cloud example:

Workflow: When a CareGap__c is created for a patient and severity = “High”, send an email
alert to the Care Manager.

Trigger: When CarePlan__c is moved to Completed, programmatically create closure tasks

across multiple related objects (CarePlanGoals, Appointments) and call an external billing
API to finalize billing.

Test steps / Test lead checks:

1. Confirm workflow fires on intended criteria and email templates merge correctly.

2. For triggers, run bulk tests (200 records) to ensure bulkification and no governor limit
exceptions.

3. Check execution order: a workflow field update may re-trigger before/after triggers. Use
debug logs to verify sequence.

---

2. What does a custom object permit the user to do?

Short answer:
Create a business-specific entity (with fields, relationships, layouts, security, automation) that
behaves like a native Salesforce object.

Health Cloud example:

Create PatientEncounter__c to record visit notes, vitals, provider seen, and link to
Patient__c and CarePlan__c.

Test steps / Test lead checks:

Validate CRUD permissions via profiles/permission sets.

Ensure page layouts & record types display the correct fields for nurses vs admin.

Confirm triggers/workflows operate on the object and integrations (ETL) map correctly.
---

3. What is a Self-Relationship?

Short answer:
A lookup field on an object that points to another record of the same object (e.g., parent/child
on same object).

Health Cloud example:

Provider__c has Supervisor__c (lookup to Provider__c). Allows modeling of provider
supervision chains.

Test steps / Test lead checks:

Create Provider A and Provider B; set [Link] = B; test cascading changes (if any).

Confirm UI displays hierarchy, and role-based sharing behaves properly (supervisor sees
subordinate patients).

---

4. What is Object Relationship Overview?

Short answer:
An explanation of how objects are linked — types include lookup, master-detail,
many-to-many (junction), self, external.

Health Cloud example:

Patient__c → (lookup) Account (if treating households), CarePlan__c → (master-detail)
CarePlanGoal__c.

Test steps / Test lead checks:

Verify referential integrity (parent exists).

Test cascade deletes for master-detail, and orphan behavior for lookups.

Validate roll-up summary fields (parent) reflect child changes.

Object Relationship Overview​
It explains how Salesforce objects are connected and the type of relationship used.
Common types:
●​ Lookup: Links two objects loosely (child can exist without parent).
●​ Master-Detail: Strong link (child depends on parent; cascade delete; roll-up
summaries).
●​ Many-to-Many: Achieved via a junction object with two master-detail relationships.
●​ Self-Relationship: Object relates to itself (e.g., hierarchical).
●​ External Lookup: Links to external objects.
1. Master-Detail Relationship
●​ Definition: A strong parent-child relationship where the child record cannot exist
without the parent.
●​ Key Features:
 ○​ Child inherits parent’s sharing and security settings.
○​ Cascade Delete: If you delete the parent, all child records are deleted
automatically.
○​ Roll-Up Summary: Available on the parent to summarize child data (COUNT,
SUM, MIN, MAX).
●​ Example in Health Cloud:
○​ CarePlan__c (Parent) → CarePlanGoal__c (Child)
■​ If you delete a CarePlan, all its CarePlanGoals are deleted.
■​ Roll-up summary on CarePlan: Total Goals Count.
●​ Delete Behavior:
○​ Parent deleted → Child deleted.
○​ Child cannot exist without parent.

✅ 2. Lookup Relationship
●​ Definition: A loose relationship where the child can exist without the parent.
●​ Key Features:
○​ No cascade delete by default (optional setting: “Delete this record also”).
○​ No roll-up summary fields.
●​ Example in Health Cloud:
○​ PatientEncounter__c → Lookup to Patient__c
■​ If you delete Patient, Encounter remains (orphaned).
●​ Delete Behavior:
○​ Parent deleted → Child remains (lookup becomes blank).

✅ 3. Many-to-Many Relationship
●​ Definition: Achieved using a junction object with two master-detail relationships.
●​ Key Features:
○​ Allows linking multiple records from two objects.
●​ Example in Health Cloud:
○​ CareTeamMember__c (Junction) links CareTeam__c and Provider__c.
■​ One CareTeam can have many Providers; one Provider can belong to
many CareTeams.
●​ Delete Behavior:
○​ Delete CareTeam → related CareTeamMember records deleted.
○​ Delete Provider → related CareTeamMember records deleted.

✅ 4. Self-Relationship
●​ Definition: An object relates to itself using a lookup.
●​ Example:
○​ Account → Parent Account (hierarchy).
○​ In Health Cloud: CarePlan__c could reference another CarePlan as a
“Parent Plan”.
●​ Delete Behavior:
○​ If parent is deleted, child remains (lookup cleared).

✅ Roll-Up Summary Fields

●​ Definition: A field on the parent object that aggregates child records in a
master-detail relationship.
●​ Types:
○​ COUNT: Number of child records.
○​ SUM: Total of a numeric field on child.
○​ MIN/MAX: Minimum or maximum value from child.
●​ Example:
 ○​ On CarePlan__c: Roll-up summary for Total Goals from
CarePlanGoal__c.

🔍 Quick Comparison Table

Relationship Child Exists Without Parent? Cascade Roll-Up Summary
Delete

Master-Detail ❌ No ✅ Yes ✅ Yes

Lookup ✅ Yes ❌ No ❌ No
Many-to-Many ❌ (via junction) ✅ Yes ✅ Yes
Self-Relationship ✅ Yes ❌ No ❌ No
What is Cascade Delete?
●​ Definition: In a Master-Detail relationship, when you delete the parent record,
Salesforce automatically deletes all its child records.
●​ Why? Because the child cannot exist without the parent.
●​ Example:
○​ CarePlan__c (Parent) → CarePlanGoal__c (Child)
○​ If you delete CarePlan, all related CarePlanGoals are deleted automatically.

✅ Does Roll-Up Summary Also Delete?

●​ No, roll-up summary fields themselves are not deleted.
●​ What happens?
○​ Roll-up summary fields recalculate when child records are deleted.
○​ Example:
■​ CarePlan has a roll-up summary Total Goals = 5.
■​ Delete 2 CarePlanGoals → Roll-up summary updates to 3.
●​ Roll-Up Summary is only available on Master-Detail parent objects.

✅ Behavior for Lookup Relationship

●​ If you delete the parent in a Lookup relationship:
○​ Child record remains (becomes orphaned).
○​ Lookup field becomes blank (unless “Delete this record also” option is
enabled manually).
Cascade Delete
●​ All child records (e.g., CarePlanGoal__c) linked to that CarePlan are
automatically deleted.
●​ This is because in Master-Detail, the child cannot exist without the parent.

✅ Roll-Up Summary Behavior

●​ Roll-up summary fields exist on the parent object (CarePlan).
●​ When you delete the CarePlan:
○​ The parent record itself is deleted, so the roll-up summary field is gone with
it.
○​ There’s no recalculation because the parent no longer exists.
●​ Before deletion:
○​ Roll-up summary shows aggregated child data (e.g., Total Goals = 5).
●​ After deletion:
○​ CarePlan record (and its roll-up summary field) is removed from the
database.
✅ Key Points
●​ Roll-up summary does not survive parent deletion.
●​ It only recalculates when child records are added/removed while the parent exists.

---

5. How is SaaS beneficial to Salesforce?

Short answer:
No infrastructure management, automatic upgrades, global availability, pay-as-you-go
model, and rapid provisioning.

Health Cloud example:

A hospital can onboard new clinics quickly without installing servers—for example, enabling
Patient 360 across clinics with central updates from Salesforce releases.

Test steps / Test lead checks:

During releases, run a regression checklist (e.g., key Health Cloud pages, integrations).

Confirm integrations (EHR) after sandbox/previews.

---

6. What is [Link]?

Short answer:
Salesforce’s PaaS for building custom business apps on the Salesforce platform (metadata,
Apex, Visualforce, LWC).

Health Cloud example:

Build a customized Patient Intake application using custom objects + LWC on [Link].

Test steps / Test lead checks:

Validate deployed components, permissions, and packaging in sandbox before production.

---

7. What are the different types of reports available in Salesforce?

Short answer:
Tabular, Summary, Matrix, Joined.

Health Cloud example:

Tabular: List of upcoming appointments.

Summary: Cases grouped by priority and owner.

Matrix: Patient counts by region (columns) & care manager (rows).

Joined: Combine claims and appointments into one dashboard view.

1. Tabular Report
●​ Description: Simple list of records in rows and columns.
●​ Use Case: Export data or create mailing lists.
●​ Example: List of all Patients with their Encounter Dates.

✅ 2. Summary Report
●​ Description: Groups rows based on a field and provides subtotals.
●​ Use Case: Group by Provider or CarePlan.
●​ Example: Total Encounters per Provider.

✅ 3. Matrix Report
●​ Description: Groups data by rows and columns (like a pivot table).
●​ Use Case: Compare data across two dimensions.
●​ Example: Encounters grouped by Provider (rows) and Month (columns).

✅ 4. Joined Report
●​ Description: Combines multiple report blocks from different objects.
●​ Use Case: Show related data sets together.
●​ Example: Patient details + CarePlan + Encounter info in one report.

Test steps / Test lead checks:

Verify grouping and summary formulas are accurate.

Confirm filters work with large datasets and that report performance is acceptable.

---

8. Is it possible to schedule a dynamic dashboard in Salesforce?

Short answer:
No — dynamic dashboards (run as viewing user) cannot be scheduled to refresh. Only
dashboards running as a single user can be scheduled.

Health Cloud implication:

Care Manager dashboards personalized to each coordinator must be refreshed manually or
viewed live.

Test steps / Test lead checks:

Confirm scheduled refresh works for non-dynamic dashboards.

Validate that dynamic dashboard displays correct data for different users.
---

9. What is the junction object, and what purpose does it serve?

Short answer:
A custom object with two master-detail relationships used to implement many-to-many
relationships between two objects.

Health Cloud example:

ProviderProgram__c (junction) linking Provider__c and CareProgram__c: provider may
belong to multiple programs and a program contains many providers.

Test steps / Test lead checks:

Create junction records and verify both parent relationships are enforced.

Validate roll-up summaries on parents if needed and test delete behavior.

---

10. What is an Audit Trail?

Short answer:
Tracks configuration changes in Setup (who changed what). Useful for admin governance
and debugging.

Health Cloud example:

Identify who changed the Patient object sharing setting that caused access issues.
What is an Audit Trail in Salesforce?
●​ Definition: Audit Trail tracks configuration changes made in your Salesforce org. It
helps admins see who changed what and when.
●​ Purpose: Ensures compliance, security, and accountability.

✅ Where to Find It
●​ Navigate to:​
Setup → Quick Find → Audit Trail
●​ It shows the last 20 changes (or download full history for 6 months).

✅ Example Changes Logged

●​ Profile or Permission Set updates.
●​ Custom Object or Field changes.
●​ Workflow or Validation Rule modifications.

Test steps / Test lead checks:

Review Setup Audit Trail when permissions/config bugs occur.

Cross-check change timestamp with release or deployment logs.

---

11. Explain the Salesforce dashboard.

Short answer:
A visual aggregate of reports using components (charts, gauges, tables) to monitor KPIs.

Health Cloud example:

Dashboard showing Open Care Gaps by Team, Average Appointment Wait Time, and
High-risk patients count.

Test steps / Test lead checks:

Validate each dashboard component uses the correct base report and filters.

Test refresh behavior and user-level visibility (dynamic vs running user).

---

12. What is a Wrapper Class?

Short answer:
A custom Apex class that wraps multiple objects or primitives into one structure, often used
to present complex rows in Visualforce or LWC.

Health Cloud example:

PatientRowWrapper holds Patient__c, LatestVital__c, and Boolean isSelected for a batch
operation UI.

Test steps / Test lead checks:

Unit test wrapper behavior (instantiation, serialization) and integration with VF/LWC
component logic.

---

13. What is the sharing rule?

Short answer:
Declarative rule to open record access automatically (owner-based or criteria-based) to
users, groups, or roles. Sharing rules only expand access, never restrict it.
A Sharing Rule in Salesforce is a way to extend record access to users who don’t have
access through their role hierarchy or organization-wide defaults (OWD). It allows you to
share records based on criteria or ownership.

✅ Key Points
●​ Purpose: To open up access beyond OWD and role hierarchy.
●​ Types:
 1.​ Owner-Based: Share records owned by certain users/roles.
2.​ Criteria-Based: Share records that meet specific field criteria.
●​ Access Levels: Read Only or Read/Write.

Example:​
If OWD for Patient__c is Private, you can create a Sharing Rule to share all Patient
records where Region = East with the East Care Team.
What is Organization-Wide Defaults (OWD) in Salesforce?
OWD defines the baseline level of access to records for all users in your org. It sets the
default sharing setting for each object when no other sharing mechanism (Role Hierarchy,
Sharing Rules, Manual Sharing) applies.

✅ How It Works
●​ OWD determines how restrictive or open your data is.
●​ It applies at the object level and affects all records of that object.
●​ You can choose one of these settings for each object:
OWD Setting Meaning

Private Only record owner and users above in role hierarchy can
access.

Public Read Only Everyone can view records, but only owner can edit.

Public Read/Write Everyone can view and edit records.

Public For Leads and Cases (allows transfer).

Read/Write/Transfer

Controlled by Parent Child record inherits parent’s sharing settings (e.g., Contact
under Account).

✅ Example
●​ If Patient__c OWD = Private, only the owner and their managers can see the patient
record.
●​ To give access to others, you use Role Hierarchy, Sharing Rules, or Manual
Sharing.

✅ Impact
●​ OWD is the foundation of Salesforce security.
●​ More restrictive OWD → More sharing rules needed.
●​ Less restrictive OWD → Easier collaboration but less security.
Here’s the diagram showing the Salesforce Sharing Model flow:
1.​ Organization-Wide Defaults (OWD) – Sets the baseline access for all users.
2.​ Role Hierarchy – Grants access upward in the hierarchy.
3.​ Sharing Rules – Opens access beyond OWD and roles (criteria-based or
owner-based).
4.​ Manual Sharing – User-level sharing for specific records.
5.​ Apex Sharing – Programmatic sharing for custom logic.

Health Cloud example:

Share any Authorization__c record where Insurance_Type__c = 'Private' with the Billing
Team role.
Test steps / Test lead checks:

Create sample records meeting criteria and verify target users gain access.

Validate that sharing is propagated correctly across role hierarchy and that there are no
over-shares.

---

14. What do you mean by governor limits?

Short answer:
Platform-enforced limits to ensure equitable resource usage (SOQL/DML counts, CPU time,
heap, callouts).

Health Cloud example:

A poorly written trigger that queries inside a loop may exceed the 100 SOQL limit when
processing bulk patient imports.
What are Governor Limits in Salesforce?
Definition:​
Governor Limits are runtime limits enforced by Salesforce to ensure that no single
transaction monopolizes shared resources in the multi-tenant environment. They keep the
platform stable and fair for all customers.

✅ Why Do They Exist?

Salesforce is a multi-tenant architecture, meaning many customers share the same
infrastructure. Governor Limits prevent:
●​ Excessive CPU usage
●​ Memory overconsumption
●​ Database overload

✅ Types of Governor Limits

1.​ SOQL Query Limits​

○​ Max 50,000 records retrieved per transaction.

○​ Max 100 SOQL queries per transaction.
2.​ DML Limits​

○​ Max 150 DML statements per transaction.

○​ Max 10,000 records processed in DML operations.
3.​ Heap Size​

○​ Max 6 MB for synchronous transactions.

○​ Max 12 MB for asynchronous transactions.
4.​ CPU Time​

○​ Max 10,000 ms per transaction.

5.​ Callouts​

○​ Max 100 HTTP callouts per transaction.

✅ Example
If you write an Apex trigger that queries 200,000 records, it will fail because the SOQL limit
is 50,000 records per transaction.

Test steps / Test lead checks:

Execute bulk tests (200 records) and confirm no governor exceptions.

Review logs to ensure code uses Maps/Sets and minimized queries.

---

15. What are some things that you can do to prevent governor limits?

Definition:​
Governor limits are Salesforce-enforced restrictions to ensure fair resource usage.
Preventing them means writing efficient code and designing scalable solutions.

✅ Key Points:
●​ Bulkify Apex code (handle multiple records in one go).
●​ Use efficient SOQL queries (avoid SELECT * and nested loops).
●​ Minimize DML operations (combine updates in collections).
●​ Use Batch Apex or Queueable for large data volumes.
●​ Cache frequently used data instead of querying repeatedly.
●​ Avoid unnecessary triggers or recursion.

✅When
Health Cloud Example (CarePlan):​
updating multiple CarePlan__c records for a patient:
●​ Instead of updating each CarePlan individually in a loop, collect all CarePlans in a list
and perform one DML update.
●​ Query all related CarePlans in a single SOQL query and store them in a map for
quick access.

✅ Best Practices / Testing Steps:

●​ Test with bulk data (200+ CarePlans) to ensure triggers and flows handle large
volumes.
●​ Validate that no SOQL or DML statements are inside loops.
●​ Check debug logs for governor limit warnings during execution.

---

16. What happens to master-detail and lookup relationships when a record is deleted?

Short answer:

Master-Detail: child records are cascaded deleted with the master.

Lookup: child record typically remains; lookup field becomes null unless delete restricted.
Health Cloud example:
Deleting a CarePlan__c (master) deletes CarePlanGoal__c (detail). Deleting a Provider__c
(lookup) will not delete Appointments__c, but the provider reference may become blank or
be restricted.

Test steps / Test lead checks:

Delete parent records and verify child behavior.

Test with validation/trigger logic that handles orphaned children.

Definition:​
Explains the behavior of child records when the parent record is deleted in different
relationship types.

✅ Key Points:
●​ Master-Detail: Child records are automatically deleted (cascade delete).
●​ Lookup: Child records remain but the lookup field becomes blank (orphaned).
●​ Roll-up summary fields exist only on Master-Detail parent objects.

✅ Health Cloud Example:

●​ Master-Detail:​
CarePlan__c (parent) → CarePlanGoal__c (child).​
If CarePlan is deleted, all CarePlanGoals are deleted automatically.
●​ Lookup:​
Assessment__c → Lookup to Patient__c.​
If Patient is deleted, Assessment remains but the Patient lookup becomes blank.

---

17. What is an App in Salesforce?

Short answer:
A logical collection of tabs, objects, dashboards, and utilities presented as a workspace.

Health Cloud example:

“Hospital Operations” app contains Patients, Appointments, Care Plans, Authorization tabs
and the utility bar with “Quick Intake” flow.

Test steps / Test lead checks:

Confirm users have access to required apps via profiles.

Validate app navigation and visibility across devices.

---

18. What are the different types of apps you can use in Salesforce?
Short answer:
Standard apps (Sales, Service), Custom apps, Console apps (multi-tabbed UI for agents),
Lightning apps.

Health Cloud example:

Use a Console app for clinicians with quick access to patient history and session notes.

Test steps / Test lead checks:

Test the console layout, workspace tabs, and utility bar items for clinician workflows.

✅A Console
What is a Console App in Salesforce?
Definition:​
App in Salesforce is a specialized app designed for users who need to work on
multiple records at the same time. It provides a tab-based interface within a single screen,
allowing quick navigation and multitasking without opening multiple browser windows.

✅ Key Points:
●​ Ideal for service agents or care coordinators who handle multiple cases or patient
records.
●​ Supports split view and subtabs for related records.
●​ Improves productivity by reducing clicks and context switching.

✅ Health Cloud Example:

●​ A Care Coordinator Console App in Health Cloud:
○​ Main tabs: Patient__c, CarePlan__c, Assessment__c.
○​ Subtabs: When viewing a Patient, you can open CarePlan and Assessment in
subtabs without leaving the main screen.
○​ Enables quick updates during patient calls or care team meetings.

---

19. What is a profile in Salesforce? Can two different users have the same profile?

Definition:​
A Profile in Salesforce defines a user’s permissions, object access, and field-level
security. It controls what users can see, create, edit, and delete in the system.

✅ Key Points:
●​ Profiles determine CRUD access (Create, Read, Update, Delete) for objects.
●​ Control tab visibility, record types, and page layouts.
●​ Every user must have one profile, but multiple users can share the same profile.

✅ Health Cloud Example:

●​ Care Coordinator Profile:
○​ Access to Patient__c, CarePlan__c, Assessment__c objects.
○​ Can edit CarePlans and Assessments but only view Patient financial details.
●​ Multiple care coordinators in the organization can share this profile.

---
20. What do you understand about the Master-Detail relationship in Salesforce?

Short answer:
Tight coupling: child inherits parent sharing, parent deletion cascades, and parent can have
roll-up summaries aggregating child fields.

Health Cloud example:

CarePlan__c (master) → CarePlanGoal__c (detail) with a roll-up Total_Goals__c.

Test steps / Test lead checks:

Create child records and verify parent roll-up values update.

Test delete cascades and sharing propagation.

What do you understand about the Master-Detail relationship in

✅A Master-Detail
Salesforce?
Definition:​
relationship is a strong parent-child relationship where the child record
cannot exist without the parent. The parent controls the child’s ownership, sharing, and
security.

✅ Key Points:
●​ Child inherits parent’s sharing and security settings.
●​ Cascade Delete: Deleting the parent automatically deletes all child records.
●​ Roll-Up Summary: Available on the parent to summarize child data (COUNT, SUM,
MIN, MAX).

✅ Health Cloud Example:

●​ CarePlan__c (Parent) → CarePlanGoal__c (Child).
○​ If you delete a CarePlan, all related CarePlanGoals are deleted.
○​ Roll-up summary on CarePlan shows Total Goals Count.

✅ Best Practices / Testing Steps:

●​ Delete parent record and confirm child records are deleted.
●​ Validate roll-up summary fields update correctly when child records change.
●​ Test automation (Flows, Triggers) to ensure they handle cascade deletes properly.

---

21. What do you understand about workflow in Salesforce?

Short answer:
Declarative automation tool that triggers after records are saved to perform field updates,
send email alerts, create tasks, or send outbound messages. Workflows are limited vs Flow.

Health Cloud example:

When a Patient is flagged as “No-show” thrice, create a task to follow-up.

Test steps / Test lead checks:

Validate criteria, test field updates, ensure email templates send correct merge fields, and
test time-based workflow scheduling in sandbox.

✅A Workflow
What do you understand about Workflow in Salesforce?
Definition:​
in Salesforce is an automation tool that performs predefined actions (like field
updates, email alerts, tasks) when certain criteria are met. It is declarative, meaning no
coding is required.

✅ Key Points:
●​ Automates standard internal procedures to save time.
●​ Actions include Field Update, Email Alert, Task Creation, Outbound Message.
●​ Cannot handle complex logic or multiple objects (use Flow for that).
●​ Executes after record save (cannot run before save).

✅ Health Cloud Example:

●​ When a CarePlan__c status changes to Completed, a Workflow Rule:
○​ Sends an email alert to the care coordinator.
○​ Updates a field on Patient__c to reflect care plan completion.

✅ Best Practices / Testing Steps:

●​ Create test records that meet and do not meet the criteria.
●​ Validate that workflow actions trigger correctly (email sent, field updated).
●​ Check time-dependent actions (e.g., send reminder email after 7 days).
●​ Ensure field-level security does not block updates.

---

22. What is WhoId and WhatId in activities?

Short answer:
WhoId points to a person (Contact/Lead). WhatId points to an object (Account, Case,
Opportunity, or custom).

Health Cloud example:

A phone task: WhoId = PatientContact__c; WhatId = CarePlan__c.

Test steps / Test lead checks:

Create activities and verify correct linking and behavior when related records are deleted or
merged.

Definition:​
In Salesforce activities (Tasks and Events), WhoId and WhatId are special polymorphic
fields that link the activity to related records.

✅ Key Points:
●​ WhoId: Refers to a person-type record (Lead or Contact).
●​ WhatId: Refers to an object-type record (Account, Opportunity, or any custom
object).
●​ Both fields allow activities to be associated with multiple entities for better tracking.

✅ Health Cloud Example:

 ●​ When scheduling a CarePlan review meeting:
○​ WhoId = Patient__c (or Contact representing the patient).
○​ WhatId = CarePlan__c (the care plan being discussed).
●​ This links the meeting to both the patient and their care plan for complete context.

✅ Best Practices / Testing Steps:

●​ Verify that activities display correctly under both related records (Patient and
CarePlan).
●​ Test creating tasks/events via UI and API to ensure WhoId and WhatId populate
correctly.
●​ Validate reporting: Activities should appear in related lists for both entities.

---

23. What is a bucket field in reports?

Short answer:
A report UI feature to categorize field values into buckets without changing object metadata.

Health Cloud example:

Group patients by Age into buckets: Pediatric (<18), Adult (18–64), Senior (65+).

Test steps / Test lead checks:

Validate bucket boundaries and "Other" bucket behavior; ensure charts respect buckets.
Definition:​
A Bucket Field in Salesforce reports allows you to group records into categories without
creating a formula or custom field. It’s a way to segment data dynamically within a report.

✅ Key Points:
●​ Used to categorize values of a field into buckets (e.g., ranges or labels).
●​ Works only in reports, not stored in the database.
●​ Simplifies grouping without changing object schema.

✅ Health Cloud Example:

●​ In a Patient report, create a bucket field for Age Group:
○​ Bucket 1: 0–18 = “Child”
○​ Bucket 2: 19–60 = “Adult”
○​ Bucket 3: 61+ = “Senior”
●​ This helps care coordinators quickly segment patients by age for targeted care plans.

---

24. Can you have a roll up summary field in case of Master-Detail relationship?

Short answer:
Yes — roll-up summaries exist on the master side of a Master-Detail relationship.

Health Cloud example:

CarePlan__c.Total_Goals__c = COUNT(CarePlanGoal__c).

Test steps / Test lead checks:

Create/delete child records and verify parent roll-up recalculates; test with bulk operations.

---

25. Which fields are automatically Indexed in Salesforce?

Short answer:
Id, OwnerId, lookup/master-detail fields, CreatedDate, SystemModstamp, RecordTypeId,
and fields marked Unique or External ID. Some standard fields (Email, Name) may be
indexed on specific objects.

Health Cloud example:

Indexing Patient.External_MRN__c as External ID speeds up upsert operations when
syncing from EHR.

Test steps / Test lead checks:

Run explain plan for problematic queries or inspect selective filters; request custom indexes
from Salesforce Support when necessary.

ndexed fields in Salesforce improve query performance by allowing faster data retrieval.
Some fields are automatically indexed by the platform.

✅ Key Points:
●​ Primary Key: Id field of every object.
●​ Foreign Keys: Fields that are part of relationships (Lookup and Master-Detail).
●​ Audit Fields: CreatedDate, SystemModstamp.
●​ Unique Fields: Fields marked as Unique or External ID.
●​ Custom Fields: If marked as External ID or Unique, they are indexed.

✅ Health Cloud Example:

●​ Patient__c.Id (primary key) is indexed.
●​ Lookup fields like CarePlan__c.Patient__c are indexed for faster queries.
●​ CreatedDate on Assessment__c is indexed for reporting and filtering.
●​ If you create a custom field MemberID__c and mark it as External ID, it becomes
indexed.

---

26. For which criteria in workflow “time dependent workflow action” cannot be created?

Definition:​
Time-dependent workflow actions are scheduled actions that execute after a certain time
interval based on rule criteria. However, they cannot be created for every type of criteria.

✅ Key Points:
●​ Cannot be created for “Created” or “Every time record is created and edited”
evaluation criteria.
 ●​ Allowed only when the rule evaluates on “Created and subsequently meets
criteria”.
●​ Reason: Time-dependent actions need a stable condition, not one that changes
constantly.

✅ Health Cloud Example:

●​ If you have a workflow on CarePlan__c:
○​ Allowed: Send an email reminder 7 days after CarePlan status changes to
“Active”.
○​ Not Allowed: If the workflow is set to fire every time CarePlan is edited,
you cannot add time-dependent actions because the criteria can change
repeatedly.

✅ Best Practices / Testing Steps:

●​ Verify workflow evaluation criteria before adding time-dependent actions.
●​ Test with sample CarePlan records to ensure scheduled actions trigger correctly.
●​ Check Pending Actions in Setup to confirm they are queued.

---

27. What are the types of custom settings in Salesforce? What is the advantage of using
custom settings?

Short answer:
Two types: Hierarchy (org/profile/user overrides) and List (global list). Advantage: cached,
fast access without SOQL, useful for configuration.

Health Cloud example:

Hierarchy setting Enable_Telehealth__c that turns telehealth features on per user or per
profile.

Test steps / Test lead checks:

Update hierarchy settings and confirm cached behavior (may require a refresh in some
contexts). Test per-profile overrides.

---

28. Why do we need to write test classes? How to identify if a class is a test class?

Short answer:
Tests validate Apex behavior, ensure deployment eligibility, and protect regression. Test
classes are annotated with @isTest or contain testMethod.

Health Cloud example:

Test a trigger that updates patient risk scores and verifies no recursion and correct
calculations in bulk.

Test steps / Test lead checks:

Ensure tests cover positive/negative/bulk scenarios and include callout mocks where
appropriate.

---

29. What is minimum test coverage required for trigger to deploy?

Short answer:
Org must have 75% Apex coverage to deploy. Ensure triggers and related classes are
covered and their tests assert expected results.

Health Cloud implication:

Critical triggers (e.g., patient data workflows) must be covered by unit tests validating both
small and bulk cases.

---

30. What is an external ID in Salesforce? Which field data types can be used as external
IDs?

Short answer:
An External ID stores an identifier from an external system for upsert and matching.
Supported field types: Text, Number, Email, Auto-Number. Marking a field External ID also
automatically indexes it.

Health Cloud example:

Use EHR MRN External_MRN__c (Text) as External ID to upsert patient records.

Test steps / Test lead checks:

Test upsert path using external ID; handle duplicate external IDs and error conditions.

---

31. What are some causes of data loss in Salesforce? How many days in Recycle Bin?

Definition:​
Data loss in Salesforce occurs when records or fields are deleted or overwritten
unintentionally due to configuration changes, integrations, or user actions.

✅ Key Points (Causes of Data Loss):

●​ Changing Data Types:
○​ Example: Changing a field from Text to Number deletes existing text values.
●​ Import/Update Errors:
○​ Incorrect mapping during Data Loader or API updates.
●​ Integration Overwrites:
○​ External system updates overwrite Salesforce data.
●​ Cascade Deletes:
○​ Deleting a parent record in a Master-Detail relationship deletes all child
records.
 ●​ Workflow/Automation Errors:
○​ Incorrect field updates in Workflow, Flow, or Apex triggers.

✅ Health Cloud Example:

●​ If a CarePlan__c record is deleted, all related CarePlanGoal__c records are deleted
due to Master-Detail relationship.
●​ Changing Assessment__c.Score__c from Text to Number will remove all previous
text values.

✅ Recycle Bin Retention:

●​ Deleted records remain in the Recycle Bin for 15 days (standard Salesforce
behavior).
●​ After 15 days, records are permanently deleted.

✅ Best Practices / Testing Steps:

●​ Validate field type changes in sandbox before production.
●​ Test data imports with a small sample first.
●​ Review automation logic to prevent unintended updates or deletes.
●​ Monitor Recycle Bin for accidental deletions and restore within 15 days.

---

32. How can a record be shared in Salesforce?

✅Record
Definition:​
sharing in Salesforce determines how users can access records beyond the default
Organization-Wide Defaults (OWD) and role hierarchy.

✅ Key Points:
●​ Role Hierarchy: Users higher in the hierarchy automatically get access to records
owned by users below them.
●​ Sharing Rules: Criteria-based or owner-based rules to open access to groups or
roles.
●​ Manual Sharing: Record owner or admin manually shares a record with specific
users.
●​ Apex Sharing: Programmatic sharing for custom logic.
●​ Teams & Territories: Account Teams, Opportunity Teams, and Territory
Management for collaborative access.

✅ Health Cloud Example:

●​ A Patient__c record is private by OWD.
●​ To share with a Care Coordinator who is not in the same role hierarchy:
○​ Create a Sharing Rule to share all Patient records where Region = “East”
with the East Care Team.
●​ Alternatively, use Manual Sharing for a specific Patient record with a specialist.

✅ Best Practices / Testing Steps:

●​ Validate OWD settings for the object (e.g., Patient__c = Private).
●​ Test sharing rule by creating a record that meets criteria and confirm access for
target users.
●​ Check manual sharing option on record detail page.
●​ Verify Apex sharing logic in debug logs for custom sharing scenarios.
---

33. How would you approach testing a complex Salesforce integration with an external
system?

Short answer:
Understand data contract, sandbox testing, mock/stub services, test positive/negative/edge
cases, load/performance testing, idempotency, and reconcile records.

Health Cloud example:

Test bi-directional sync between Salesforce and EHR: patient demographics from EHR →
Patient records; clinical notes back to EHR. Validate transformations, security (PHI/HIPAA),
and error-handling.

Test steps / Test lead checks:

Validate auth/oAuth token lifecycles, test boundary conditions, ensure logging/alerting on

failures.

---

34. Can you explain the concept of bulkification in Apex and why it's important for QA?

Short answer:
Bulkification means writing Apex that handles lists of records efficiently (single SOQL for
many records, DML outside loops), essential to avoid hitting governor limits and for
real-world scale.

Health Cloud example:

Batch importing 5k appointments requires triggers that handle collections and use maps for
lookups.

Test steps / Test lead checks:

Run unit tests that insert/update 200 or more records and confirm no governor exceptions.

---

35. How would you test Salesforce Lightning components?

Definition:​
Salesforce Lightning Components are UI elements built using Aura or LWC (Lightning Web
Components) for dynamic, responsive interfaces. Testing ensures they function correctly
across browsers and devices.

✅ Key Points:
●​ Validate UI rendering and responsiveness.
●​ Test component attributes, events, and data binding.
●​ Check integration with Apex controllers and server-side logic.
●​ Ensure cross-browser compatibility and performance.
✅ Health Cloud Example:
●​ Lightning component for CarePlan__c Summary:
○​ Displays CarePlan details and related CarePlanGoals.
○​ Allows care coordinators to update status inline.
●​ Test scenarios:
○​ Component loads correct CarePlan data.
○​ Inline edits save successfully and reflect in Salesforce.
○​ Related goals update dynamically without page refresh.

---

36. What strategies would you use to optimize Salesforce reports and dashboards
performance?

Definition:​
Optimizing reports and dashboards ensures faster load times, accurate data, and better
user experience, especially when dealing with large datasets.

✅ Key Points:
●​ Use Filters and Limit Data: Apply selective filters to reduce the number of records
processed.
●​ Use Indexed Fields: Filter on indexed fields like Id, CreatedDate, or External IDs
for faster queries.
●​ Summary and Matrix Reports: Use grouping and summaries instead of detailed
lists for large data sets.
●​ Reduce Dashboard Components: Limit the number of components and use
efficient source reports.
●​ Schedule Refresh: Avoid real-time refresh for heavy dashboards; schedule during
off-peak hours.
●​ Avoid Complex Formulas: Simplify calculations in reports to reduce processing
time.

✅ Health Cloud Example:

●​ A dashboard showing CarePlan completion rates and Patient assessments:
○​ Use filters like Region or Care Coordinator to limit data.
○​ Group CarePlans by Status instead of listing all records.
○​ Schedule dashboard refresh at night to avoid peak usage.

✅ Best Practices / Testing Steps:

●​ Test report performance with large data volumes (e.g., 50,000+ Patient records).
●​ Validate that filters and grouping reduce load time.
●​ Check dashboard refresh logs and ensure scheduled refresh works.
●​ Use Query Plan Tool to confirm indexed fields are used in filters.

---

37. How would you approach testing a Salesforce CPQ implementation?

Salesforce CPQ (Configure, Price, Quote) is used to automate quoting processes, including
product configuration, pricing, and discounting. Testing ensures accurate pricing, approvals,
and quote generation.

✅ Key Points:
●​ Validate product configuration rules (bundles, options, constraints).
●​ Test pricing logic (list price, discounts, subscriptions).
●​ Verify quote generation and document accuracy.
●​ Check approval workflows for discounts and special pricing.
●​ Validate integration with billing and ERP systems.

✅ Health Cloud Example:

●​ For a healthcare organization selling care packages:
○​ Configure a CarePlan Package with options like telehealth visits,
assessments, and pharmacy benefits.
○​ Test pricing rules: Adding extra assessments should increase cost correctly.
○​ Validate quote PDF includes correct patient details and care plan
components.
○​ Ensure approval triggers when discount exceeds 20%.

---

38. Steps in the Salesforce Testing Lifecycle

Short answer:
Requirement & impact analysis → Test strategy → Environment & data setup → Test case
design → Automation & unit tests → Execution (functional/integration/UAT) → Regression →
Release validation → Production smoke checks → Retrospective.

Health Cloud emphasis:

Include PHI handling and EHR integration testing, backward compatibility,

39. How many events do we have in Aura components? How are they used?

Aura Components use events to enable communication between components. Events allow
data to be passed and actions to be triggered without tight coupling between components.

✅There
Key Points:​
are three types of events in Aura Components:
1.​ Component Events​

○​ Fired from a child component and handled by its parent.

○​ Used for communication within a component hierarchy.
2.​ Application Events​

○​ Fired and handled by any component in the application.

○​ Used for communication across unrelated components.
3.​ System Events​

○​ Predefined by the Aura framework (e.g., init, render).

○​ Used for lifecycle management.
✅ Health Cloud Example:
●​ Component Event:
○​ A CarePlanGoal component fires an event when a goal is marked complete,
and the parent CarePlan component updates the progress bar.
●​ Application Event:
○​ When a Patient__c record is updated in one component, an application
event notifies other components (like Assessment or CareTeam) to refresh
data.

---

40. What is an approval process?

Definition:​
An Approval Process in Salesforce automates the routing of records for approval based on
defined criteria. It ensures that certain actions (like status changes or discounts) require
authorization before completion.

✅ Key Points:
●​ Defines steps, approvers, and actions for record approval.
●​ Supports initial submission actions, approval/rejection actions, and final
actions.
●​ Can include email notifications, field updates, and locking records during
approval.
●​ Works with standard and custom objects.

✅ Health Cloud Example:

●​ When a CarePlan__c exceeds a cost threshold (e.g., $5,000), it must be approved
by a Care Manager before activation.
●​ Steps:
1.​ Care Coordinator submits CarePlan for approval.
2.​ Care Manager reviews and approves or rejects.
3.​ If approved, CarePlan status updates to “Active”; if rejected, status changes
to “Needs Review”.

41. What is a recursive trigger and how can we avoid it?

Definition:​
A recursive trigger occurs when a trigger causes itself (or another trigger on the same
object) to execute repeatedly, leading to infinite loops or hitting governor limits.

✅ Key Points:
●​ Happens when DML operations inside a trigger cause the same trigger to fire
again.
●​ Common in before/after update triggers where an update inside the trigger updates
the same record.
●​ Can lead to performance issues and governor limit errors.

✅ Health Cloud Example:

●​ A trigger on CarePlan__c updates related Assessment__c records.
●​ If the Assessment trigger also updates CarePlan, this can cause a recursive loop.
 ●​ Example: CarePlan → Assessment → CarePlan → Assessment (infinite loop).

42. How is Process Builder and Flow Builder different?

Definition:​
Both are Salesforce automation tools, but Flow Builder is more advanced and flexible than
Process Builder.

✅ Key Points:
●​ Process Builder:​

○​ Automates simple processes like field updates, email alerts, and record
creation.
○​ Limited to one object per process.
○​ Cannot handle complex logic or loops.
●​ Flow Builder:​

○​ Handles complex automation with multiple objects, loops, and branching

logic.
○​ Supports screen flows, record-triggered flows, and scheduled flows.
○​ Can replace most Process Builder and Workflow functionality.

✅ Health Cloud Example:

●​ Process Builder:​

○​ When CarePlan__c status changes to “Completed,” send an email to the

care coordinator.
●​ Flow Builder:​

○​ When Assessment__c score is below threshold, update Patient__c risk

level, create a CarePlan__c, and notify the care team—all in one flow.

---

43. What is the order of execution of Trigger, Process Builder, and Workflow?

What is the order of execution of Trigger, Process Builder, and

✅Salesforce
Workflow?
Definition:​
has a defined order of execution for automation tools when a record is saved.
Understanding this ensures predictable behavior and avoids conflicts.

✅ Key Points (Simplified Order):

1.​ Before Triggers​

○​ Executes before the record is saved to the database.

○​ Commonly used for validation or setting default values.
2.​ After Triggers​

○​ Executes after the record is saved.

○​ Used for actions that require record ID or committed data.
3.​ Workflow Rules​
 ○​ Field updates from Workflow can cause another round of before/after triggers.
○​ Executes after triggers but before Process Builder.
4.​ Process Builder​

○​ Executes after Workflow actions.

○​ Can update records, call Flows, or send notifications.
5.​ Flows (if invoked by Process Builder)​

○​ Executes after Process Builder actions.

✅ Health Cloud Example:

●​ When updating CarePlan__c status to “Active”:
1.​ Before Trigger: Validate CarePlan start date.
2.​ After Trigger: Create related CarePlanGoals.
3.​ Workflow: Update a field on Patient__c (e.g., CarePlanCount).
4.​ Process Builder: Send an email to Care Coordinator and launch a Flow to
create an Assessment.

---

44. How many APIs are available in Salesforce?

Salesforce provides multiple APIs to enable integration, data manipulation, and automation
between Salesforce and external systems.

✅ Key Points:
●​ Common APIs include:
1.​ REST API – Lightweight, easy for web and mobile apps.
2.​ SOAP API – For enterprise-level integrations requiring WSDL.
3.​ Bulk API – Handles large data volumes asynchronously.
4.​ Streaming API – Real-time notifications using PushTopic or Platform Events.
5.​ Metadata API – For deploying and retrieving configuration changes.
6.​ Tooling API – For building developer tools and accessing metadata.
7.​ Composite API – Combines multiple requests into one call.
8.​ Connect API – For social and collaboration features (Chatter).

✅ Health Cloud Example:

●​ REST API: Sync patient demographics from EHR to Salesforce Health Cloud.
●​ Bulk API: Load thousands of CarePlan__c records during migration.
●​ Streaming API: Notify Salesforce when an external pharmacy system updates
prescription status.
●​ Metadata API: Deploy new CarePlan fields from sandbox to production.

✅ Best Practices / Testing Steps:

●​ Validate API authentication (OAuth tokens).
●​ Test data mapping and field-level security during API operations.
●​ Perform positive and negative tests (valid and invalid payloads).
●​ Monitor API limits and governor limits during bulk operations.
●​ Use Postman or Workbench for API testing.

---
45. What is a Trigger? Name the different types

A Trigger in Salesforce is an Apex script that executes before or after specific data
manipulation events (DML) like insert, update, delete, or undelete on a Salesforce object.

✅ Key Points:
●​ Used to automate complex business logic that cannot be handled by declarative tools
(Workflow, Process Builder).
●​ Executes automatically when the specified event occurs.
●​ Can run before or after the record is saved to the database.

✅ Types of Triggers:
1.​ Before Triggers​

○​ Execute before the record is saved.

○​ Commonly used for validation or setting default values.
2.​ After Triggers​

○​ Execute after the record is saved.

○​ Used for actions that require record ID or committed data (e.g., creating
related records).
Events Supported:
●​ before insert, before update, before delete
●​ after insert, after update, after delete, after undelete

✅ Health Cloud Example:

●​ Before Trigger:
○​ On CarePlan__c, validate that the start date is not in the past before saving.
●​ After Trigger:
○​ When a CarePlan__c is created, automatically create related
CarePlanGoal__c records.

✅ Best Practices / Testing Steps:

●​ Bulkify triggers to handle multiple records efficiently.
●​ Avoid SOQL/DML inside loops to prevent governor limits.
●​ Test with single record and bulk updates (200 records).
●​ Validate trigger logic in sandbox before deploying to production.
---

46. What is a dynamic Dashboard?

A Dynamic Dashboard in Salesforce displays data based on the logged-in user’s access
and role, rather than showing the same data to everyone. It personalizes the view without
creating multiple dashboards.

✅ Key Points:
●​ Shows data according to user’s security settings (role, sharing rules).
●​ Reduces the need for multiple dashboards for different users.
●​ Can be scheduled for refresh (except dynamic dashboards cannot be emailed).
●​ Useful for organizations with role-based visibility requirements.

✅ Health Cloud Example:

●​ A Care Coordinator Dashboard:
 ○​ Displays CarePlans, Assessments, and Patient__c records only for
patients assigned to that coordinator.
●​ A Care Manager Dashboard:
○​ Shows aggregated data for all patients under their team.
●​ Both dashboards use the same dynamic dashboard, but data changes based on
who logs in.

✅ Best Practices / Testing Steps:

●​ Log in as different users (Care Coordinator, Care Manager) and verify dashboard
data changes accordingly.
●​ Validate that users only see records they have access to (respecting OWD and
sharing rules).
●​ Test dashboard filters and components for correct data segmentation.
●​ Confirm that dynamic dashboards cannot be scheduled for email delivery.

---

47. How many records can we display on a single page in a report?

Definition:​
Salesforce reports display data in a tabular format, but there is a limit on how many rows
can appear on a single page for performance reasons.

✅ Key Points:
●​ A report view can display up to 2,000 rows per page in the Salesforce UI.
●​ If the report has more than 2,000 rows, you can export the report to view all data.
●​ Export options:
○​ Formatted Report (Excel/PDF)
○​ Details Only (CSV for large data sets)

✅ Health Cloud Example:

●​ A report listing Patient__c records with related CarePlan__c details:
○​ If there are 10,000 patients, only 2,000 rows will show per page in the UI.
○​ To analyze all patients, export the report as CSV.

✅ Best Practices / Testing Steps:

●​ Validate that large reports paginate correctly (2,000 rows per page).
●​ Test export functionality for full data retrieval.
●​ Check performance when applying filters to reduce row count.
●​ Ensure sensitive data (e.g., patient info) is secure during export.

---

48. Can we create formula fields in Reports?

Yes, Salesforce allows you to create custom summary formulas in reports, but not
standard formula fields like on objects. These formulas are used to calculate values
dynamically within the report.

✅ Key Points:
●​ Formula fields in reports are called Custom Summary Formulas.
●​ They work on summary-level data, not individual rows.
 ●​ You can use operators, functions, and fields from the report.
●​ Available only in Summary, Matrix, and Joined Reports (not Tabular).

✅ Health Cloud Example:

●​ In a CarePlan report, create a formula to calculate:​
Completion % = (Completed Goals / Total Goals) * 100
●​ This helps care managers track progress without creating extra fields on the object.

✅ Best Practices / Testing Steps:

●​ Validate formula accuracy with sample data.
●​ Test edge cases (e.g., division by zero when no goals exist).
●​ Ensure the formula works across grouped data in Summary or Matrix reports.
●​ Confirm that users have access to fields used in the formula.

---

49. What kind of reports can be used to generate dashboards?

Definition:​
Dashboards in Salesforce are built using source reports. Only certain types of reports can
be used as dashboard components.

✅ Key Points:
●​ Dashboards can use Summary Reports, Matrix Reports, and Joined Reports as
source reports.
●​ Tabular Reports cannot be used unless they have a row limit and are used in a
chart component.
●​ Each dashboard component (chart, gauge, metric) is tied to one source report.

✅ Health Cloud Example:

●​ A dashboard showing CarePlan completion rates:
○​ Source report: Summary Report grouped by CarePlan Status (Active,
Completed).
●​ A dashboard showing Patient risk distribution:
○​ Source report: Matrix Report grouped by Region and Risk Level.
●​ A dashboard showing Top 10 Care Coordinators by CarePlans managed:
○​ Source report: Tabular Report with a row limit of 10.

✅ Best Practices / Testing Steps:

●​ Verify that the source report type supports dashboard components.
●​ Test grouping and summaries in the report before adding to the dashboard.
●​ Validate that filters applied in the dashboard reflect correctly in the source report.
●​ Check performance when refreshing dashboards with large data sets.

---

50. What is Lightning App Builder? Where can we use Lightning Components?

Interview answer:
Lightning App Builder is a drag-and-drop UI tool to create Lightning Pages (record pages,
app pages, home pages) using standard or custom components (LWC or Aura).
Components can be used on record pages, app pages, home pages, and Experience Cloud
pages.

Health Cloud example:

Build a Patient 360 Lightning page with custom LWC CarePlanTimeline and standard
Related Lists for Appointments.

Test steps / Checks:

Test component visibility rules and mobile behavior.

Validate navigation and lightning data service integration for components.

---

51. What is the difference between permission sets and sharing rules?

Interview answer:
Permission Sets grant object/field/system permissions (what users can do). Sharing Rules
grant record-level visibility (which records users can see). They serve different access
models: Permission Sets expand capabilities; Sharing Rules expand access to records.

Health Cloud example:

Permission Set ClinicalNoteEditor grants edit rights to Clinical_Note__c. A Sharing Rule
gives the Billing Team read access to Authorization__c records with insurance type
'Commercial'.

Test steps / Checks:

Verify permission set assignments allow/disallow actions (create/edit).

Verify sharing rules grant visibility without elevating permissions to edit.

---

52. What are the different types of relationships in Salesforce? Can you differentiate
between them?

Interview answer:
Types: Master–Detail (tight coupling, cascade deletes, roll-up summaries), Lookup (loose
coupling), Many-to-Many (junction object with 2 MD relationships), Self-Relationship (object
relates to itself), External Relationship (Salesforce Connect external object lookup). Each
affects sharing, deletion, and roll-ups.

Health Cloud example:

CarePlan__c (Master) → CareGoal__c (Detail) — roll-up counts goals.

Appointment__c lookup to Provider__c — provider deletion doesn’t delete appointments.

ProviderProgram_Junction__c linking Provider__c and Program__c.

Test steps / Checks:

Validate cascade deletes for MD, nulling behavior for lookup, existence of roll-ups, and
behavior of external object references.

---

53. What is a standard profile and name some of them?

Interview answer:
Standard profiles are built-in Salesforce profiles that come with orgs and cannot be deleted.
Examples: System Administrator, Standard User, Read Only, Marketing User, Contract
Manager, Solution Manager.

Health Cloud example:

Start from a Standard User profile, then create custom profiles and permission sets for
clinicians, nurses, and billers.

Test steps / Checks:

Validate baseline permissions on standard profiles and adjust with custom

profiles/permission sets for Health Cloud roles.

---

54. What is a sandbox and what are the different types of sandboxes?

Interview answer:
A Sandbox is a copy of your production org for development/testing/training. Types:
Developer (metadata), Developer Pro (more storage), Partial Copy (metadata + sample
data), Full (complete copy of production). Refresh intervals differ.

Health Cloud example:

Use a Full Sandbox to test new EHR integration end-to-end with realistic patient and claims
data.

Test steps / Checks:

Ensure test data templates are available for Partial/Developer sandboxes; test integrations in
Full sandbox to validate external endpoints.

---

55. What is the difference between profile and role? Can a user be assigned two profiles?
Interview answer:
Profile controls permissions (one per user). Role controls record-level access/hierarchy (one
per user). A user cannot have two profiles; use Permission Sets to add permissions.

Health Cloud example:

Care Coordinator profile grants CRUD on Patient__c. Role places them under Care
Manager allowing the manager to see subordinate patient records.

Test steps / Checks:

Validate login, access, and data visibility with test users across profiles and roles.

---

56. You’ve configured a workflow rule. How would you test whether it executes as expected?

Interview answer:
Create test records matching and not matching the rule criteria; check that email alerts,
tasks, field updates, and outbound messages are triggered; verify time-based actions in
sandbox; check debug logs for execution trace.

Health Cloud example:

Workflow sends a follow-up task when a NoShow__c flag is set. Test create and update
scenarios and ensure the task is generated.

Test steps / Checks:

Validate email templates and recipients, confirm field updates persist, and verify no
unexpected duplicate actions.

---

57. What are your steps to ensure field-level security is properly applied during testing?

Interview answer:
Check Field-Level Security in Setup, use 'Login As' different profiles, verify via UI and API
that unauthorized users can't see or update fields, test in reports and mobile contexts, and
ensure permission sets don’t accidentally grant access.

Health Cloud example:

Clinical Notes should be hidden from billing-only profiles; validate both UI and API visibility.

Test steps / Checks:

Create test users with target profiles, perform CRUD on fields and check API responses
using REST.

---
58. User reports they can’t see a field on the layout. How would you investigate and test
this?

Interview answer:
Check page layout assignment for the user’s record type/profile, verify Field-Level Security
and permission sets, check Lightning Page component visibility (dynamic forms), test ‘Login
As’ to reproduce, and confirm mobile app differences.

Health Cloud example:

A nurse can't see Allergies__c — check that Record Type is “Inpatient” using a different
layout or component filter that hides allergies.

Test steps / Checks:

Walk through profile & page layout setup, test Login As the user, check console/mobile
layout differences.

---

59. What is your approach to testing a newly added custom field in an existing object?

Interview answer:
Validate FLS, add the field to appropriate page layouts/record types, update integrations and
mapping, update unit tests & automation, verify reports/dashboards, and run regression to
ensure no side effects.

Health Cloud example:

New RiskScore__c on Patient__c: validate the calculation logic, ensure it’s visible only to
clinicians, and update care-gap flows relying on risk score thresholds.

Test steps / Checks:

Test creation & update of the field, integration upserts, report filters, and any workflow or
trigger references.

---

60. How do governor limits influence how you design or execute your Salesforce test cases?

Interview answer:
They push for bulk tests and efficient designs. Tests must simulate real-world bulk behavior
(200+ records), ensure asynchronous processing for heavy loads, and avoid test code itself
breaching limits.

Health Cloud example:

When creating many encounter records in tests, ensure triggers use maps to avoid
per-record queries and confirm no limit exceptions occur.

Test steps / Checks:

Write bulk test methods inserting/updating 200+ records; run debug logs and confirm no
SOQL/DML limit breaches.

---

61. Walk me through a Salesforce approval process you’ve tested. What were the key test
cases and validations involved?

Interview answer:
Validate entry criteria, correct approver resolution (role/hierarchy), email notifications and
templates, record locking during approval, rejection paths, re-submission flow, and
post-approval automation (field updates/tasks).

Health Cloud example:

ReferralAuthorization__c requires clinical approver then payer approver. Test approver
substitution, recall, rejection, and that scheduling only happens after final approval.

Test steps / Checks:

Test multiple approver scenarios, delegate approver, audit trail entries, and ensure
downstream scheduled processes only run post-approval.

---

62. What’s your approach to exploratory testing in Salesforce? Can you give a real scenario
where it uncovered a hidden issue?

Interview answer:
Use personas and role-based access, try edge-case workflows, simulate concurrent actions,
and explore integrations. Document and create formal test cases from findings.

Health Cloud example (scenario):

While exploring Lead-to-Patient conversion with different profiles, discovered a Process
Builder overwrote patient contact details after conversion—caused by an outdated PB
triggered after workflow updates. Found via exploratory testing across profiles and
conversion paths.

Test steps / Checks:

Reproduce discovery, add regression tests, convert PB to Flow to prevent the issue, and add
guardrails like field change checks.

---

63. How do you ensure consistent test coverage and quality in a rapidly changing Salesforce
environment?

Interview answer:
Maintain an up-to-date regression suite, use CI/CD to run tests on metadata changes,
maintain test data factories and templates, assign ownership of test cases for each
automation, and run smoke tests after deployments.

Health Cloud example:

Maintain health-cloud-specific regression cases (Patient intake, Care Plan lifecycle, EHR
sync) and run tests in sandboxes after each release.

Test steps / Checks:

Integrate tests into CI pipelines, ensure automated test runs on pull requests, and maintain a
traceability matrix.

---

64. What’s your process for testing integrations, e.g., a third-party ERP via REST API?

Interview answer:
Define contract (payload/schema), mock endpoints for sandbox testing, test authentication &
token lifecycle, validate payload transformations, error & retry behavior, and run load tests.
Monitor logs and reconcile data after sync.

Health Cloud example:

Sync invoices to ERP—test invoice creation/updates, failed submissions, and retry logic for
network failures.

Test steps / Checks:

Use Postman/newman for contract tests, implement mock servers for negative scenarios,
and verify DB/state reconciliation after integration runs.

---

65. How do you approach regression testing when multiple workflows, flows, and Apex
triggers are updated in the same sprint?

Interview answer:
Identify impacted business flows, run prioritized regression tests for critical processes, run
full regression in staging/full sandbox, coordinate with devs to isolate and resolve conflicts,
and have rollback plans.

Health Cloud example:

If Care Plan flows, triggers, and notifications updated together, validate end-to-end patient
workflows (intake → care plan → goals → notifications) rather than isolated unit tests.

Test steps / Checks:

Create smoke test suites for high-risk areas and run them after combined changes; validate
integration points and scheduled jobs.
---

66. Can you explain the difference between testing in Classic vs Lightning Experience?
What UI or functional nuances should QA watch for?

Interview answer:
Classic is server-rendered static pages; Lightning is component-based with client-side
rendering and dynamic components. Testing in Lightning requires additional checks for
component visibility, events, performance, and responsive behavior.

Health Cloud example:

Lightning LWC CarePlanTimeline might lazy-load items and use client-side events—validate
rendering, event handling, and behavior under slow network.

Test steps / Checks:

Validate LWC selectors for automation, check accessibility (a11y), and test mobile layouts &
partial page rerenders.

---

67. What is Salesforce Order of Execution?

Interview answer:
A deterministic sequence of rules/events that execute when a record is saved (validations →
before triggers → after triggers → workflows → processes/flows → commit → post-commit).
Knowing this is crucial to design and debug automations.

Health Cloud example:

A before-save flow sets a flag, a trigger recalculates risk, a workflow updates a
field—understanding order prevents overwrites and unintended re-evaluations.

Test steps / Checks:

Use debug logs for complex save operations; assert final field values and system behavior
after full execution.

---

68. Describe the different ways to make a field required in Salesforce

Interview answer:
Make field required at field definition, set as required on page layout, enforce via Validation
Rule (conditional), enforce via Record Type + page layout, or require in LWC/Screen Flow
UI.

Health Cloud example:

Require Consent_Signed__c before scheduling a procedure: use validation rule to ensure
consent is signed for specific record types.
Test steps / Checks:

Test all entry points (UI, API, Data Loader) to ensure enforcement—validation rules and
field-level required differ in enforcement for API loads.

---

69. Describe a few ways that Account and Contact information can be imported into
Salesforce

Interview answer:
Data Import Wizard (simple UI, dedupe), Data Loader (large volumes, desktop),
[Link] (cloud), Bulk API (large batches), ETL tools (MuleSoft, Informatica) for complex
transforms.

Health Cloud example:

Nightly batch import of provider rosters via Bulk API and dedupe using External ID
(ProviderLicense__c).

Test steps / Checks:

Test small and large batch imports, check deduplication rules, mapping, and referential
integrity (linking Accounts to Contacts).

---

70. Describe the differences between Lightning Pages, Page Layouts, and Record Types

Interview answer:

Lightning Pages: App Builder composed pages that arrange components (LWCs/Aura).

Page Layouts: Determine field order, sections, related lists on the Details tab.

Record Types: Allow multiple business processes & picklist values; map to different page
layouts per profile.

Hea
Health Cloud example:
“Patient 360” Lightning page (component-based) uses a Page Layout for fields and multiple
Record Types for Inpatient vs Outpatient with different picklists.

Test steps / Checks:

Verify for each record type that the correct page layout and Lightning Page variant are
shown for a given profile.

---
71. Can you describe the differences between Roles, Profiles, and Permission Sets?

Interview answer:

Roles: Record-level visibility via hierarchy.

Profiles: Baseline permissions (object/field/tab) — one per user.

Permission Sets: Add-on permission bundles assignable to users (many per user).

Health Cloud example:

Role: Care Manager sees subordinates’ patients; Profile: Care Coordinator baseline access;
Permission Set: TelehealthAccess grants telehealth fields & LWC access.

Test steps / Checks:

Use Login As to validate role-based visibility and permission-set-level functionality.

---

72. What is Salesforce Customer 360?

Interview answer:
Customer 360 is Salesforce’s vision/product set to provide a unified profile across Salesforce
systems—bringing together Sales, Service, Marketing, Commerce and Health Cloud (Patient
360).

Health Cloud example:

Patient 360 pulls clinical records, claims, appointment history, and engagement into one
unified view for clinicians.

Test steps / Checks:

Validate cross-system identifiers, correct data mapping, and permissions so sensitive data is
exposed only to authorized users.

---

73. What is the difference between Data and Metadata?

Interview answer:
Data = actual records (Patients, Appointments). Metadata = configuration (objects, fields,
flows, layouts). Metadata defines structure & behavior; data is the runtime content.

Health Cloud example:

Patient__c records are data. Patient__c object definition, fields, validation rules are
metadata.

Test steps / Checks:

Tests should separate data migration verification from metadata deployment checks.

---

74. What is a Queue in Salesforce?

Interview answer:
A queue is a holding place for records that multiple users can claim (e.g., Cases, Leads,
custom objects). Useful for work routing and shared ownership.

Health Cloud example:

A Utilization_Management_Case lands in a UM_Case_Queue for nurses to pick up.

Test steps / Checks:

Test queue entry rules, assignment rules, and claim/unclaim workflows.

---

75. Can you explain how Salesforce releases work?

Interview answer:
Salesforce publishes release notes and upgrades orgs three times per year
(Spring/Summer/Winter). Sandboxes are upgraded earlier in preview windows; admins must
test orgs for breaking changes and new features in sandbox before production rollout.

Health Cloud example:

Before a Winter release that updates FHIR connectors, plan regression tests for EHR
integrations and patient-facing components.

Test steps / Checks:

Identify release-impact areas from release notes, run targeted regression suites on
sandboxes in preview, and schedule fixes before production upgrade.

---

76. Can you describe the differences between declarative and programmatic
customizations? (with Health Cloud examples)

Interview answer:
Declarative = clicks (Flows, Validation Rules, Process Builder, Page Layouts). Programmatic
= code (Apex, LWC, Batch Apex, REST endpoints). Declarative is faster for admins and
easier to maintain; programmatic required for complex logic, heavy processing, or
integrations.

Health Cloud examples:

Declarative: Flow that auto-assigns Care Team members based on patient zip code.

Programmatic: Batch Apex that calculates risk scores across millions of encounter records
and integrates with analytics.

Test steps / Checks:

Test admin-editable flows for maintainability; for programmatic changes, perform unit tests,
bulk tests, and monitoring/alerts.

---

77. What are the key dates you need to be aware of with every Salesforce release?

Interview answer:
Important dates: Release Notes publication; Sandbox Preview windows (when sandboxes
are upgraded); Production upgrade dates (release weekend); and deprecation deadlines for
retiring features.

Health Cloud example:

If release notes show changes to Health Cloud managed package APIs, plan integration
testing during sandbox preview and schedule fixes before production upgrade.

Test steps / Checks:

Subscribe to release notes, identify impacted metadata and integrations, run

smoke/regression tests during sandbox preview.

---

78. What is the “Person Accounts” feature, and how can it help organizations?

Interview answer:
Person Accounts combine Account + Contact into a single record for individual consumers,
useful for B2C use-cases where individual persons are the primary entity.

Health Cloud example:

For clinics treating individual patients (not corporate accounts), Person Accounts simplify
patient records and reduce object linking.

Test steps / Checks:

Test behavior for Person Account creation, contact mapping, merges, and integration with
EHR systems expecting Contact or Account schemas.

---
79. What is the difference between Lightning Components and Lightning Web Components
(LWC)?

Interview answer:
Aura Components (Lightning Components) are the older framework using custom
component lifecycle. LWC uses modern web standards (native DOM, ES6), is more
performant, smaller bundle size, and preferred for new development.

Health Cloud example:

Rewrite an Aura Care Timeline to LWC to improve loading speed and reduce client-side
latency.

Test steps / Checks:

Test LWC rendering, event handling, and compatibility with Lightning Data Service; compare
performance vs older Aura components.

---

80. When should Flow be used over Apex?

Interview answer:
Use Flow when the logic can be implemented declaratively (screen flows, simple
cross-object updates, before-save flows) and needs admin maintenance. Use Apex when
you need complex logic, heavy bulk processing, external callouts, or fine-grained
performance control.

Health Cloud example:

Flow: Screen Flow for patient intake forms and immediate record creation.
Apex: Batch Apex to compute risk scores across millions of historical encounters nightly.

Test steps / Checks:

For Flows: test versions, exception handling, and reusability (subflows).

For Apex: unit tests with bulk scenarios and mocks for external callouts.

—
---

81. What is an Apex Trigger?

A (Interview): Apex Trigger is server-side Apex code that runs before or after DML events
(insert/update/delete/undelete) on sObjects to implement custom logic.
B (Health Cloud): A before insert trigger on PatientEncounter__c validates vitals and sets a
default EncounterStatus__c. An after insert trigger publishes a Platform Event to the
monitoring system.
C (Tests): Unit tests for each trigger event, include @isTest methods, bulk tests (200
records), verify no SOQL/DML in loops, and inspect debug logs for correct order.
---

82. What is MuleSoft?

A: MuleSoft (Anypoint) is an integration platform for connecting apps, data, and devices via
APIs, often used to integrate enterprise systems with Salesforce.
B (Health Cloud): MuleSoft transforms FHIR/HL7 from the hospital EHR into Salesforce
Patient__c records and handles secure token auth.
C (Tests): Contract tests (Postman), validate OAuth token lifecycles, payload mapping tests,
simulate downtime & retry logic, and end-to-end reconciliation.

---

83. What is the Salesforce Order of Execution?

A: A predefined sequence of validations, triggers, automation (flows/workflows), and commit

steps executed on record save — important for design and debugging.
B (Health Cloud): A before-save Flow sets CareLevel__c, a trigger recalculates risk, and a
workflow sends a notification — knowing order avoids unexpected overwrites.
C (Tests): Use debug logs to verify sequence; create scenarios where workflow field updates
would re-enter triggers and assert final values.

---

84. Describe different ways to make a field required in Salesforce

A: Field definition (schema required), Page Layout required, Validation Rule (conditional),
Record Type + Page Layout, Flow/LWC UI enforcement.
B (Health Cloud): ConsentSigned__c required via Validation Rule for surgical procedures
record type.
C (Tests): Test UI create/update, API upsert, Data Loader imports — validation behaves
consistently; test exception messaging and error localization.

---

85. Describe a few ways Account and Contact information can be imported into Salesforce

A: Data Import Wizard (small), Data Loader (large), [Link], Bulk API, ETL tools
(MuleSoft/Informatica), or third-party connectors.
B (Health Cloud): Nightly bulk of provider directory via Bulk API; manual CRM uploads by
admin using Data Loader for one-off fixes.
C (Tests): Test mapping, dedupe (matching rules), referential integrity (Account ↔ Contact),
and error handling of bad rows.

---

86. Differences between Lightning Pages, Page Layouts, and Record Types

A: Lightning Page = component arrangement (App Builder). Page Layout = field

ordering/sections/related lists. Record Type = business process/picklist variants + page
layout assignment.
B (Health Cloud): Inpatient record type shows inpatient fields/layout; Lightning Page contains
Vitals LWC and CareTeam components.
C (Tests): Verify correct Lightning Page variant and Page Layout per record type/profile; test
mobile and console views.

---

87. Differences between Roles, Profiles, and Permission Sets

A: Role = record visibility (hierarchy). Profile = baseline permissions (one per user).
Permission Sets = additive permissions assignable to users (many allowed).
B (Health Cloud): Care Coordinator profile grants edit rights; Permission Set TelehealthUser
grants video session access; Role Care Manager sees team patients.
C (Tests): Use Login As to validate view/action differences; verify permission sets don’t
inadvertently give record-level access.

---

88. What is Salesforce Customer 360?

A: A unified identity layer that links customer data across Salesforce apps to create a single
view of the customer.
B (Health Cloud): Patient 360 aggregates clinical notes, claims, appointments, and outreach
history for clinicians.
C (Tests): Validate identity mapping, dedupe logic, PII protections, and correct merging rules
across systems.

---

89. Difference between Data and Metadata

A: Data = runtime records (Patients, Claims). Metadata = configuration (objects, fields,

flows). Metadata controls application behavior.
B (Health Cloud): Patient__c records (data); Patient__c object, validation rules, and flows
(metadata).
C (Tests): Test metadata deployments separately from data migrations; use change sets/CI
to validate metadata migration.

---

90. What is a Queue in Salesforce?

A: A queue is an ownership pool for records (e.g., Cases, Leads, custom objects); users can
claim records from the queue.
B (Health Cloud): UM_Case_Queue holds utilization management cases for nurses to claim.
C (Tests): Test queue assignment rules, auto-assignment, claim/unclaim flows and
notifications.

---
91. How do Salesforce releases work?

A: Salesforce pushes 3 major releases yearly; sandboxes preview first; admins should test in
preview sandboxes and manage deprecations.
B (Health Cloud): New Health Cloud connector updates may change API behavior — test
EHR integration in preview sandbox.
C (Tests): Review release notes, run smoke/regression on preview sandboxes, document
issues and apply fixes before production upgrade.

---

92. Declarative vs Programmatic customizations (recap with depth)

A: Declarative = no code (Flows, Validation), Programmatic = code (Apex, LWC). Declarative

is faster to change but may not handle heavy logic or complex integrations.
B (Health Cloud): Use declarative Flow to auto-assign care teams; use Apex Batch for
nightly analytics of millions of encounters.
C (Tests): Validate Flow exception handling and admin changes; for Apex, unit/bulk tests and
performance tests are mandatory.

---

93. Key Salesforce release dates to track

A: Release Notes publication, Sandbox Preview schedule, Production upgrade weekend,

deprecation/retirement announcements.
B (Health Cloud): Plan EHR and package testing around Sandbox Preview and Production
dates.
C (Tests): Construct a release test plan and schedule for preview windows, with rollback
criteria and hotfix procedures.

---

94. What is Person Accounts and benefits?

A: Person Accounts combine Account+Contact for individuals (B2C). Simplifies data model
where the individual is primary.
B (Health Cloud): Use Person Accounts for individual patients without household entities.
C (Tests): Test creation, mapping to EHR, data merges, reporting, and special handling for
APIs that expect separate Account/Contact objects.

---

95. Lightning Components vs Lightning Web Components (LWC) — detailed differences

A: LWC uses modern web standards and is faster; Aura is older and more framework-heavy.
LWC is recommended for new development.
B (Health Cloud): Replacing Aura CareTimeline with LWC improved render performance and
reduced event overhead.
C (Tests): Compare performance metrics (TTFB, render time), test events, accessibility, and
LWC compatibility with Lightning Data Service.
---

96. When should Flow be used over Apex? (decision guide)

A: Use Flow for admin-maintainable logic, screen interactions, before-save updates, and
scheduled automation where complexity is moderate. Use Apex for heavy computation,
complex transactions, callouts, or when existing limits require code.
B (Health Cloud): Use Flow for interactive patient intake; use Apex Batch to process
historical claims for analytics.
C (Tests): Test Flow error/fallback handling, versioning, and test that Apex covers bulk and
edge cases not feasible in Flow.

---

97. What is an approval process? (detailed)

A: A declarative multi-step approval workflow with entry criteria, approver steps, record
locking, email alerts, and post-approval actions.
B (Health Cloud): TreatmentAuthorization__c needs clinician, manager, and payer approvals
before scheduling procedures.
C (Tests): Test approver substitution, recall, rejection, notification templates, and ensure
downstream actions (scheduling, billing) only occur after final approval.

---

98. What is WhoId and WhatId in activities? (deep)

A: WhoId references person objects (Contact/Lead); WhatId references non-person records

(Account, Case, Opportunity, or custom).
B (Health Cloud): A visit Event: WhoId points to the patient contact; WhatId to the CarePlan
or Episode record.
C (Tests): Create tasks/events with various combinations; merge related records and check
activity history integrity.

---

99. What is a bucket field in reports? (advanced)

A: Report UI field for grouping values into buckets without changing schema. Useful for
ad-hoc grouping.
B (Health Cloud): Bucket ages into Pediatric/Adult/Senior for quick charts.
C (Tests): Check boundaries, default/unassigned bucket behavior, sorting, and dashboard
compatibility.

---

100. Can you have a roll-up summary field in Master-Detail? (clarify)

A: Yes — roll-up summaries exist on the master record aggregating detail children (COUNT,
SUM, MIN, MAX).
B (Health Cloud): CarePlan__c.Total_Goals__c = COUNT(CarePlanGoals__c).
C (Tests): Test child create/update/delete scenarios, verify bulk behavior, and ensure roll-up
recalculation triggers downstream automations correctly.

---

101. Which fields are automatically indexed in Salesforce? (practical list)

A: Indexed fields typically include Id, OwnerId, lookup/master-detail fields, CreatedDate,

SystemModstamp, RecordTypeId, and any field marked Unique or External ID (automatically
indexed). Some standard fields (Email, Name) have indexes on certain objects.
B (Health Cloud): Mark External_MRN__c as External ID to speed up upserts.
C (Tests): Use explain plan or query performance tests; request custom index if queries are
not selective.

---

102. For which workflow criteria time-dependent actions cannot be created? (clarify)

A: Time-dependent workflow actions cannot be used with evaluation criteria “created, and
every time it’s edited”. Use other criteria that support time-based scheduling.
B (Health Cloud): Scheduling a follow-up reminder 48 hours after creation requires “created”
or “created, and any time it’s edited to subsequently meet criteria”.
C (Tests): Test that scheduling is not created on every edit and confirm expected scheduled
jobs appear in “Time-Based Workflow” queue.

---

103. What are the types of custom settings and advantages? (recap)

A: Hierarchy (org/profile/user overrides) and List (global list). Advantages: cached, fast reads
without SOQL; useful for configuration. For packageable config, prefer Custom Metadata
Types.
B (Health Cloud): DefaultCareTeam__c as Hierarchy setting to set default care team per
clinic.
C (Tests): Test per-profile overrides, refresh behavior, and cache invalidation scenarios.

---

104. Why write test classes; how to identify them?

A: Tests validate logic, ensure deployment eligibility (75% org coverage), and prevent
regressions. Test classes are annotated @isTest or use testMethod.
B (Health Cloud): Test triggers for CarePlan changes including bulk scenarios and callout
mocks to EHR.
C (Tests): Ensure tests include positive, negative, and bulk cases; use @testSetup for
common data; assert expected outcomes.
---

105. Minimum test coverage required to deploy a trigger? (short)

A: 75% org-wide Apex coverage is required to deploy code to production. Individual triggers
should be covered as part of that.
B (Health Cloud): Triggers on patient objects must be covered for both single and bulk
operations.
C (Tests): Create robust test classes with assertions, avoid fragile tests, and include
negative scenarios.

---

106. What is an External ID? Which field types support it? (recap)

A: External ID is a marker on a field used for matching/upsert from external systems;

supported types: Text, Number, Email, Auto-Number. Field becomes indexed.
B (Health Cloud): Use MRN__c as External ID for EHR upserts.
C (Tests): Upsert tests using External ID; handle duplicate External ID conflicts.

---

107. Causes of data loss and Recycle Bin retention (practical)

A: Causes: accidental/hard deletes, faulty ETL, field deletions, integration bugs, storage
limits. Recycle Bin retention ~15 days (may vary). Hard delete bypasses Recycle Bin.
B (Health Cloud): A bad nightly job hard-deletes merged patient duplicates.
C (Tests): Ensure backup/restore processes exist, test restores from backup and detect data
corruption early.

---

108. How is a record shared in Salesforce? (full list)

A: OWD, Role Hierarchy, Sharing Rules, Manual Sharing, Account/Case Teams, Queues,
Apex sharing, Public Groups. Permission Sets affect capabilities, not record sharing.
B (Health Cloud): Share Authorization__c using criteria-based sharing to the Billing Team.
C (Tests): Validate visibility for users across roles, ensure sharing rules don’t overexpose
data, and test Apex sharing logic for batch processes.

---

109. Approach to testing complex Salesforce integration (restated)

A: Understand contract, mock endpoints, simulate edge cases, performance/load tests,

verify idempotency, error handling, and reconciliation. Test security and PII handling.
B (Health Cloud): Bi-directional sync with EHR requires careful transformation and audit
logging.
C (Tests): End-to-end reconciliation, schema validation, message queue tests, monitor
message failures and retries.
---

110. Concept of Bulkification in Apex and QA importance (recap)

A: Bulkification = handling many records in one transaction efficiently (avoid SOQL/DML in

loops). Essential to prevent governor limit exceptions.
B (Health Cloud): Bulk import of 10,000 claims needs triggers that operate on collections and
use maps for lookups.
C (Tests): Create unit tests inserting/updating 200+ records to verify bulk behavior.

---

111. How to test Lightning Components (recap with methods)

A: Unit testing (Jest for LWC), Apex tests for server, UI automation (Selenium/Cypress),
manual exploratory tests. Use robust selectors.
B (Health Cloud): Test PatientIntakeLWC for field validation, file attachments, and server
error handling.
C (Tests): Validate lifecycle, event wiring, navigation, and accessibility.

---

112. Strategies to optimize reports & dashboards performance (recap)

A: Use selective/indexed filters, summary reports, pre-aggregate via roll-ups, limit

components on dashboards, and avoid cross-object filters that make reports non-selective.
B (Health Cloud): Use roll-ups for HighRiskPatientCount__c rather than computing on the fly
for dashboards.
C (Tests): Test report run times with production-scale data and ensure SLA compliance.

---

113. Approach to testing Salesforce CPQ implementations (recap)

A: Validate product bundles, pricing rules, discounting, approvals, quote/PDF generation,

and integration with Orders/Opportunity. Performance for big catalogs is critical.
B (Health Cloud): CarePackage bundles with complex discount rules for insurers must
generate correct quote PDFs.
C (Tests): Run scenario matrices, approval flows, and stress tests for quotes with many line
items.

---

114. Steps in Salesforce Testing Lifecycle (recap)

A: Impact analysis → strategy & plan → env/data setup → test case design → automation →
execution → regression & UAT → pre-deploy validation → production smoke checks →
retrospective.
B (Health Cloud): Include PHI handling and EHR interface validation.
C (Tests): Maintain traceability matrix and automated CI job for regression.
---

115. How many events do we have in Aura components? (recap)

A: Three event types: Component, Application, System.

B (Health Cloud): Use Application Event CareTeamUpdated for broadcast updates.
C (Tests): Validate both local and global event handling, and check for redundant refreshes.

---

116. What is an approval process? (recap)

A: Declarative multi-stage approval with locking, notifications, and post-approval actions.

B (Health Cloud): ProcedureAuthorization__c approval chain for high-cost treatments.
C (Tests): Test happy/rejection paths, delegate approver, email content, and post-approval
automation.

---

117. What is WhoId and WhatId in activities? (repeat)

A: WhoId → Contact/Lead; WhatId → non-person objects.

B (Health Cloud): Task WhoId = Patient contact; WhatId = Care Plan.
C (Tests): Validate lookups and behavior when related records merge/delete.

---

118. What is a bucket field in reports? (repeat)

A: On-the-fly grouping in report UI.

B (Health Cloud): Bucket AppointmentWait into time ranges.
C (Tests): Validate bucket groupings across filters and dashboards.

---

119. Can you have a roll up summary field in case of Master-Detail relationship? (repeat)

A: Yes — parent can roll up child aggregates.

B (Health Cloud): CarePlan.TotalCompletedGoals__c =
SUM(CarePlanGoals.IsCompleted__c).
C (Tests): Test child changes and ensure parent roll-up updates propagate.

---

120. Which fields are automatically indexed in Salesforce? (repeat)

A: Id, OwnerId, lookup/master-detail, CreatedDate, SystemModstamp, RecordTypeId,

Unique/External ID fields, and some standard fields depending on object.
B (Health Cloud): Index External_MRN__c for fast EHR upserts.
C (Tests): Run performance tests and consult Salesforce Support for custom index requests
when queries are not selective.

---
---

✅ 121. What is a Recursive Trigger? How do you prevent it?

Interview Answer:

A recursive trigger occurs when a trigger updates a record in such a way that the same
trigger fires again, causing infinite loops or governor limit failures.
Prevent using:

Static variables in handler classes

Before updating, compare old vs new values

One-time flags in Trigger Handler frameworks

Health Cloud Example:

A CarePlanGoal__c trigger updates the parent CarePlan__c.

But the parent CarePlan trigger also updates its child goals → unintended loop.

Testing Steps:

Insert/update 200 records and ensure trigger fires once.

Use debug logs to verify guard (if(![Link])).

Confirm old/new value checks prevent unnecessary updates.

---

✅ 122. What is an Approval Process in Salesforce?

Interview Answer:

A multi-step workflow that routes a record to approvers based on business rules. Includes:

Entry criteria

Multiple approver steps

Record locking

Email alerts

Post-approval/rejection actions
Health Cloud Example:

TreatmentAuthorization__c goes through:

1. Nurse approval

2. Care Manager

3. Insurance Payer rep

Only after final approval → procedure can be scheduled.

Testing Steps:

Validate entry criteria using various record types.

Test rejection, recall, and re-submission flows.

Validate email templates + locking during approval.

Validate final action triggers only after last step.

---

✅ 123. What is a Dynamic Dashboard?

Interview Answer:

A dashboard that runs in the logged-in user's security context, showing only the data that
user has access to.
Cannot be scheduled.

Health Cloud Example:

“My Patients Dashboard” → each Care Coordinator sees only their assigned patients, care
gaps, and tasks.

Testing Steps:

Use Login As Care Coordinator, Nurse, and Manager → verify different data views.

Validate dashboard filters.

Confirm no scheduling option.

---

✅ 124. How many records can appear on a report view?

Interview Answer:

UI supports viewing up to 2,000 rows.

Exports can include more.

Health Cloud Example:

A Patient Census report with 5,200 records will require exporting to Excel/CSV.

Testing Steps:

Validate pagination and filter logic.

Test export consistency.

Verify large reports load efficiently.

---

✅ 125. Can we create a Formula Field inside a Report?

Interview Answer:

Yes — Row-Level and Summary Formulas can be created inside the report builder
(Lightning).
But not saved to metadata.

Health Cloud Example:

% Care Plan Completion = CompletedGoals / TotalGoals.

Testing Steps:

Validate formula calculations across sample data.

Check divide-by-zero.

Test chart render.

---

✅ 126. What Reports can be used for Dashboards?

Interview Answer:

Dashboards support:
Summary Reports

Matrix Reports

Tabular (only if row limit or chart applied)

Joined Reports (for some components)

Health Cloud Example:

Summary report grouped by Care Team used to generate bar chart “Open Care Gaps by
Team.”

Testing Steps:

Validate grouping and summary fields.

Ensure dashboard refresh and security visibility.

---

✅ 127. What is Lightning App Builder? Where can Lightning Components be used?
Interview Answer:

Lightning App Builder allows creating pages (Home, Record, App pages) using
drag-and-drop components (Aura, LWC).
Components can be used on:

Record Pages

App Pages

Home Pages

Community/Experience pages

Health Cloud Example:

Custom VitalsHistoryLWC added to Patient 360 page.

Testing Steps:

Validate component visibility filters.

Test desktop vs mobile layout.

Test component interactions and refresh events.

---

✅ 128. Difference Between Permission Sets and Sharing Rules

Interview Answer:

Permission Sets → grant object/field permissions (what user can DO).

Sharing Rules → grant record-level visibility (what user can SEE).

Health Cloud Example:

Permission Set: Edit Clinical Notes

Sharing Rule: Billing Team gets read-only access to Authorizations.

Testing Steps:

Verify entity-level CRUD by profile/PS.

Validate record visibility from hierarchy/sharing rules.

Confirm no unintended elevated access.

---

✅ 129. Types of Relationships (MD, Lookup, Many-to-Many, Self, External)

Interview Answer (Short):

Master-Detail: Parent controls detail, cascade delete, roll-ups.

Lookup: Loose, independent sharing, optional.

Many-to-Many: Created via junction object.

Self Relationship: Same object.

External Lookup: Relates to External Object.

Health Cloud Example:

MD: CarePlan → CareGoal

Lookup: Encounter → Provider

Many-to-Many: Provider ↔ Program via Junction

Self: CarePlan linked to Parent CarePlan

External: FHIR external Patient object → Salesforce Patient

Testing Steps:

Validate deletes (cascade vs null).

Test roll-up recalculation.

Validate record visibility from parent/child.

---

✅ 130. What is a Standard Profile? Name Some

Interview Answer:

A standard profile is a Salesforce-delivered baseline profile that cannot be deleted.

Examples:

System Administrator

Standard User

Read Only

Marketing User

Contract Manager

Solution Manager

Health Cloud Example:

System Admin customizes Health Cloud package settings; Standard User gets limited
Patient access.

Testing Steps:

Validate default CRUD.

Add permission sets on top for custom apps.

---

✅ 131. What are Sandboxes? Types?

Interview Answer:

A sandbox is a replica of your Production org for dev/testing.

Types:
Developer (200 MB)

Developer Pro (1 GB)

Partial Copy (5 GB + templates)

Full (entire production; 28-day refresh)

Health Cloud Example:

Full sandbox used for full EHR integration testing with real-size patient data.

Testing Steps:

Validate data templates.

Test integrations with mock endpoints first.

Confirm metadata consistency.

---

✅ 132. Difference Between Profile and Role? Can a User Have Two Profiles?
Interview Answer:

Profile controls user permissions (one per user).

Role controls record visibility in hierarchy.

Users cannot have two profiles. Use Permission Sets instead.

Health Cloud Example:

Profile = Care Coordinator

Role = City → Region → State
Managers see subordinates’ patients.

Testing Steps:

Test CRUD with different profiles.

Test data visibility across roles.

---

✅ 133. Testing a Workflow Rule — How to validate?

Interview Answer:

Create records matching criteria

Validate actions (email, task, update)

Check time-based queue (if applicable)

Inspect debug logs

Test edit scenarios

Health Cloud Example:

When FollowUpRequired__c = TRUE, workflow creates a follow-up Task for the assigned
nurse.

Testing Steps:

Validate task assignment and due date.

Validate workflow fires only once.

---

✅ 134. Steps to Ensure Field-Level Security is Correct

Interview Answer:

Check FLS in Profile & Permission Sets

Verify Page Layout access

Check Lightning Page conditional visibility

Test via Login-As

Verify via API (SOQL) visibility

Health Cloud Example:

ClinicalNotes not visible to Billing users.

Testing Steps:

Try create/edit with restricted user.

Query field via API with low-privilege user.

---

✅ 135. User Cannot See a Field — How Do You Troubleshoot?

Interview Answer:

Check:

FLS

Page Layout

Record Type assignment

Lightning Page component visibility rules

Profile tab & app access

“Login As” test

Health Cloud Example:

Nurse cannot view Allergies — layout missing for Inpatient record type.

Testing Steps:

Test across profiles.

Validate correct record type layouts.

Validate mobile vs desktop.

---

✅ 136. Testing a Newly Added Custom Field

Interview Answer:

Check:

FLS

Page Layout

Default values

Required rules

Validations

API name added to flows, triggers

Reports/filters

Health Cloud Example:

New RiskScore__c impacts Care Plan assignment logic.

Testing Steps:

Test APIs (upserts).

Validate existing automations.

Test reports & dashboards.

---

✅ 137. Explain Impact of Governor Limits on Testing

Interview Answer:

Design tests to cover:

Bulk scenarios

Trigger recursion

SOQL/DML in loops

Stress transactions

Async apex behavior

Help ensure solutions scale.

Health Cloud Example:

Bulk update of 10,000 Encounters for annual audit.

Testing Steps:

Insert/update 200 records in single transaction.

Review logs for SOQL/DML limits.

---

✅ 138. Walk Through a Salesforce Approval Process You've Tested

Interview Answer:
Describe:

Entry criteria

Approver assignment

Record locking

Email alert

Escalation

Post-approval logic

Health Cloud Example:

High-cost treatment needs 3 approvals: Nurse → Manager → Insurance.

Testing Steps:

Test alternate approvers.

Validate locked fields.

Validate final automation.

---

✅ 139. How Do You Do Exploratory Testing? Give Example

Interview Answer:

Use role-based accounts, navigate like user, break flows intentionally, test edge cases, try
unexpected data.

Health Cloud Real Scenario:

Found a bug where Lead → Patient conversion overwrote existing Contact phone numbers
due to an old Process Builder.

Testing Steps:

Reproduce conversion across profiles.

Validate logging.

Convert PB to Flow.

---
✅ 140. Approach for Regression Testing in Salesforce
Interview Answer:

Identify impacted metadata

Refresh regression suite

Test workflows, flows, triggers

Test integrations

Run automation scripts

Test UAT

Ensure rollback plan

Health Cloud Example:

New clinical workflows + Flows + triggers all updated → run 500+ regression tests for patient
lifecycle.

Testing Steps:

Smoke test after deployment.

Run full suite in Full Sandbox.

Validate negative scenarios.

---

✅ 141. Difference Between Lightning & Classic in Testing

Interview Answer:

Lightning is component-driven with dynamic UI, async rendering, and responsive UI; Classic
is static page reloads.

Health Cloud Example:

Patient 360 Lightning components (LWC) dynamically hide/show sections like allergies and
vitals.

Testing Steps:

Test responsive behavior.

Validate dynamic visibility.

Test performance (client-side).

Test mobile app differences.

✅ 🔥 Salesforce TEST LEAD – Full Missing Concepts Pack (Advanced Level 50+
Questions)

(All answers include real-time Health Cloud examples and how a Test Lead should validate
them)

---

⭐ SECTION 1 — End-to-End Testing Concepts (Missing Earlier)

---

1. What is End-to-End (E2E) testing in Salesforce? How is it different from Functional

testing?

Answer (Interview-ready):

E2E testing validates an entire business workflow across Salesforce + external systems +
integrations + user roles.
Functional testing validates only the feature/flow inside Salesforce.

Health Cloud Example:

E2E: Patient Referral → Eligibility Check (API) → Authorization Creation → Care Plan →
Appointment Scheduling → Claim Submission (ERP).
Functional: Testing only the “Create Authorization” screen.

What a Test Lead Should Validate:

Cross-system mappings

Correct events triggered (Platform Events/Mulesoft)

Roles and permissions across E2E

Data reconciliation after sync

Failure and retry behavior in integrations

---

2. How do you design an E2E test plan in Salesforce for a multi-cloud environment?

Answer:

Steps:
1. Understand business workflow

2. Map all touchpoints (Sales Cloud → Health Cloud → Mulesoft → EHR)

3. Identify owners per system

4. Determine test data needs

5. Plan environment readiness (Full sandbox preferred)

6. Validate security, roles, profiles

7. Validate integrations

8. Execute E2E cycles in parallel with sprint testing

9. Track defects + root cause

10. Prepare a regression bucket

---

⭐ SECTION 2 — Integration, APIs, MuleSoft, Platform Events

---

3. How do you test real-time integrations using Platform Events?

Answer:

Testing platform events requires validating:

Event publishing

Event subscription

Replay ID behavior

Duplicate event handling

Error logging for failed subscriber actions

Example:

A “PatientConsentUpdated__e” event triggers external systems to update compliance

records.

Test Lead Validation:

Publish event manually using Workbench

Validate subscriber logs in Mulesoft

Validate replay IDs (before, new, replay missing)

Validate consumer retries

---

4. How do you test asynchronous integration failures?

Answer:

Simulate failures such as:

Timeout

400/500 error responses

Invalid payload

Network disruption

Authentication token expiration

Health Cloud Example:

Authorization update fails due to EHR downtime → Flow/Apex should requeue or alert
admin.

Test Steps:

Use mock servers to simulate failures

Verify Retry logic (queueable/batch)

Verify Platform Event DLQ (dead letter queue)

---
5. What are the risks in integration testing and how do you mitigate them?

Answer:

Risks: data corruption, improper mapping, sync mismatches, stale data, duplicate creation.
Mitigation:

Validate mapping sheets

Use test integration users

Perform controlled bulk tests

Maintain rollback strategy

Monitor logs

---

⭐ SECTION 3 — Flows, Workflow, Automation – Hard Testing Scenarios

---

6. How do you test a complex Salesforce Flow?

Answer:

Validate:

Entry conditions

Decision branches

Screen UI validations

Subflow behavior

Fault paths

Governor limits for Flow loops

Versioning

Example:

A Patient Intake Flow assigns care team, creates care plan, launches a screen component.

Test Lead Steps:

Test incorrect input

Test decision paths

Test bulk updates (record-triggered)

Test rollback behavior

---

7. How do you test a before-save vs after-save Flow?

Before-save Flow:

No DML allowed

Should be faster

Test field updates only

After-save Flow:

Can trigger actions

Test updates, callouts, related record creation

Example:

Before-save: Normalize patient phone numbers.

After-save: Create default Care Plan tasks.

---

8. What are common Flow issues a Test Lead should watch?

Infinite loops

Conflicts between Flows & PB/Triggers

Wrong variable scope

Missing Null checks

Version not activated

Fault connectors not configured

Incorrect access for running user

---
⭐ SECTION 4 — Data Migration Testing & Validation
---

9. How do you test Salesforce data migration?

Answer:

Check:

Data volume

Mappings

Transformations

Parent-child relationships

Upsert with External IDs

Duplicate rules

Validation rule impact

Example:

Migrating 500K patient records + 2M encounters from EHR.

Test Lead Steps:

Record counts match source

Field-by-field comparison (spot checks + automation)

Referential integrity across objects

Batch size handling

Roll-up recalculation

---

10. What are the biggest data migration risks?

Missing parent references

Data truncation

Wrong picklist mappings

Skipped validation due to bypass rules

Duplicates

Wrong time zone

---

⭐ SECTION 5 — Security Testing (BIG Missing Area)

---

11. How do you test FLS, CRUD, and Sharing end-to-end?

Answer:

Test across:

Profiles

Permission Sets

Record Types

Sharing Rules

Role hierarchy

Manual sharing

Apex sharing

Example:

Clinical Notes should be visible only to Doctors, not Billing.

Test Steps:

Login-As

Validate API access via tooling

Validate report visibility

Validate mobile access

---

12. What are key Salesforce security validations for a Test Lead?
OWD validation

Role hierarchy checks

Sharing rule execution

Team access

External user access (communities)

API user profile

Field audit

Encryption (Shield) checks

Session timeout

Login IP restrictions

---

⭐ SECTION 6 — EHR / Health Cloud Specific Scenarios (Highly Valuable)

---

13. How do you test Health Cloud Patient 360?

Answer:

Validate:

Provider-Patient Relationships

Care Plan automation

Timeline components

Health Timeline Grouping

Clinical Data (Vitals, Allergies, Medications)

Care Team assignments

FHIR data sync

Filter logic

---
14. How do you test referrals and care plans end-to-end?

Flow:

Referral → Triage → Create Authorization → Assign Care Plan → Assign Goals →

Appointments → Claims

Test Steps:

Validate every transition

Validate role-based access

Validate LWC/FHIR data components

Validate audit trail

Validate HL7/FHIR message sync

---

15. How do you test eligibility and claims integration?

Answer:

Eligibility check involves real-time API → Mulesoft → Payer system.

Test:

Success scenario

Failure scenario

Payer downtime

Partial response

Invalid payload

Policy expired

---

⭐ SECTION 7 — Test Lead Responsibilities (Advanced)

---

16. How do you create a regression suite for Salesforce?

Answer:
Include:

Core E2E processes

Triggers/Flows

Security tests

Integration endpoints

UI layouts

Reports/Dashboards

Batch jobs

Scheduling

Lightning page behavior

---

17. How do you plan testing for a large Salesforce release?

Answer:

1. Identify impacted metadata

2. Review release notes

3. Identify automation conflicts

4. Smoke test all impacted areas

5. Prepare sandbox preview testing

6. Identify high-risk integrations

7. Coordinate with external teams

---

18. How do you test Batch Apex & Scheduled Jobs?

Answer:

Validate:

Batch chunk size

Retry behavior

Email logs

Partial failure scenarios

Cron expression correctness

Example:

Nightly job recalculates risk scores for 1M+ encounter records.

---

⭐ SECTION 8 — Real Production Issues (Ask in Senior Interviews)

---

19. Production defect: Workflow/Flow running twice — how do you debug?

Answer:

1. Check Order of Execution

2. Check duplicate Flows/Process Builders

3. Check Workflow field update causing re-trigger

4. Check duplicate triggers

5. Check integration overwrites

---

20. Production issue: Users unable to edit a record — how do you approach it?

Root Causes Could Be:

Record locking (approval process active)

Field-level security

Validation rule

Record type mismatch

Apex error suppressed

Test Lead Troubleshooting:

Login As

Debug logs

Apex exception logs

Check OWD sharing

---

21. Data mismatch between Salesforce & EHR — how do you troubleshoot?

Steps:

1. Identify source of truth

2. Check integration mapping

3. Check Mulesoft logs

4. Check Platform Event failures

5. Check field updates/overwrites

6. Check dedupe logic

7. Check manual edits

---

⭐ SECTION 9 — Performance Testing

---

22. How do you test Salesforce Lightning performance?

Answer:

Measure component load time

Test large datasets

Validate SOQL limits

Validate caching behavior

Simulate poor network

Example:

Patient Timeline component loads 300+ records → must be optimized with pagination.

---

23. How do you test report performance?

Use selective filters

Test with full data volumes

Measure report generation time

Validate dashboard refresh performance

---

⭐ SECTION 10 — UAT, SIT, Cutover & Deployment Testing

---

24. What is the difference between SIT and UAT in Salesforce?

SIT:

Technical validation

Integration + System alignment

APIs, flows, triggers

Performed by QA

UAT:

Business validation

Workflows, approvals

Performed by business users

---

25. What testing do you perform on deployment day?

Sanity testing

Data migration spot checks

Integration connectivity check

High priority business flows

Access & permissions

Email alerts

Batch job schedule verification

---

⭐ SECTION 11 — Test Lead Scenario Questions (High Weightage)

---

26. Tell me a scenario where a Flow, Trigger, and Integration caused a conflict. How did you
solve it?

Answer (STAR Method):

Flow updated a field

Trigger fired and updated a related object

Integration then overwrote that field

→ resulted in wrong risk score.

Fix:
Add field-change conditions

Move logic from Trigger to Flow (best practice)

Add integration overwrite protection (skip logic)

Add audit log for external updates

---

27. A defect appears only in production but not in sandbox — what do you do?

Root Causes:

Missing data conditions

Different org settings

Caching

Duplicate Flows

Incorrect permission sets

Incorrect deployment versions

Actions:

Compare metadata

Check deployment logs

Check debug logs in prod (with user trace flag)

---

⭐ SECTION 12 — Missing Report/Dashboard Testing Concepts

---

28. How do you test a dashboard with dynamic filters?

Steps:

Validate filter combinations

Validate role-based data

Validate dynamic dashboard controls

Validate component drill-down accuracy

---

⭐ SECTION 13 — Scenario-Based Questions (Strong Additions)

h ji

---

29. A payer integration sends wrong claim status codes — how do you test and escalate it?

Answer:

Capture incorrect payload

Compare with mapping sheet

Coordinate with Mulesoft team

Validate reprocessing

Validate downstream UI updates

---

30. Appointment scheduling system shows wrong provider availability — what do you
check?

Checks:

Provider lookup

Calendar sync

Timezone

Apex scheduling logic

EHR availability data

Batch delays

---

---

✅ SECTION 1 — Salesforce Testing (Core Concepts)

Q1. What are the key components you validate in a Salesforce application?

Interview Answer:

As a Salesforce Test Lead, I validate both standard and custom Salesforce components to
ensure the entire business process works end-to-end. Key areas include:

1. Functional Components

Standard & Custom Objects

Fields, Page Layouts, Record Types

Lightning Pages, Flexi pages

2. Business Automation

Validation Rules

Workflows

Process Builders

Record-triggered Flows (before/after save)

Scheduled and Autolaunched Flows

3. Custom Development

Apex Classes

Apex Triggers

Batch Apex / Scheduled Apex

Platform Events

4. Security Testing

Profiles, Permission Sets

OWD, Sharing Rules

Manual Sharing

Role Hierarchy validation

5. Integrations

REST/SOAP API testing

Named Credentials

External systems (EHR, ERP, Billing)

6. Reporting

Reports

Dashboards

Bucket fields, Row-level formulas

7. Non-functional

Browser compatibility

Performance of Lightning components

Data migration validations

Real-Time Example:

During a referral-to-care-plan workflow testing, I validated:

Patient creation (custom object)

Care Plan automation (Flow)

Integration with EHR (API)

Security: Nurses should see only assigned patients

Lightning Page load performance

---

Q2. How do you validate Salesforce customizations?

Interview Answer:

I validate Salesforce customizations end-to-end using a structured approach:

---

1. Requirement Understanding

Review BRDs, User stories, Acceptance criteria

Compare customization workbook with what’s built

---

2. UI Validation

Check layouts, fields, picklists, dynamic visibility

Validate Lightning components

---

3. Backend Validation

Use SOQL to validate stored data

Check trigger behaviors and Flow execution paths

---

4. Automation Testing

Validate Flows → entry conditions, fault connectors

Validate Process Builders → ensure only one automation for each object

Validate Workflow Rules

Ensure no conflicting or duplicate automation

---

5. Security

Test FLS & CRUD for all profiles

Validate whether sensitive fields are masked

---

6. Integrations

API testing using Postman

Validate response mapping and error handling

---

7. Bulk Operations

Use Data Loader to test bulk operations

Validate governor limit handling (SOQL/DML limits)

---

Real Example:

During Care Team Assignment build:

I validated the Flow’s entry criteria

Verified CareTeamMember__c records via SOQL

Tested profile-level access for Coordinators

Verified integration mapping to EHR

---

Q3. How do you test Salesforce integrations?

Interview Answer:

For Salesforce integrations, I follow a 360° validation approach:

---

1. Review API documentation:

Endpoint URLs

Payload structure

Authentication (OAuth, JWT, Named Credentials)

---

2. Execute requests using tools:

Postman
SOAPUI

Workbench

---

3. Validate inbound and outbound flows:

REST → Inbound patient data from EHR

Outbound → Authorization updates to Payer systems

---

4. Validate Mapping:

Field mapping sheets

SOQL validation against expected results

---

5. Test Negative & Edge Scenarios:

400/500 errors

Auth token expiration

Timeouts

Partial updates

---

6. Validate Retry Logic:

Platform events

Queueable apex

Failed event replays

---

Real-Time Example:
During Eligibility Check API testing in Health Cloud:

Sent invalid policy number → expected 404 with error message

Valid policy → mapped response created Eligibility__c record

Checked debug logs + Mulesoft logs for message flow

---

✅ SECTION 2 — Salesforce Health Cloud

---

Q4. What is Salesforce Health Cloud and what testing areas are critical?

Interview Answer:

Salesforce Health Cloud is a healthcare CRM built to manage patient care, clinical
workflows, payer-provider relationships, and care coordination.

Critical Testing Areas:

---

1. Patient Management

Patient 360 card

Household relationships

Medications, Allergies

---

2. Care Plans

Goal creation

Tasks automation

Progress tracking
---

3. Care Team

Role-based assignments

Provider–Patient relationships
---

4. Utilization Management

Prior authorization workflows

Medical necessity checks

---

5. Referrals

Referral intake

Routing & Triage

Integration with external EHR

---

6. Integrations

FHIR/HL7

EHR sync (Epic/Cerner)

Payer APIs
---

7. HIPAA & compliance

Patient PHI masking

Role-based access

Field tracking

---
Real Example:

Care Manager should only see patients in their region.

Billing team should NOT see clinical data.

---

Q5. How do you validate Health Cloud data?

Interview Answer:

I validate Health Cloud data using the following approach:

---

1. Validate HL7/FHIR mappings:

Patient demographics

Conditions

Vitals

Medications

---

2. Validate object relationships:

Account ↔ Contact ↔ Patient

CarePlan__c → CareGoal__c

CareTeamMember__c linking
---

3. Validate automation:

Flows: create Care Tasks when Care Plan = Active

Hooks to external EHR systems

---

4. Validate security:

PHI fields masked for non-clinical profiles

Care Team access is restricted

---

Real Example:

While testing “Medication Reconciliation,” I validated:

EHR → Health Cloud sync

Duplicate prevention logic

Mapping of dosage instructions

Access only for Nurses & Doctors

---

✅ SECTION 3 — Life Sciences Testing

---

Q6. What is unique about Life Sciences testing?

Interview Answer:

Life Sciences testing has strict regulatory and compliance needs.

Key Focus Areas:

---

1. Compliance Requirements

GxP validation

21 CFR Part 11

Audit trails

E-signature validation

No tampering of records

---

2. Data Integrity Testing

ALCOA+ principles

Traceability from creation → review → approval

---

3. Documentation Standards

Validation Plan

Test Protocol

Traceability Matrix

IQ/OQ/PQ validation

---
4. Domain-Specific Workflows

Clinical trial subject management

Pharmaceutical sample distribution

Medical device complaint tracking

---

5. Change Control

All changes must go through Change Request + validation.

---

Real Example:

While testing “Sample Request Approval” for pharma reps:

Verified role-based approvals

Validated e-signatures

Tested audit logs for record changes

Ensured sample inventory update sync with SAP

---