Top 75 Salesforce Business Analyst Interview Questions 2026

Complete BA prep — BA vs Admin vs Developer comparison, how to become a Salesforce BA, and 75 real interview questions with direct answers, XYZ Company examples, and one-line interview answers.

75Questions

6Sections

BARole Guide

100%Free

All Topics Scenario Qs

Jump to Section

BA vs Admin vs Developer How to Become a Salesforce BA Requirements & User Stories (Q1-Q15) Process Mapping & Gap Analysis (Q16-Q25) UAT & Testing (Q26-Q35) Stakeholder Management (Q36-Q45) Salesforce Specific (Q46-Q60) Agile & Scenarios (Q61-Q75)

BA vs Admin vs Developer — Complete Comparison

Aspect	Business Analyst	Admin	Developer
Primary Focus	Requirements, process, stakeholders	Configuration, users, data	Code, integrations, custom solutions
Coding	None	None (declarative)	Apex, LWC, SOQL
Certifications	Salesforce BA, Admin, Agile	Admin, Advanced Admin	Platform Dev I & II
Avg Salary India	8-18 LPA	6-14 LPA	10-25 LPA
Avg Salary USA	$90K-$130K	$75K-$110K	$110K-$160K
Entry Barrier	Medium	Low	High
Best Background	Business, MBA, any domain	Any background	CS, Engineering, IT
Career Path	BA → Sr BA → Solution Architect	Admin → Sr Admin → Architect	Dev → Sr Dev → Tech Lead

How to Become a Salesforce Business Analyst in 2026

1Salesforce Admin Certified — Every Salesforce BA needs Admin cert first. Understand objects, flows, reports, profiles. Free prep: Trailhead + sfinterviewpro.com
2Salesforce BA Certification — Officially "Salesforce Certified Business Analyst". Covers requirements, user stories, UX, testing. Highest priority in 2026.
3Learn Agile & Scrum — Most Salesforce projects run Agile. Learn Sprint ceremonies, user stories, backlog management. Consider PSM or CSM certification.
4Process Mapping Tools — Lucidchart, Miro, Visio, Draw.io. BAs live in diagrams. Learn swimlane, process flow, data flow diagrams.
5Salesforce Functional Knowledge — Sales Cloud, Service Cloud, Experience Cloud, Flows, Reports. You don't code but must understand what's possible.
6Real Project Experience — Volunteer for NGO projects, intern, or start with an admin role. Hands-on experience is non-negotiable.
7Build Your Portfolio — Document a process you improved, a project you led. Interviewers want real examples, not theory.

📝

Requirements & User Stories

Q1-Q15 · Foundation of Every BA Interview

What is the role of a Business Analyst in a Salesforce implementation?

✅ Direct Answer

A Salesforce BA bridges the gap between business stakeholders and the technical team. They gather requirements, document processes, write user stories, facilitate UAT, and ensure the final solution meets business needs.

💡 Why?

The BA is the translator — business speaks goals, developers speak code. The BA converts goals into actionable, testable requirements. Without a good BA, projects fail not because of bad code but because of wrong code.

Phase	BA Responsibility
Discovery	Stakeholder interviews, As-Is process mapping
Design	User stories, acceptance criteria, To-Be process
Build	Clarify requirements, review dev progress
Testing	UAT planning, test scripts, defect management
Go-Live	Training, change management, hypercare support

🎯 Key Points

Gathers and documents requirements | Writes user stories with acceptance criteria | Facilitates stakeholder workshops | Manages UAT and sign-off | Does NOT write code

🏢 XYZ Company Example

At XYZ Company, the BA interviewed sales, operations, and management to understand how polymer orders flow. Discovered sales and ops had completely different views of the same process — documented both and created a unified To-Be before any Salesforce configuration began.

📌 For Interviewer

Bridges business and tech | Accountable for requirements quality | Key driver of project success

🎤 "A Salesforce BA translates business needs into clear, testable requirements that guide the technical team to build the right solution."

How do you gather requirements from stakeholders who are not clear about what they want?

✅ Direct Answer

Use structured discovery — stakeholder interviews, workshops, observation, shadowing, and prototype walkthroughs. Ask 'what problem are you trying to solve?' not 'what do you want built?'

💡 Why?

Stakeholders know their pain points but rarely know the solution. The question 'what do you want?' gets a wish list. The question 'what stops you from doing your job today?' gets real requirements.

🎯 Key Points

Open-ended questions: Walk me through your current process | 5 Whys technique for root cause | Observation: shadow users doing actual work | Prototype: show don't tell | Workshop: all stakeholders in one room

🏢 XYZ Company Example

At XYZ Company, the sales team said they wanted 'a better CRM'. After a 2-hour workshop, the real problem emerged — reps couldn't see which products were in stock during a customer call. The requirement became: real-time product availability on the Opportunity page.

📌 For Interviewer

Never accept 'I want X feature' as a requirement | Always ask: what business problem does this solve? | Document what you hear and play it back for validation

🎤 "Requirements gathering is not about capturing what stakeholders ask for — it's about uncovering what they actually need."

What is a User Story? Write one for a Salesforce scenario.

✅ Direct Answer

A User Story is a short description of a feature from the end user's perspective. Format: As a [role], I want [feature], so that [business value].

💡 Why?

User stories keep requirements focused on business value. The 'so that' clause forces the team to understand WHY the feature is needed, not just what to build.

Component	Example	Purpose
As a [role]	As a sales manager	Who needs this
I want [feature]	I want to see my team weekly pipeline	What is needed
So that [value]	So that I can coach underperforming reps	Why it matters
Acceptance Criteria	Given/When/Then	How to test it

🎯 Key Points

Role must be specific, not 'user' | Feature: one thing at a time | Value: measurable business outcome | Acceptance criteria: 3-5 testable conditions

🏢 XYZ Company Example

At XYZ Company: 'As an international sales rep, I want INR equivalent of opportunity amounts auto-converted, so that I can report accurate revenue without manual calculations.' This drove the multi-currency conversion trigger development.

📌 For Interviewer

Acceptance criteria are as important as the story | A story without 'so that' is incomplete | Stories should be independent, testable, and small

🎤 "A User Story captures a business need: As a [role], I want [feature], so that [value] — with testable acceptance criteria."

What is the difference between a BRD and an FRD?

✅ Direct Answer

BRD (Business Requirements Document) describes WHAT the business needs. FRD (Functional Requirements Document) describes HOW the system will meet those needs. BRD = business language. FRD = functional language.

💡 Why?

BRD is for business stakeholders — captures goals, scope, constraints. FRD is for the technical team — translates requirements into system behaviors.

Aspect	BRD	FRD
Audience	Business stakeholders	Developers, architects
Language	Business terms	System/functional terms
Example	Sales needs pipeline visibility	Dashboard shows 5 KPI tiles filtered by owner
When written	Discovery phase	Design phase

🏢 XYZ Company Example

At XYZ Company, the BRD stated: 'Management needs to track polymer sales performance by territory.' The FRD translated this to: 'Create a Salesforce Dashboard with 4 report components — Opportunities by Territory (bar chart), Win Rate by Rep (donut), Pipeline by Stage (funnel), Monthly Revenue Trend (line).'

📌 For Interviewer

In Agile, Epics = BRD, User Stories = FRD | Both need stakeholder sign-off | FRD should trace back to BRD

🎤 "BRD captures what the business needs; FRD describes how the system delivers it — BRD for stakeholders, FRD for the technical team."

What is MoSCoW prioritization?

✅ Direct Answer

MoSCoW = Must Have, Should Have, Could Have, Won't Have. It prioritizes requirements by importance so the team focuses on delivering the highest business value first.

💡 Why?

In every project there are more requirements than time allows. MoSCoW forces stakeholders to make hard decisions about what truly matters vs what would be nice to have.

Category	Meaning	Action
Must Have	Non-negotiable	Sprint 1
Should Have	Important but not critical at launch	Build if time allows
Could Have	Nice to have	Future sprint
Won't Have	Out of scope this release	Phase 2 backlog

🏢 XYZ Company Example

At XYZ Company: Must Have — Account management, Opportunity pipeline, basic reports. Should Have — IndiaMART integration, automated emails. Could Have — custom dashboards per territory. Won't Have — full ERP sync (Phase 2).

📌 For Interviewer

Get stakeholders to agree before build starts | Must Haves should be 60% or less of total scope | Revisit every sprint

🎤 "MoSCoW prioritizes requirements into Must, Should, Could, and Won't Have — ensuring the team builds what matters most first."

How do you handle conflicting requirements from different stakeholders?

✅ Direct Answer

Acknowledge both perspectives, understand the root cause, bring stakeholders together to find common ground, escalate to the sponsor if needed, and document the agreed decision.

💡 Why?

Conflicting requirements are normal — different departments have different priorities. Find the underlying business need behind each requirement — often conflicts resolve when both parties want the same outcome.

🎯 Key Points

Listen without judgment | Find the common goal behind conflicting asks | Present options with trade-offs — let stakeholders decide | Document the decision with names and date | Never decide yourself

🏢 XYZ Company Example

At XYZ Company, Sales wanted Leads auto-converted after 3 days. Operations wanted manual review. BA discovered both were concerned about data quality. Solution: auto-convert if key fields populated, else flag for manual review. Both teams agreed.

📌 For Interviewer

Never document conflicting requirements without resolution | Always get written sign-off | Use the sponsor as final escalation

🎤 "Conflicting requirements resolve by finding the shared business goal and facilitating agreement — never by the BA deciding unilaterally."

What is acceptance criteria and how do you write it?

✅ Direct Answer

Acceptance criteria are testable conditions a user story must meet to be accepted. Format: Given [context], When [action], Then [outcome].

💡 Why?

Acceptance criteria prevent the classic problem of a developer building exactly what was asked but not what was needed. They are the contract between BA and development — objective, testable, unambiguous.

Component	Example
Given (context)	Given a sales rep is on an Account record
When (action)	When they click New Opportunity
Then (outcome)	Then the Account name auto-populates

🎯 Key Points

Must be testable — pass/fail | Must be specific — no vague language | Cover happy path AND edge cases | Written BEFORE development starts

🏢 XYZ Company Example

At XYZ Company, User Story: 'As a rep, I want automatic INR conversion on Opportunities.' Criteria 1: Given USD amount, When saved, Then INR_Amount__c shows converted value using today's rate. Criteria 2: Given exchange rate unavailable, When saved, Then show error 'Exchange rate not found'.

📌 For Interviewer

Minimum 3 criteria per story | Include positive and negative scenarios | QA uses acceptance criteria to write test cases

🎤 "Acceptance criteria are Given/When/Then conditions defining exactly when a user story is complete — the objective, testable contract between BA and developer."

What is the difference between functional and non-functional requirements?

✅ Direct Answer

Functional requirements describe WHAT the system does — features and behaviors. Non-functional requirements describe HOW WELL — performance, security, usability, scalability.

💡 Why?

Both are essential. A system that works but is too slow or insecure fails in production. Non-functional requirements are often harder to capture because stakeholders don't think about them until something breaks.

Type	Salesforce Examples
Functional	Create Opportunity, auto-send email on stage change, generate PDF quote
Performance	Dashboard loads in under 3 seconds
Security	Only managers can see salary fields
Usability	Mobile-responsive on all devices

🏢 XYZ Company Example

At XYZ Company: functional requirement — generate Proforma Invoice PDF. Non-functional — the PDF must generate in under 5 seconds and be under 2MB. The PDF worked but failed UAT taking 12 seconds — a non-functional requirement failure.

📌 For Interviewer

Always capture non-functional requirements in discovery | Non-functional failures cause production incidents | Security requirements are non-functional

🎤 "Functional requirements define what the system does; non-functional define how well it does it — both equally critical."

What is scope creep and how do you manage it?

✅ Direct Answer

Scope creep is the gradual expansion of project scope beyond what was agreed, without changes to timeline or budget. It is managed through a formal Change Request process.

💡 Why?

Scope creep is the #1 reason Salesforce projects go over budget and time. A BA's job is to say yes to the need, not necessarily yes to the timing.

🎯 Key Points

Maintain a signed requirements baseline | All new requests through a Change Request | Every CR assessed for time, cost, and risk | Stakeholders decide: now or Phase 2 | Never absorb new requirements silently

🏢 XYZ Company Example

At XYZ Company, mid-project a manager requested WhatsApp notifications. BA documented as a Change Request, estimated 2 extra sprints, presented impact to sponsor. Decision: defer to Phase 2. Go-live date protected.

📌 For Interviewer

Document everything — verbal discussions are not scope control | A Change Request is not rejection — it's a process | Scope creep always comes from good intentions

🎤 "Scope creep is managed through a Change Request process that makes the time, cost, and risk impact transparent before any new requirement is accepted."

Q10

What is a Requirements Traceability Matrix (RTM)?

✅ Direct Answer

An RTM maps each requirement to its source, user story, Salesforce feature, and test case — ensuring nothing is missed and every requirement is tested.

💡 Why?

RTM provides end-to-end visibility. It answers: Is every requirement covered by a test case? Has every test case been executed? Can we trace a defect to its requirement? Essential in regulated industries.

Req ID	Business Need	User Story	SF Feature	Status
REQ001	Pipeline visibility	US-12	Opp Dashboard	Done
REQ002	Auto email on close	US-18	Flow	Testing

🎯 Key Points

Every requirement needs at least one test case | Use RTM to track project completeness | Helps identify requirements with no test coverage

🏢 XYZ Company Example

At XYZ Company, BA maintained an RTM with 47 requirements. During UAT, discovered REQ-031 (account merge handling) had no test case — caught before go-live. Without RTM this would have been missed.

📌 For Interviewer

RTM is a living document — update throughout | Useful for regression testing future releases | Proves completeness to sponsors and auditors

🎤 "An RTM maps every requirement to its user story, Salesforce feature, and test case — ensuring complete coverage and nothing slips through."

Q11

What is the difference between a Use Case and a User Story?

✅ Direct Answer

A Use Case describes a system interaction in detail — actors, preconditions, main flow, exceptions. A User Story is lightweight — a conversational description of a need focused on business value.

💡 Why?

Use Cases are formal and detailed, common in waterfall. User Stories are brief and Agile — conversation starters, not complete specifications. Modern Salesforce projects use User Stories.

Aspect	Use Case	User Story
Methodology	Waterfall	Agile
Length	1-5 pages	1-3 sentences
Format	Actor, precondition, main flow	As a / I want / So that

🏢 XYZ Company Example

At XYZ Company, a traditional use case for quote generation would be 3 pages. The Agile user story: 'As a sales rep, I want to generate a PDF quote from an Opportunity, so that I can send it to a customer within 5 minutes.' Detail came through acceptance criteria.

📌 For Interviewer

Modern Salesforce projects use User Stories | Use Cases used in some enterprise/waterfall projects | Both need acceptance criteria

🎤 "Use Cases are formal with all scenario flows; User Stories are brief Agile descriptions capturing business value in one or two sentences."

Q12

How do you validate requirements with stakeholders before development begins?

✅ Direct Answer

Use requirements walkthroughs, prototype reviews, and formal sign-off sessions. Show stakeholders what you understood — not what they said.

💡 Why?

The cost of fixing a requirement error in development is 10x the cost in the requirements phase. Walking stakeholders through what you documented — and having them confirm it — is non-negotiable.

🎯 Key Points

Requirements Walkthrough: present back what you captured | Prototype: sandbox mockup or Figma demo | Sign-off document: formal written agreement | Review with ALL stakeholders — not just the loudest

🏢 XYZ Company Example

At XYZ Company, after gathering requirements for Visit Reports, the BA created a Figma mockup and walked through it with reps, their manager, and IT. Manager needed a 'Customer Satisfaction Rating' field the reps never mentioned. Caught before development.

📌 For Interviewer

Never start development without written sign-off | Prototype reviews catch 80% of misunderstandings | Document who signed off and when

🎤 "Requirements validation shows stakeholders what you understood through prototypes and walkthroughs — then gets formal written sign-off before development begins."

Q13

What is the difference between As-Is and To-Be process?

✅ Direct Answer

As-Is is the current state — how things work TODAY. To-Be is the future state — how things will work AFTER Salesforce. The gap between them defines what needs to be built.

💡 Why?

Understanding As-Is prevents digitizing a broken process. If you implement Salesforce on top of a bad process, you just have a faster bad process.

Aspect	As-Is	To-Be
Definition	Current state	Future state after Salesforce
Purpose	Understand pain points	Define desired outcome
Output	Process map with problems	Process map with Salesforce solution

🏢 XYZ Company Example

At XYZ Company: As-Is — IndiaMART inquiry arrives by email → rep creates Excel entry → follow up manually → no tracking. To-Be — API → Salesforce Lead → auto-assigned → automated follow-up → pipeline visible. The gap became the project scope.

📌 For Interviewer

Always document As-Is before designing To-Be | Highlight pain points — they drive requirements | To-Be should always be better, not just digital

🎤 "As-Is documents the current process with pain points; To-Be shows the improved future state — the gap is exactly what Salesforce delivers."

Q14

What is a Product Backlog and how do you manage it?

✅ Direct Answer

A Product Backlog is a prioritized list of all features, user stories, and tasks for a Salesforce project. Owned by the Product Owner, managed by the BA, it is the single source of truth for what needs to be built.

💡 Why?

The backlog is never done — it grows as the project evolves. Good backlog management means items are always prioritized, estimated, and ready for the next sprint.

🎯 Key Points

Top items: fully written, estimated, acceptance criteria clear | Middle: written, needs refinement | Bottom: ideas, not yet refined | Backlog grooming: regular session to refine and reprioritize

🏢 XYZ Company Example

At XYZ Company, the BA maintained 89 user stories in Jira. Before each sprint, ran a 1-hour grooming session with the Product Owner to refine the top 15 stories, estimate effort, and confirm priority. Sprint always started with a clear, ready backlog.

📌 For Interviewer

Use MoSCoW to prioritize | Groom every sprint, not just at start | Remove obsolete items — bloated backlog confuses the team

🎤 "A Product Backlog is a living prioritized list managed through grooming sessions — ensuring the team always works on the highest-value items."

Q15

How do you manage a stakeholder who keeps changing requirements after sign-off?

✅ Direct Answer

Acknowledge the change, assess the impact, submit a formal Change Request, present the time/cost impact, and get a decision on whether to incorporate or defer.

💡 Why?

Requirement changes after sign-off are reality. A BA's role is not to block change but to make its impact visible. When stakeholders understand 'one small change' means 2 extra weeks, they often defer to Phase 2.

🎯 Key Points

Never say no to a change — say 'here is the impact' | Log all changes in a Change Log — dated and signed | Escalate to sponsor if changes are frequent and disruptive | Use Change Request as a professional tool

🏢 XYZ Company Example

At XYZ Company, a sales manager requested 6 post-sign-off changes in Sprint 3. BA documented each as a Change Request with estimates. Total: 3 extra sprints. Sponsor decided: 2 absorbed, 4 deferred to Phase 2. Go-live date protected.

📌 For Interviewer

A Change Log is your protection as a BA | Verbal approval is not approval — everything in writing | Frequent changes signal poor initial gathering — reflect and improve

🎤 "Post-sign-off changes are managed through a Change Request process that makes impact transparent — letting stakeholders make informed decisions."

🗺️

Process Mapping & Gap Analysis

Q16-Q25 · Show You Understand Business Before Technology

Q16

What is process mapping and why is it critical in Salesforce projects?

✅ Direct Answer

Process mapping visually documents a business process — steps, decision points, actors, and systems. It is critical because it reveals the actual workflow Salesforce needs to support and highlights inefficiencies to fix before automation.

💡 Why?

You cannot automate what you don't understand. Process maps reveal hidden steps stakeholders forgot to mention and create shared understanding between business and IT.

🎯 Key Points

Reveals hidden steps | Identifies automation opportunities | Highlights waste and inefficiency | Creates shared understanding | Drives Flow and trigger design

🏢 XYZ Company Example

At XYZ Company, process mapping the quote-to-order process revealed 14 manual email steps. The map showed 4 steps fully automatable in Flows, reducing quote turnaround from 3 days to 4 hours.

📌 For Interviewer

Always map As-Is before designing To-Be | Validate maps with multiple stakeholders | Use swimlane diagrams for cross-department processes

🎤 "Process mapping visually documents how a business works — revealing what to support, what to automate, and what to fix before implementation."

Q17

What tools do you use for process mapping?

✅ Direct Answer

Lucidchart, Miro, Draw.io (free), Microsoft Visio, and Microsoft Whiteboard for remote workshops. For documentation: Confluence, SharePoint, or Google Docs.

💡 Why?

The tool matters less than the clarity of the diagram. Cloud-based tools like Miro and Lucidchart are preferred because stakeholders can review and comment in real time.

Tool	Best For	Cost
Lucidchart	Professional maps, Confluence integration	Paid (free tier)
Miro	Collaborative workshops	Free tier
Draw.io	Quick diagrams, free	Free
Visio	Enterprise technical diagrams	M365 license

🏢 XYZ Company Example

At XYZ Company, Miro was used for discovery workshops — stakeholders added sticky notes remotely. Formal swimlane diagrams were then created in Lucidchart for the FRD with direct stakeholder commenting.

📌 For Interviewer

Know 2-3 tools well — interviewers often ask | Miro popular for Agile teams | Always export and attach to project documentation

🎤 "Lucidchart, Miro, and Draw.io are the most common — choose what stakeholders can actually access and review."

Q18

What is a gap analysis and how do you conduct one?

✅ Direct Answer

A gap analysis compares As-Is with To-Be and identifies what is missing, what needs to change, and what Salesforce must deliver to bridge those gaps.

💡 Why?

The gap analysis turns process mapping into an actionable requirements list. Each gap becomes a requirement. Each requirement becomes a user story.

Step	Action
1. Map As-Is	Document current state
2. Define To-Be	Document desired future state
3. Identify Gaps	What is missing or needs to change?
4. Categorize	People, Process, Technology gaps
5. Prioritize	MoSCoW — which gaps must close at go-live?

🏢 XYZ Company Example

At XYZ Company: As-Is — leads in Excel, no visibility. To-Be — leads in Salesforce, auto-assigned, pipeline visible. Gaps: No CRM (Technology), No qualification process (Process), Reps unfamiliar with CRM (People). Each gap drove a workstream.

📌 For Interviewer

People, Process, and Technology gaps all need addressing | Not all gaps are Salesforce problems — some are training | Gap analysis output feeds the requirements

🎤 "A gap analysis identifies the As-Is to To-Be difference across people, process, and technology — each gap becomes a project requirement."

Q19

What is a swimlane diagram?

✅ Direct Answer

A swimlane diagram shows which department or role is responsible for each process step using horizontal or vertical lanes. Used when a process spans multiple teams to make handoffs visible.

💡 Why?

Cross-department handoffs are where most Salesforce projects fail. Swimlane diagrams make handoffs explicit — when sales finishes, who picks it up? A swimlane answers this visually.

🎯 Key Points

Each lane = one department | Steps in a lane = that team's responsibility | Arrows crossing lanes = handoffs (biggest risk points) | Best for: lead-to-opp, quote-to-order, case escalation

🏢 XYZ Company Example

At XYZ Company, the order process involved Sales, Operations, Accounts, and Logistics. The swimlane revealed the same data entered 3 times across 3 systems. Salesforce integration eliminated 2 of those entries.

📌 For Interviewer

Swimlane diagrams show BA expertise — use them in interviews | Handoff points = highest automation opportunity | Review with ALL departments shown

🎤 "A swimlane diagram shows who does what in a cross-department process — making handoffs visible, explicit, and ready for automation."

Q20

How do you identify automation opportunities during process mapping?

✅ Direct Answer

Look for repetitive manual steps, data entry duplication, email-based notifications, approval chains with clear rules, and tasks that always follow another task.

💡 Why?

Automation is the highest-value Salesforce delivery. A BA who can identify automation opportunities adds enormous value beyond requirements documentation.

Signal	Automation Solution
Manual email sent every time X happens	Flow — email alert
Data copied from one place to another	Field update or integration
Approval follows a rule: if amount > X	Salesforce Approval Process
Task always created when stage changes	Flow — record triggered

🏢 XYZ Company Example

At XYZ Company, process mapping showed: every IndiaMART lead — rep manually creates Contact, updates Excel, emails territory manager. Three automations: API integration (Lead auto-creation), Flow (Contact creation), Flow (manager notification).

📌 For Interviewer

Ask: Does this step always happen the same way? If yes, automate | Document opportunities in FRD with priority

🎤 "Automation opportunities are repetitive, rule-based, duplicative steps in the process map — each is a Flow or trigger candidate."

Q21

What is the difference between a business process and a Salesforce Workflow/Flow?

✅ Direct Answer

A business process is a series of steps people follow to achieve a business goal. A Salesforce Flow is the automation tool that digitizes part of that process.

💡 Why?

The business process exists independently of Salesforce. The Flow is its technical implementation. A BA understands the business process first, then determines which parts to automate.

🏢 XYZ Company Example

At XYZ Company, the complaint resolution process had 8 steps across 3 departments. Salesforce automated 4 of those 8 using Flows — auto-creating a Case, assigning to the right team, sending an acknowledgment, and escalating after 48 hours. The other 4 remained human-judgment decisions.

📌 For Interviewer

Not every process step should be automated | Automate only rule-based steps | Document which steps are automated vs manual in To-Be

🎤 "A business process is what people do to achieve a goal; a Flow automates the rule-based parts — the BA decides what to automate and what stays human."

Q22

How do you handle a business requirement that standard Salesforce cannot deliver?

✅ Direct Answer

First validate the requirement is truly needed. Then explore: AppExchange packages, declarative customization, and custom development. Present options with trade-offs to stakeholders.

💡 Why?

Never say 'Salesforce can't do that' without exploration. Salesforce is highly configurable. But also don't promise custom development without understanding cost and maintenance.

Option	When to Use	Trade-off
AppExchange	Common need, pre-built solution	Licensing cost
Declarative (Flow)	Achievable without code	May have limits
Custom Dev	Unique business logic	Higher cost, requires developer
Process change	Requirement is gold-plating	Change management needed

🏢 XYZ Company Example

At XYZ Company: requirement — generate Proforma Invoice PDF with QR code. Standard reports couldn't do it. Options: AppExchange PDF tool (₹2L/year) or Custom Visualforce PDF (1 sprint, one-time). Stakeholders chose custom — now in production for 2 years.

📌 For Interviewer

Always present options — never just 'not possible' | Document the decision and rationale | Consider maintenance when recommending custom dev

🎤 "When standard Salesforce can't meet a requirement, the BA presents AppExchange, declarative, and custom development options with trade-offs — never a dead end."

Q23

What is a data flow diagram?

✅ Direct Answer

A DFD shows how data moves through a system — from origin, where it goes, what transforms it, and where it stores. Used when designing integrations, migrations, or complex data architectures.

💡 Why?

DFDs are critical for integration design. When connecting Salesforce to ERP or marketing platforms, a DFD makes data movement explicit — preventing data loss, duplication, or incorrect mapping.

🏢 XYZ Company Example

At XYZ Company, a DFD for the IndiaMART-Salesforce integration showed: IndiaMART inquiry → API call → Salesforce Lead with field mapping: company_name → Account, contact_name → Contact, product_interest → Lead Description. Caught a missing phone field before development.

📌 For Interviewer

Use DFDs for any integration or migration | Prevents the most expensive integration errors

🎤 "A DFD maps how data moves between systems — essential for integrations and migrations to ensure correct field mapping with no data loss."

Q24

What is the difference between a business rule and a Salesforce validation rule?

✅ Direct Answer

A business rule is a policy the organization follows. A validation rule is the Salesforce-specific technical implementation that prevents incorrect data entry.

💡 Why?

Not all business rules become validation rules. Some become Flows, some become Apex, some become training. The BA identifies business rules and the tech team decides implementation.

Aspect	Business Rule	Validation Rule
Nature	Organizational policy	Technical implementation
Example	Phone is required for all Contacts	ISBLANK(Phone) shows error
Defined by	Business stakeholders	Admin/Developer

🏢 XYZ Company Example

At XYZ Company: Business rule — no Opportunity without a phone on the Account. Implemented as a validation rule checking if Account.Phone is blank on Opportunity creation.

📌 For Interviewer

Document ALL business rules — not just the validation rule ones | Some rules are better as Flows | Validation rules need user-friendly error messages

🎤 "A business rule is organizational policy; a validation rule is one way to enforce it — the BA documents the rule, the admin decides the implementation."

Q25

How do you document a business process for handover to a developer?

✅ Direct Answer

Provide: To-Be process map, user stories with acceptance criteria, data model requirements, Salesforce-specific notes (record types, automation type), and a walkthrough session.

💡 Why?

Documentation developers can actually use is a BA superpower. A developer needs: what triggers this, what data is involved, edge cases, what success looks like.

🏢 XYZ Company Example

At XYZ Company, Visit Report module handover: swimlane diagram, 8 user stories with acceptance criteria, ERD showing Visit_Report__c fields and relationships, Salesforce notes (LWC component, after update trigger on Opportunity), and 30-minute walkthrough. Developer delivered in 2 sprints with zero rework.

📌 For Interviewer

A walkthrough session is non-negotiable — docs alone are never enough | Include edge cases in acceptance criteria | Be available during development for clarifications

🎤 "Developer-ready documentation includes process map, user stories, data model, Salesforce guidance, and a walkthrough — reducing rework and misunderstandings."

✅

UAT & Testing

Q26-Q35 · The BA Owns Testing Quality

Q26

What is UAT and how do you plan it?

✅ Direct Answer

UAT (User Acceptance Testing) is the final phase where real business users verify the Salesforce solution meets requirements. The BA plans UAT, writes test scripts, coordinates testers, manages defects, and facilitates sign-off.

💡 Why?

UAT is the last chance to catch issues before go-live. A poorly run UAT means production incidents, unhappy users, and eroded trust.

Phase	BA Activity
UAT Planning	Define scope, identify testers, create test plan
Test Scripts	Write step-by-step test cases from user stories
Execution	Support testers, log defects, track progress
Sign-off	Get formal written sign-off from business owners

🏢 XYZ Company Example

At XYZ Company UAT: BA wrote 34 test cases for 8 user stories. 5 users tested over 3 days. 7 defects — 2 critical (fixed before go-live), 5 minor (Phase 2). Formal sign-off before go-live.

📌 For Interviewer

UAT should use real business data | Testers = end users, not IT staff | Never skip UAT — 'fix in production' is not a plan

🎤 "UAT is final verification by real business users that Salesforce meets requirements — the BA plans it, coordinates it, manages defects, and secures formal sign-off."

Q27

What is the difference between UAT and System Testing?

✅ Direct Answer

System Testing verifies the technical solution works as built — done by the dev/QA team. UAT verifies the solution meets business requirements — done by business users.

💡 Why?

A solution can pass system testing and fail UAT — system testing checks 'does it work?', UAT checks 'does it do what we need?'

Aspect	System Testing	UAT
Who	Dev/QA team	Business users
Checks	Technical correctness	Business requirements
Environment	QA sandbox	UAT sandbox
Timing	Before UAT	After system testing passes

🏢 XYZ Company Example

At XYZ Company, PDF quote passed system testing — generated with no errors. In UAT, users found missing bank details, wrong logo, and incorrect INR decimal formatting. Business requirements system testing didn't cover — UAT caught them.

📌 For Interviewer

UAT should never begin before system testing passes | Business users are not responsible for technical bugs | UAT defects categorized by severity for go/no-go

🎤 "System testing checks technical correctness by the dev team; UAT checks business requirement fulfillment by real users — both required before go-live."

Q28

How do you write test cases for Salesforce UAT?

✅ Direct Answer

A test case has: Test Case ID, User Story, Preconditions, Test Steps (numbered), Expected Result, Actual Result, Pass/Fail status.

💡 Why?

Test cases must be clear enough for a business user to execute. Vague test cases lead to inconsistent testing.

Field	Example
Test Case ID	TC-012
User Story	US-08: Auto-create Task on Opportunity creation
Precondition	User logged in as Sales Rep
Steps	1. Go to Opportunities 2. Click New 3. Fill required fields 4. Save
Expected Result	Task with subject "Follow up" appears, due in 3 days

🏢 XYZ Company Example

At XYZ Company, Visit Report trigger test: Precondition — Opportunity in Proposal Sent. Steps: 1) Change stage to Negotiation, 2) Save. Expected: Visit_Report__c created with Status=Pending, linked to Opp and Account. 3 testers executed consistently.

📌 For Interviewer

Write from user perspective | Each test case tests ONE behavior | Include negative test cases

🎤 "A good test case has specific preconditions, numbered steps, and a measurable expected result — clear enough for a non-technical user."

Q29

How do you manage defects found during UAT?

✅ Direct Answer

Log each defect with ID, description, steps to reproduce, expected vs actual result, severity, and screenshot. Prioritize with the project manager. Track resolution and retest.

💡 Why?

Not all defects block go-live — a BA must judge severity. A missing logo is different from data corruption.

Severity	Definition	Action
Critical (P1)	Core process broken, no workaround	Must fix before go-live
High (P2)	Significant, workaround exists	Fix if time allows
Medium (P3)	Minor impact, workaround	Post-go-live release
Low (P4)	Cosmetic	Future backlog

🏢 XYZ Company Example

At XYZ Company: 12 UAT defects. 1 Critical (Opportunity amount wrong — fix immediately), 2 High (PDF formatting), 5 Medium (known issues), 4 Low (cosmetics). Go-live after Critical and High resolved.

📌 For Interviewer

Use a defect tracker | Every defect needs steps to reproduce | Retest every fixed defect before closing

🎤 "Defects are categorized by severity — Critical and High block go-live, Medium and Low are accepted with a remediation plan."

Q30

What is regression testing in Salesforce?

✅ Direct Answer

Regression testing verifies that new changes haven't broken existing functionality that was previously working. Critical because Salesforce changes can have unintended side effects.

💡 Why?

Salesforce is connected — a change to one Flow or trigger can affect seemingly unrelated functionality. Regression testing catches these before they reach production.

🏢 XYZ Company Example

At XYZ Company, a new Visit Report trigger in Sprint 5 accidentally broke the Opportunity stage validation from Sprint 2. Regression testing caught it before production.

📌 For Interviewer

Maintain a regression test suite from previous sprints | Run before every deployment | Use sandboxes to test before production

🎤 "Regression testing verifies new changes haven't broken existing functionality — essential because Salesforce automation is interconnected."

Q31

What is the difference between positive and negative testing?

✅ Direct Answer

Positive testing verifies correct behavior with valid inputs (happy path). Negative testing verifies the system handles invalid inputs and edge cases correctly.

💡 Why?

Most people test the happy path — but negative scenarios are where production incidents happen. Both are required for complete coverage.

Type	Salesforce Example
Positive	Create Opp with all required fields → saves successfully
Negative	Create Opp with blank Account → shows validation error
Positive	Change stage to Closed Won → Congratulations task created
Negative	Jump from Proposal Sent to Closed Won → error displayed

🏢 XYZ Company Example

At XYZ Company, phone validation: Positive — '+91-9876543210' saves. Negative — '98765' too short shows error. '---' no digits shows error. Blank shows required error. All 4 needed.

📌 For Interviewer

For every positive test, write at least one negative | Edge cases are negative tests | Negative testing catches validation and error handling gaps

🎤 "Positive testing validates the happy path; negative testing validates error handling — both required because users never follow the expected path perfectly."

Q32

How do you get formal sign-off after UAT?

✅ Direct Answer

Present a UAT Summary Report showing test case results and defect resolution status. Get written sign-off — email or document — from the business owner before scheduling go-live.

💡 Why?

Verbal sign-off is not sign-off. A BA needs documented written confirmation. Without it, the go-live decision is ambiguous.

🏢 XYZ Company Example

At XYZ Company, UAT Sign-off: '48 of 48 test cases passed. 2 medium defects accepted as known issues with workaround documented. Business owner approves go-live on [date].' Signed by Sales Director and Operations Head.

📌 For Interviewer

Sign-off must come from the right authority | Known issues need documented workaround | Never go live without written sign-off

🎤 "UAT sign-off is formal written acceptance from the business owner — verbal agreement is never sufficient."

Q33

What is a test plan?

✅ Direct Answer

A test plan documents the testing strategy: scope, objectives, test types, environment, resources, schedule, entry/exit criteria, and risk. Created before UAT begins.

💡 Why?

A test plan prevents chaotic testing where everyone tests whatever they feel like. It ensures systematic, complete coverage with an objective go/no-go decision.

🏢 XYZ Company Example

At XYZ Company: UAT test plan covered 8 modules, 48 test cases, 5 testers, 3-day window, entry criteria (system testing complete, test data loaded), exit criteria (all Critical/High resolved, sign-off obtained). Approved by sponsor before testing began.

📌 For Interviewer

Exit criteria are as important as entry | Test plan approved before testing starts | Update as scope changes

🎤 "A test plan defines testing strategy with scope, resources, and exit criteria — ensuring systematic coverage and a clear go/no-go standard."

Q34

How do you test a Salesforce Flow?

✅ Direct Answer

Test Flows by: creating trigger records, verifying expected outcomes, testing all decision branches, testing edge cases and null values, and checking debug logs for errors.

💡 Why?

Flows are often tested only on the happy path — insufficient. A Flow with 3 branches needs test cases for each branch. Null values and bulk scenarios must be tested.

🏢 XYZ Company Example

At XYZ Company, testing Stage Change Flow: Test 1 — change to Negotiation (first time) → Visit Report created ✅. Test 2 — move back then return to Negotiation → duplicate NOT created ✅. Test 3 — bulk update 10 Opps → all 10 reports created ✅. Test 4 — Opp without Account → Flow handles gracefully ✅.

📌 For Interviewer

Test all decision branches | Test bulk scenarios | Check debug logs when Flow doesn't behave as expected

🎤 "Testing a Flow requires cases for every decision branch, null values, edge cases, and bulk scenarios — not just the happy path."

Q35

What is smoke testing vs sanity testing?

✅ Direct Answer

Smoke testing is a quick check that basic functions work after a new deployment. Sanity testing is a focused test of a specific area after a bug fix.

💡 Why?

Both are quick pre-tests. Smoke testing is done first after every deployment. If smoke fails, there is no point doing full regression.

Aspect	Smoke Testing	Sanity Testing
When	After every new deployment	After a specific bug fix
Scope	Wide and shallow	Narrow and deep
Purpose	Is the system stable to test?	Is this specific fix working?

🏢 XYZ Company Example

At XYZ Company: after each Sprint deployment, 20-minute smoke test — login works, Accounts load, Opportunities create, reports open. If passed — UAT is open. After bug fix, sanity test confirmed just that specific fix.

📌 For Interviewer

Document smoke test checklist — same every time | 15-20 minutes maximum | Sanity after bug fixes prevents regressions

🎤 "Smoke testing checks system stability after deployment; sanity testing checks a specific fix — both are quick pre-tests before full UAT."

🤝

Stakeholder Management

Q36-Q45 · The Softest But Most Critical BA Skill

Q36

What is a RACI matrix?

✅ Direct Answer

RACI = Responsible, Accountable, Consulted, Informed. A matrix defining who does what for each project task or decision — eliminating role confusion.

💡 Why?

On Salesforce projects, role confusion is common. Who approves requirements? Who signs off UAT? Who makes go/no-go? RACI answers all upfront before conflicts arise.

Role	Meaning	Example
Responsible	Does the work	BA writes user stories
Accountable	Owns the outcome (one person only)	Product Owner signs off
Consulted	Input required	Sales Manager on lead rules
Informed	Notified, no input	Finance team on go-live date

🏢 XYZ Company Example

At XYZ Company, Requirements Sign-off RACI: BA = Responsible, Sales Director = Accountable, IT Manager = Consulted, Operations = Informed. No ambiguity on who to send requirements to for sign-off.

📌 For Interviewer

Only ONE person can be Accountable | Too many Consulted = slow decisions | Create RACI at project start

🎤 "A RACI matrix defines responsibility and authority for every project task — eliminating role confusion before it causes delays."

Q37

How do you manage a stakeholder resistant to Salesforce adoption?

✅ Direct Answer

Understand the root cause of resistance, address it directly, involve them early, show quick wins, and get executive sponsorship to reinforce the change.

💡 Why?

Resistance is almost always rational — people fear job changes, distrust IT projects, or believe their current process is better. Dismissing resistance creates a go-live nobody uses.

Root Cause	BA Response
Fear of job loss	Show how Salesforce reduces admin work, not jobs
Past CRM failure	Acknowledge past, explain what is different now
Comfort with Excel	Show side-by-side benefit comparison
Loss of information power	Give them a key SME role in the project

🏢 XYZ Company Example

At XYZ Company, one senior rep refused Salesforce and kept updating his private Excel. BA discovered he feared pipeline data becoming visible to management. Showed him how filters let him see HIS data separately. He became the team's strongest advocate.

📌 For Interviewer

Find the personal WIIFM for every resistor | Involve resistors early — make them part of the solution | Quick wins in UAT build confidence

🎤 "Resistance to Salesforce is rational — the BA understands the specific concern and turns resistors into advocates through early involvement and personal benefit."

Q38

What is change management in a Salesforce project?

✅ Direct Answer

Change management is the structured process of transitioning people from the current way to the new Salesforce-enabled way. The BA drives communication planning, stakeholder impact assessment, training coordination, and hypercare support.

💡 Why?

Technology implementations fail when people don't change behavior. Salesforce is the easy part — getting 50 reps to use it is the hard part.

Activity	BA Role
Impact assessment	Document how each group work changes
Communication plan	What to communicate, when, to whom
Training plan	Identify needs, coordinate delivery
Hypercare	Available for questions post go-live

🏢 XYZ Company Example

At XYZ Company go-live: BA prepared a 2-page visual cheat sheet per role (not a 40-page manual), 30-minute training per team, a WhatsApp support group, and daily check-ins for 2 weeks. Adoption at 90% by end of week 2.

📌 For Interviewer

Training should happen close to go-live — not 3 months before | A cheat sheet beats a manual for adoption | Hypercare = first 2-4 weeks post go-live

🎤 "Change management transitions people to the new way — the BA drives communication, training, and hypercare to ensure adoption, not just deployment."

Q39

How do you communicate project status to non-technical stakeholders?

✅ Direct Answer

Use visual, plain-language status reports — RAG (Red/Amber/Green) status, milestone percentages, and clear statements of what needs attention. No jargon. Focus on business impact.

💡 Why?

Executives don't need to understand Apex architecture — they need to know: are we on track? what decisions do I need to make? what risks am I carrying?

🎯 Key Points

RAG status at a glance | One page maximum | Always end with decisions needed | Milestone completion percentage not task list

🏢 XYZ Company Example

At XYZ Company, BA's weekly MD status report was one slide: Green (Requirements 100%, Dev 85%), Amber (UAT starts Monday), Red (ERP API delayed — decision needed on go-live date). MD made decisions in 5 minutes.

📌 For Interviewer

Under one page | RAG makes risks visible | Always include decisions needed — make it easy for stakeholders to act

🎤 "Non-technical stakeholders need one-page RAG status with milestone progress and clear decisions needed — not technical details."

Q40

What is the difference between a Product Owner and a BA?

✅ Direct Answer

Product Owner owns the product vision and prioritizes the backlog — responsible for value. BA gathers requirements, documents processes, and supports UAT — responsible for requirements quality.

💡 Why?

In smaller projects one person often plays both roles. Understanding both makes a BA more valuable.

Aspect	Product Owner	Business Analyst
Focus	What to build and priority	Requirements, documentation, UAT
Authority	Final say on what to build	Facilitates and recommends
Agile role	Sprint Review — accepts stories	Sprint Planning — refines stories

🏢 XYZ Company Example

At XYZ Company, Sales Director acted as PO (prioritization decisions) while BA handled requirements, documentation, UAT, and daily dev coordination. Clear separation prevented decision confusion.

📌 For Interviewer

PO = what to build and in what order | BA = how to document and validate | In small teams BA often plays PO role too

🎤 "Product Owner owns vision and prioritizes the backlog; BA ensures requirements are clear and testable — complementary roles that often overlap in practice."

Q41

How do you build trust with stakeholders as a new BA?

✅ Direct Answer

Deliver on small commitments first, listen more than you talk in early meetings, be transparent about what you don't know, and demonstrate knowledge of their business — not just Salesforce.

💡 Why?

Trust is earned through consistent reliability. A BA who delivers on promises builds trust faster than one who over-promises.

🎯 Key Points

Under-promise and over-deliver — especially in month 1 | Follow up on every action item — even small ones | Admit what you don't know — stakeholders respect honesty

🏢 XYZ Company Example

At XYZ Company, the BA's first week: shadow 3 sales reps for half a day each — no meetings, just observation. By week 2, stakeholders were proactively sharing problems they'd never told the previous IT team.

📌 For Interviewer

No impressive presentations in week 1 | Listen before you speak | Consistent small deliveries beat big promises

🎤 "Trust is built through consistent delivery on small commitments and active listening — not through impressive presentations."

Q42

What is a stakeholder register?

✅ Direct Answer

A stakeholder register documents all stakeholders — name, role, influence level, interest level, communication preferences, and key concerns. It guides how to engage each person effectively.

💡 Why?

Not all stakeholders are equal. A sales director and a data entry clerk need completely different engagement approaches.

Field	Purpose
Influence (High/Med/Low)	How much they can impact the project
Interest (High/Med/Low)	How much they care about the outcome
Communication preference	Email, meeting, weekly update
Key concerns	What they worry about — address proactively

🏢 XYZ Company Example

At XYZ Company: MD — High influence, Low interest — monthly executive summary only. Sales Reps — Low influence, High interest — weekly training and feedback. Tailored engagement for each.

📌 For Interviewer

Create at project start | High influence + Low interest = keep satisfied | Low influence + High interest = change champions, keep informed

🎤 "A stakeholder register maps influence, interest, and preferences — enabling tailored engagement for each person throughout the project."

Q43

How do you handle a developer saying 'that's not possible in Salesforce'?

✅ Direct Answer

Don't accept it at face value. Ask: what specific limitation? Then explore alternatives — AppExchange, declarative approach, modified requirement, or workaround.

💡 Why?

'Not possible in Salesforce' is rarely true. Usually means 'not possible with this approach'. A BA finds the acceptable alternative.

🎯 Key Points

Ask 'what is the constraint specifically?' before accepting | An alternative that meets the business NEED is often acceptable | Document constraints and agreed workaround

🏢 XYZ Company Example

At XYZ Company, developer said 'real-time stock on Opportunities not possible'. BA investigated: real-time via API callout was possible, or near-real-time via hourly sync was possible. Presented both options. Stakeholders chose hourly sync — implemented successfully.

📌 For Interviewer

Never accept 'not possible' without investigation | Find the specific constraint | Present options — never a dead end

🎤 "When a developer says 'not possible', the BA investigates the specific constraint and presents alternatives — never returns to the business with a dead end."

Q44

How do you measure success of a Salesforce implementation?

✅ Direct Answer

Measure against the original business objectives — not whether the system was deployed on time. KPIs: user adoption rate, time savings, error reduction, pipeline visibility improvement, ROI.

💡 Why?

A Salesforce go-live is NOT success — it's a milestone. Real success is users adopting it and business problems being solved.

Business Objective	Success Metric
Improve sales visibility	% of pipeline updated weekly
Reduce data entry time	Hours per week saved
Improve lead response	Average follow-up time (target under 4 hours)
User adoption	% of active users logging in weekly

🏢 XYZ Company Example

At XYZ Company, 3 months post go-live: Lead response time reduced from 3 days to 4 hours, pipeline visibility 100% (vs 0% on Excel), 34 hours/week saved on manual data entry. BA presented to leadership as proof of ROI.

📌 For Interviewer

Define success metrics BEFORE the project starts | Measure at 30, 60, 90 days post go-live | Adoption metrics matter as much as technical metrics

🎤 "Salesforce success is business outcomes — adoption, time savings, KPI improvements — not just whether the system went live on time."

Q45

What is your approach to onboarding new Salesforce users after go-live?

✅ Direct Answer

Create role-based training, visual quick reference guides, a support channel, internal champions, and monitor adoption metrics to identify who needs extra help.

💡 Why?

Training once and disappearing is the most common adoption failure. Users forget. New people join. Processes evolve. Plan for ongoing enablement.

🎯 Key Points

Role-based training beats generic every time | A champion in each team multiplies adoption | Track login rates and reach out to non-users proactively

🏢 XYZ Company Example

At XYZ Company post go-live: separate 30-minute sessions for reps, managers, and admins. 2-page visual cheat sheet per role. WhatsApp support group. 2 power users as internal champions. Adoption at 95% by week 3.

📌 For Interviewer

Role-based training | Internal champions | Monitor adoption and intervene early

🎤 "Effective Salesforce onboarding uses role-based training, visual guides, internal champions, and adoption monitoring — not a single session and hope for the best."

☁️

Salesforce Specific Knowledge

Q46-Q60 · A BA Who Knows Salesforce is Irreplaceable

Q46

What is the difference between a standard and custom object?

✅ Direct Answer

Standard objects are pre-built by Salesforce (Account, Contact, Opportunity, Lead, Case). Custom objects are created by the organization to store business-specific data (Visit_Report__c, Invoice__c).

🏢 XYZ Company Example

At XYZ Company, Accounts and Opportunities are standard. Visit_Report__c (field visits), Molecule_Tracking__c (R&D), Invoice__c (ERP integration) are custom objects built for XYZ's specific processes.

📌 For Interviewer

Standard objects have pre-built relationships | Custom objects need relationships designed | Both use the same security model

🎤 "Standard objects are Salesforce pre-built; custom objects are org-specific — both use the same configuration, security, and automation capabilities."

Q47

What is the difference between Lookup and Master-Detail relationship?

✅ Direct Answer

Lookup = loose relationship, child exists independently. Master-Detail = tight relationship, child cannot exist without parent, parent controls child sharing and deletion.

Aspect	Lookup	Master-Detail
Required?	Optional — independent child	Required — child needs parent
Delete parent	Lookup field cleared	Child deleted too
Rollup summary	Not supported	Supported
Max per object	25	2

🏢 XYZ Company Example

At XYZ Company, Visit_Report__c has Master-Detail to Opportunity (report must belong to an opp) and Lookup to Contact (the contact visited is optional). MD enables rollup of visit count on Opportunity.

📌 For Interviewer

Use MD when child has no meaning without parent | Use Lookup when relationship is optional | Only MD supports Rollup Summary

🎤 "Lookup is optional and flexible; Master-Detail is required and controls sharing, deletion, and rollup summaries."

Q48

When would you recommend Flow vs Apex Trigger?

✅ Direct Answer

Recommend Flow for simple declarative automation admins can maintain. Recommend Apex for complex logic, bulk operations, external callouts, and anything requiring governor limit management.

Scenario	Recommendation
Send email on stage change	Flow
Update a few fields on save	Flow
Complex bulk data processing	Apex Trigger
External API callout	Apex Trigger
Cross-object complex rules	Apex Trigger

🏢 XYZ Company Example

At XYZ Company, Visit Report status change sending email to manager = Flow (simple, admin-maintainable). Same event updating 3 objects, running currency conversion, logging to audit = Apex Trigger (complex, bulk-safe).

📌 For Interviewer

Salesforce best practice: declarative first, code second | Flows maintainable by admins — prefer for simple logic | Apex for bulk operations or API calls

🎤 "Recommend Flow for simple admin-maintainable automation; Apex for complex logic, bulk operations, or external API calls."

Q49

What are record types and when do you use them?

✅ Direct Answer

Record types allow different page layouts, picklist values, and business processes for different user groups on the same object.

🎯 Key Points

✅ Different page layouts per record type | ✅ Different picklist values | ✅ Different business processes | Controlled by Profile/Permission Set

🏢 XYZ Company Example

At XYZ Company, Account has 3 record types: Domestic_Customer (INR pricing fields), International_Customer (USD/EUR fields, Incoterms), Supplier (purchase-related fields). Same object, three different experiences.

📌 For Interviewer

Record types solve 'one object, different users' | Don't create just for page layout — use Dynamic Forms | Assign via profiles or permission sets

🎤 "Record types let one Salesforce object serve multiple user groups with different layouts, picklists, and processes — essential for diverse business units."

Q50

What is the difference between Profiles and Permission Sets?

✅ Direct Answer

Profile = baseline access for a user, one per user, required. Permission Set = additional access on top of profile, multiple per user, optional.

Aspect	Profile	Permission Set
Per user	One (required)	Multiple (optional)
Purpose	Baseline access	Additional access
Best for	Role-based base	Exceptions and extensions

🏢 XYZ Company Example

At XYZ Company, all sales reps have the Sales Rep profile (base access). Senior reps managing key accounts get a Senior Rep Permission Set adding Account deletion rights and advanced reporting.

📌 For Interviewer

Salesforce recommends fewer profiles, more permission sets | Never give everyone System Admin to solve access issues | Permission Set Groups bundle multiple sets

🎤 "Profiles define baseline access; Permission Sets grant additional access — together enabling precise, maintainable security."

Q51

What is OWD (Organization-Wide Defaults)?

✅ Direct Answer

OWD sets the default baseline sharing level for each object — Public Read/Write, Public Read Only, or Private. It's the most restrictive access level — sharing rules and roles open it up from there.

🎯 Key Points

OWD is the security foundation | Start with Private and open up — easier than the reverse | OWD changes can break existing access — test thoroughly

🏢 XYZ Company Example

At XYZ Company: Opportunity OWD = Private (reps only see their own pipeline). Account OWD = Public Read Only (everyone views but only owner edits). This protected pipeline data while allowing team-wide customer visibility.

📌 For Interviewer

Setting OWD correctly from the start is critical | Tightening later can break workflows | Helps BAs ask the right security requirement questions

🎤 "OWD sets the most restrictive sharing baseline — the foundation from which roles, sharing rules, and manual sharing expand access upward."

Q52

What is a validation rule and when would you recommend one?

✅ Direct Answer

A validation rule is a formula-based rule that prevents record saving if data doesn't meet specified criteria. Recommend when you need to enforce data quality at the entry point.

🎯 Key Points

✅ Fires on all saves — API, import, UI | ✅ Stops bad data at source | Write error messages in plain business language | Consider Flow for complex conditional validations

🏢 XYZ Company Example

At XYZ Company: validation rule — Opportunity Amount must be positive and cannot exceed ₹1Cr without Special_Approval__c flag. Enforced at every save, by every user, via every channel.

📌 For Interviewer

Validation rules fire everywhere including API and data loads | User-friendly error messages are critical for adoption | Works alongside required fields

🎤 "Validation rules enforce business data quality at the point of entry — preventing records from saving when they violate defined constraints."

Q53

What is the difference between a Report and a Dashboard?

✅ Direct Answer

Report = list or summary of records based on criteria. Dashboard = visual display of multiple reports — charts and metrics giving a business performance snapshot.

Aspect	Report	Dashboard
Shows	Detailed data or summaries	Visual charts from multiple reports
Best for	Detailed analysis, export	Executive overview, KPIs
Drill-down	Yes — individual records	Yes — clicks to source report

🏢 XYZ Company Example

At XYZ Company Sales Dashboard: 5 components — Opportunities by Stage, Revenue by Territory, Win Rate by Rep, Monthly Pipeline Trend, Top 5 Accounts. Each chart drills into its source report.

📌 For Interviewer

Dashboards cannot exist without reports — reports are data source | Dynamic Dashboards show each user their own data | Involve stakeholders in dashboard layout design

🎤 "Reports show detailed data; dashboards display multiple report charts — together providing overview and detail for business decision-making."

Q54

What is Experience Cloud and when would you recommend it?

✅ Direct Answer

Experience Cloud builds external-facing portals for customers, partners, or employees connected to Salesforce data — for users who need access without full Salesforce licenses.

🎯 Key Points

External portal, not internal Salesforce UI | Licensed separately | Great for customer self-service and partner management

🏢 XYZ Company Example

At XYZ Company, customer portal on Experience Cloud: customers view order status, download invoices, raise service cases, track delivery — without needing Salesforce licenses. Saved ₹15L/year in license costs.

📌 For Interviewer

External users get self-service access | More cost-effective than full Salesforce licenses for large external audiences

🎤 "Experience Cloud builds external portals connected to Salesforce data — eliminating the need for external users to have full Salesforce licenses."

Q55

What is the difference between Sales Cloud and Service Cloud?

✅ Direct Answer

Sales Cloud = sales process (leads, opportunities, quotes, forecasting). Service Cloud = customer service (cases, knowledge, SLA, omni-channel). Organizations often have both.

Aspect	Sales Cloud	Service Cloud
Users	Sales reps and managers	Support agents and managers
Core objects	Lead, Opportunity, Quote	Case, Knowledge, Entitlement
Goal	Close more deals	Resolve issues faster

🏢 XYZ Company Example

At XYZ Company: Sales Cloud manages lead-to-order. Service Cloud manages customer complaints with SLA timers ensuring resolution within 48 hours.

📌 For Interviewer

Both clouds share the same platform — data flows between them | A customer can have a Sales Cloud Opp AND Service Cloud Case | Match users to the right cloud license

🎤 "Sales Cloud manages sales from lead to close; Service Cloud manages customer support — both share the same platform and customer data."

Q56

What is a Sandbox and what are the different types?

✅ Direct Answer

A sandbox is a copy of a Salesforce org for development, testing, and training without affecting production. Types: Developer, Developer Pro, Partial Copy, Full Copy.

Type	Storage	Best For
Developer	200MB	Development and unit testing
Developer Pro	1GB	Complex development
Partial Copy	5GB	UAT with real data structure
Full Copy	Full match	Performance testing

🏢 XYZ Company Example

At XYZ Company: Developer sandbox for coding, Partial Copy for UAT, Full Copy before major releases for complete data volume testing.

📌 For Interviewer

Never develop or test in production | Refresh sandboxes before UAT | Full Copy is expensive — use sparingly

🎤 "Sandboxes are isolated org copies for development, testing, and training — ranging from Developer to Full Copy sandboxes that mirror production completely."

Q57

What is the BA role in data migration?

✅ Direct Answer

The BA defines what data migrates, from where, field mapping, data quality rules, and validation. Works with the data team and validates migrated data during UAT.

💡 Why?

Data migration is where most projects encounter the most surprises — dirty data, inconsistent formats, duplicates, missing fields.

🏢 XYZ Company Example

At XYZ Company, migrating 5 years of Excel data: BA created field mapping document, defined data quality rules (phone 10 digits, email has @), identified 2,300 duplicate accounts in source, validated 500 sample records after migration.

📌 For Interviewer

Data migration takes longer than expected — plan for it | Cleanse before migration, not after | Validate migrated data against source

🎤 "The BA defines migration requirements, field mapping, and quality rules — then validates the result to ensure nothing was lost or corrupted."

Q58

What is AppExchange and when would you recommend a managed package?

✅ Direct Answer

AppExchange is Salesforce's marketplace for pre-built apps and solutions. Recommend when a business need is common enough that a pre-built solution exists at lower cost than custom development.

🎯 Key Points

Always check AppExchange before recommending custom development | Does the package meet 80%+ of requirements out of the box? | Consider total cost: licensing + implementation + annual renewal

🏢 XYZ Company Example

At XYZ Company: e-signature requirement. Custom build: 3 sprints, ₹8L. DocuSign AppExchange: ₹3L/year, live in 1 week. Stakeholders chose AppExchange — faster, cheaper, vendor-maintained.

📌 For Interviewer

AppExchange first | Compare total cost of ownership | Evaluate fit before recommending

🎤 "AppExchange managed packages are recommended when a pre-built solution meets the business need at lower cost than custom development."

Q59

What is the BA role in a Salesforce deployment?

✅ Direct Answer

The BA defines what is in the release, communicates changes to users, coordinates UAT sign-off, writes release notes in plain language, and supports hypercare after deployment.

💡 Why?

Communication and change management around releases prevent the most common go-live failure: users surprised by system changes.

🎯 Key Points

Never deploy without communicating changes to users | Release notes in user language, not technical | Validate in production within 1 hour of deployment

🏢 XYZ Company Example

At XYZ Company, each sprint deployment: BA wrote a 'What's Changing' email 2 days before, 1-page change summary for managers, confirmed UAT sign-off, and was on a dedicated support channel for 48 hours post-deployment.

📌 For Interviewer

BA release role = communication + sign-off + hypercare | Users should never be surprised by a deployment

🎤 "The BA ensures deployments are smooth — communicating changes, confirming sign-off, and supporting hypercare — not just technically successful."

Q60

What Salesforce certifications are most valuable for a BA?

✅ Direct Answer

Priority: Salesforce Certified Business Analyst (most relevant), Salesforce Administrator (essential foundation), Salesforce Agile Specialist (valuable for Agile projects).

Certification	Value for BA	Priority
Salesforce Business Analyst	Directly validates BA skills	#1
Salesforce Administrator	Foundation — understand the platform	#2
Salesforce Agile Specialist	Agile methodology for SF projects	#3
Platform App Builder	Deeper config knowledge	Bonus

🏢 XYZ Company Example

At XYZ Company, BA certification was listed as preferred. Candidates with both Admin and BA certifications received 15% higher initial offers, reflecting the recognized value of combined knowledge.

📌 For Interviewer

Admin cert is prerequisite for BA cert | Trailhead Superbadges demonstrate practical skills | Certifications validate knowledge — experience validates capability

🎤 "The Salesforce BA certification is most directly relevant, with Admin as the foundation — together validating both domain and platform knowledge."

⚡

Agile, Scenarios & XYZ Company Questions

Q61-Q75 · Questions That Separate Great BAs from Good Ones

Q61

What is Agile and how does it apply to Salesforce projects?

✅ Direct Answer

Agile is an iterative approach — work done in short sprints delivering working functionality incrementally. In Salesforce, Agile means deploying features sprint by sprint rather than a big bang go-live.

💡 Why?

Agile works well for Salesforce because requirements evolve and stakeholders learn what they need by seeing early demos. A BA must be comfortable with change and continuous prioritization.

🏢 XYZ Company Example

At XYZ Company, 2-week sprints. Sprint 1: Account and Contact. Sprint 2: Opportunities and pipeline. Sprint 3: Reporting. Sprint 4: IndiaMART integration. Users got value every sprint, not after 6 months.

📌 For Interviewer

Agile requires continuous stakeholder involvement | User stories are the unit of work | Working software at end of every sprint

🎤 "Agile delivers Salesforce functionality in short sprints, allowing incremental validation — reducing risk and ensuring the solution evolves with business needs."

Q62

What happens in Sprint Planning and what is the BA's role?

✅ Direct Answer

Sprint Planning: team selects user stories from the backlog, estimates effort, and commits to sprint delivery. BA's role: ensure selected stories are fully written, acceptance criteria are clear, and dependencies identified.

🎯 Key Points

Stories should be sprint-ready before planning | Sprint commitment is the team's — not just the BA's | BA flags dependencies and blockers

🏢 XYZ Company Example

At XYZ Company Sprint Planning: PO presented top 10 backlog items. BA confirmed all had clear acceptance criteria. Team estimated story points. Agreed on 6 stories. BA flagged Story #4 depended on Story #7 — reordered to avoid blocking.

📌 For Interviewer

Sprint-ready stories = BA's primary Sprint Planning contribution | Dependency identification prevents sprint failures

🎤 "In Sprint Planning, the BA ensures user stories are fully written with clear acceptance criteria — preventing failures from unclear requirements."

Q63

What is Sprint Review vs Sprint Retrospective?

✅ Direct Answer

Sprint Review: team demonstrates completed work to stakeholders — focuses on the product. Sprint Retrospective: team reflects on how they worked together — focuses on the process.

Aspect	Sprint Review	Sprint Retrospective
Focus	What was built	How the team worked
Attendees	Team + stakeholders	Team only
Output	Feedback, backlog updates	Process improvement actions

🏢 XYZ Company Example

At XYZ Company Sprint 3: Review — Sales Director asked for an additional chart — added to backlog. Retrospective — too many mid-sprint changes this sprint — agreed to freeze requirements by day 3.

📌 For Interviewer

Sprint Review = working demo, not PowerPoint | Retro actions must be acted on | BA facilitates Review, Scrum Master facilitates Retro

🎤 "Sprint Review shows what was built; Sprint Retrospective is the team's internal reflection on how to improve."

Q64

What is velocity in Agile and how do you use it?

✅ Direct Answer

Velocity = average story points completed per sprint. Calculated over the last 3-5 sprints and used to forecast how many sprints are needed to complete the remaining backlog.

🎯 Key Points

Never use velocity to pressure the team to go faster | Use average, not best sprint | For planning, not performance measurement

🏢 XYZ Company Example

At XYZ Company, velocity = 24 story points per sprint. Remaining backlog = 96 points. Forecast: 4 sprints = 8 weeks. Used to give the business a realistic go-live date — not a guess.

📌 For Interviewer

Velocity enables honest timeline forecasting | Fluctuates naturally — use rolling average | Helps BA set realistic stakeholder expectations

🎤 "Velocity enables realistic forecasting — average story points per sprint divided into remaining backlog gives an honest timeline estimate."

Q65

What is the Definition of Done?

✅ Direct Answer

The DoD is a team-agreed checklist of criteria that must be met before any user story can be declared done. It prevents different team members having different standards of complete.

🎯 Key Points

🏢 XYZ Company Example

At XYZ Company, a story was marked done without tests or a demo. Implemented a formal DoD checklist — 8 items. Nothing moves to done without all 8 checked. Sprint quality improved from Sprint 4.

📌 For Interviewer

DoD agreed by the whole team | Applies to every story every sprint — no exceptions | Strong DoD reduces UAT defects significantly

🎤 "The Definition of Done is a team-agreed checklist ensuring consistent quality — preventing incomplete deliveries and UAT surprises."

Q66

XYZ Company: The sales team wants to track polymer sample requests. How do you approach this?

✅ Direct Answer

Start with stakeholder interviews to understand the current process and pain points. Map As-Is, identify gaps, design To-Be, write user stories, and validate with a prototype before development.

🎯 Key Points

Interview ALL parties — not just the requestor | Observe the current process — don't just ask about it | Demo a prototype before development

🏢 XYZ Company Example

BA interviewed 3 sales reps, 1 lab manager, 1 logistics person. Found: tracked in WhatsApp and Excel — no visibility, samples going missing. Designed: custom Sample_Request__c with status workflow, email notifications, and a management dashboard. Validated in sandbox before sprint.

📌 For Interviewer

Discovery first, design second | Prototype validation catches 80% of misunderstandings | Include all impacted departments

🎤 "A new requirement starts with discovery — interviewing all stakeholders, mapping the process, and validating a prototype — before any development begins."

Q67

XYZ Company: Stakeholders disagree on Lead classification — Sales wants by product, Marketing wants by region. How do you resolve this?

✅ Direct Answer

Facilitate a joint workshop. Understand the underlying business need for each position. Explore if both can coexist. Present options to the sponsor if no consensus.

🎯 Key Points

Bring both parties together | Find the AND, not the OR | Document the decision

🏢 XYZ Company Example

BA facilitated a 2-hour workshop: Sales needed product-based grouping for rep assignment. Marketing needed region-based for campaign targeting. Solution: TWO fields — Product_Interest__c and Lead_Region__c. Both teams satisfied.

📌 For Interviewer

Joint workshop accelerates resolution | Explore AND solutions before forcing OR | Get written agreement on the decision

🎤 "Stakeholder conflicts resolve by understanding each position's underlying need and finding solutions that address both — often AND is better than OR."

Q68

XYZ Company: A deployed Flow is causing data corruption in production. What is your role?

✅ Direct Answer

Immediately communicate to stakeholders. Document the exact impact. Coordinate with development for emergency fix. Manage communications throughout. Post-incident: root cause analysis to prevent recurrence.

🎯 Key Points

Speed of communication matters | Data correction as important as the fix | Root cause analysis prevents recurrence — don't skip it

🏢 XYZ Company Example

At XYZ Company, a Stage Change Flow incorrectly updated Account Annual Revenue on every Opportunity save. BA: notified MD and IT immediately, identified 47 affected Accounts, coordinated 2-hour emergency fix, sent team workaround, organized data correction, ran post-mortem — missing test case was root cause. Added to DoD.

📌 For Interviewer

Communicate first, understand fully second | Fix the data, not just the Flow | Post-mortem is non-optional

🎤 "In a production incident, the BA coordinates communication, documents impact, supports the fix, and drives root cause analysis to prevent recurrence."

Q69

XYZ Company: Management wants a real-time dashboard of international sales. How do you approach this?

✅ Direct Answer

Clarify 'real-time', understand what metrics matter, identify the data source, design with stakeholders, and validate with a prototype.

🎯 Key Points

Clarify ambiguous terms before designing | Check if Salesforce already has the data before designing integrations | Prototype dashboard layout with stakeholders

🏢 XYZ Company Example

BA clarified: 'real-time' meant 'updated same day' — 15-minute delay acceptable. Metrics: Pipeline by country, Monthly revenue by country, Win rate by international rep. All data in Salesforce. Solution: Dashboard with 4 components, hourly refresh. Delivered in 1 sprint — no ERP integration needed.

📌 For Interviewer

Always clarify 'real-time' — it almost always means 'frequently enough' | Check data availability before designing | Prototype first

🎤 "Ambiguous requirements like 'real-time dashboard' need clarification — defining actual metrics and refresh frequency prevents over-engineering."

Q70

How would you write a user story for an automated email notification?

✅ Direct Answer

As a [role], I want [notification], so that [action I can take]. Plus acceptance criteria covering: trigger condition, recipient, email content, timing, and edge cases.

🎯 Key Points

Specify recipient precisely | Define timing quantitatively | Include edge case handling — what if a field is blank?

🏢 XYZ Company Example

User Story: 'As a sales manager, I want an email when any team Opportunity moves to Closed Won, so I can congratulate the rep immediately.' Criteria: Email within 5 minutes. Contains Opp name, amount, rep name, close date. Goes to direct manager. If manager blank, goes to default sales email.

📌 For Interviewer

Vague requirements lead to wrong automations | Always include the 'what if' scenario | Timing must be quantified not estimated

🎤 "Email notification stories need precise acceptance criteria: trigger, recipient, content, timing, and edge cases — vagueness leads to wrong automations."

Q71

What is the most important skill a Salesforce BA needs in 2026?

✅ Direct Answer

The ability to translate ambiguity into clarity — converting vague, contradictory stakeholder inputs into precise, testable requirements that a developer can build and a user can validate.

🎯 Key Points

Technical knowledge helps but communication skills drive outcomes | Asking the right question is more valuable than knowing the right answer | 2026 addition: understand AI/Agentforce automation opportunities

🏢 XYZ Company Example

At XYZ Company, the initial requirement was 'we need better reporting'. After 3 workshops, BA translated this into 47 specific user stories across 8 modules — pipeline, territory performance, customer health, integration reporting. 'Better reporting' had no meaning. 47 user stories built a ₹2Cr revenue intelligence system.

📌 For Interviewer

The most critical skill is translating ambiguity | Technology skills support this — they don't replace it

🎤 "The most critical BA skill is translating ambiguity into clarity — converting vague needs into precise, testable requirements that build the right solution."

Q72

How do you stay current with Salesforce releases?

✅ Direct Answer

Follow Salesforce Release Notes, Salesforce Ben, and Trailhead Release Highlights. Attend release webinars. Review new features before each project phase.

🎯 Key Points

Salesforce releases 3 times per year | Release Notes published 4-6 weeks before go-live | New features can eliminate custom development

🏢 XYZ Company Example

At XYZ Company, Spring 2026 release added Dynamic Forms to mobile. BA reviewed 4 weeks before, identified it could replace a custom LWC for mobile visit tracking — saving 1 sprint. Incorporated before the sprint was planned.

📌 For Interviewer

Review release notes proactively | New features can simplify requirements | BA who knows platform possibilities adds enormous value

🎤 "Staying current with 3 annual releases means proactively reviewing notes and incorporating new capabilities — often eliminating the need for custom development."

Q73

XYZ Company: A major customer complained about slow case resolution. How do you improve this?

✅ Direct Answer

Map the current process, identify where time is lost, and design a Service Cloud solution with auto-routing, SLA timers, escalation rules, and a knowledge base.

🎯 Key Points

Measure current state before designing | Root cause prevents fixing symptoms | Knowledge base reduces repeat cases

🏢 XYZ Company Example

BA discovery: average resolution 5 days. Root cause: 40% in routing (wrong team), 30% in missing info (back-and-forth), 30% actual resolution. Solution: Omni-Channel routing, required fields at creation, 48-hour SLA escalation, knowledge base articles. Result: 5 days → 1.5 days.

📌 For Interviewer

Measure before you design | Root cause analysis is non-optional | Quick wins build stakeholder trust

🎤 "Slow case resolution improves by mapping where time is lost then designing targeted Salesforce automations for routing, information, escalation, and knowledge."

Q74

What are the 3 biggest mistakes Salesforce BAs make?

✅ Direct Answer

1) Requirements validated with only one stakeholder. 2) No acceptance criteria on user stories. 3) Rubber-stamp UAT — not a genuine quality gate.

Mistake	Consequence	Prevention
One-stakeholder requirements	Others reject in UAT	Multi-stakeholder reviews
No acceptance criteria	Wrong thing built, rework cycle	Mandatory criteria before sprint
Rubber-stamp UAT	Production defects, lost trust	Real users, real data, real scenarios

🏢 XYZ Company Example

At XYZ Company Phase 1: requirements validated only with Sales Director. Operations raised 12 UAT defects catchable at requirements. Phase 2: BA ran workshops with all 5 departments. UAT had 2 defects.

📌 For Interviewer

These patterns repeat across every failed project | Awareness prevents repetition | Cost of fixing each multiplies 10x per stage

🎤 "The 3 biggest BA mistakes — single-stakeholder requirements, missing acceptance criteria, rubber-stamp UAT — cause the majority of Salesforce project rework."

Q75

What separates a good Salesforce BA from a great one?

✅ Direct Answer

A good BA gathers requirements correctly. A great BA understands the business deeply enough to challenge poor requirements and anticipate needs stakeholders haven't articulated yet.

🎯 Key Points

Deep business understanding beats deep Salesforce knowledge long-term | Great BAs ask 'should we build this?' not just 'how?' | The ability to say 'I don't think that's right' with evidence is a superpower

🏢 XYZ Company Example

At XYZ Company, a good BA would have built what the sales team asked. The actual BA noticed 70% of use cases were mobile (field sales) and redesigned for mobile-first before development. Stakeholders never thought to ask. Result: 94% mobile adoption vs 40% industry average.

📌 For Interviewer

Builds what was needed, not just what was asked | Challenges assumptions with evidence | Anticipates requirements before they're articulated

🎤 "A good BA builds what was asked; a great BA builds what was needed — by understanding the business deeply enough to anticipate requirements before they're voiced."

Related Interview Prep

Apex Triggers Part 1 Apex Triggers Part 2 — Code Flow Interview Questions 100 Scenario Questions Free Agentforce Course Free DevOps Course

sfinterviewpro.com

1,200+ questions across 18 topics. 3 free courses. Always free. No paywall. No signup.

All Topics Free Courses