Flipkart Salesforce Interview Questions 2026 — Bharat Scale + Technical + Behavioral | SF Interview Pro
📅 Flipcart
🛒 Flipkart Interview Prep
Salesforce at Flipkart — Complete Interview Prep 2026
Bharat-First Culture + E-Commerce Scale Architecture + COD/Pincode Scenarios + 15 Technical Deep Dives + Salary Guide. Everything to crack Flipkart Salesforce interviews.
70+Questions
7Bharat Values
15Tech Scenarios
100%Free
⚠️
Note: This guide is based on Flipkart's publicly available culture values, widely documented interview process (Glassdoor, AmbitionBox, LinkedIn), and logical Salesforce scenarios for Flipkart's e-commerce scale. Not leaked internal content — structured preparation based on public knowledge.
⚡ Complete Index
1How Flipkart Uses Salesforce
2Salesforce Roles at Flipkart
3Interview Round Structure
4Bharat Value: Scale Thinking
5Bharat Value: Customer Obsession
6Bharat Value: Bias for Action
7Bharat Value: Data-Driven
8Bharat Value: Ownership
9Bharat Value: Inclusion
10Bharat Value: Frugality
11Tech: Bulk Seller Batch Apex
12Tech: COD Workflow Automation
13Tech: Pincode Territory Management
14Tech: Big Billion Days Architecture
15Tech: Multi-Language Data Handling
16Tech: Microservices Integration
17Tech: Dispute Auto-Routing
18Tech: Seller Scorecard Design
19Tech: Returns Policy Automation
20Tech: Seller Ecosystem Data Model
21Tech: Queueable Chain Pattern
22Tech: Experience Cloud Seller Portal
23Tech: Einstein Analytics Dashboard
24Tech: Named Credential + HTTP Callout
25Tech: Trigger Framework + Bulkification
26Behavioral: Scale Impact Story
27Behavioral: Bias for Action
28Behavioral: Cross-Team Conflict
29Scenario: Design Seller CRM
30Scenario: 48-Hr BBD Prep
31Salary Guide 2026
3210 Tips to Crack Flipkart
🛒
How Flipkart Uses Salesforce
India's largest e-commerce company + Salesforce = Bharat-scale CRM challenges
🛒
Flipkart Group — Company Profile
Founded 2007 · Walmart Group · Bengaluru, India
Active Sellers
500,000+ registered sellers on marketplace
Annual Users
350M+ registered customers across India
Salesforce Use
Seller CRM, B2B relationships, supply chain partners
Key Challenge
Managing 500K sellers + COD complexity + 19K+ pincodes
Group Companies
Flipkart, Myntra, Flipkart Quick, Cleartrip, Shopsy
Salesforce Roles
Admin, Developer, Architect, Integration Engineer
👷
Salesforce Roles at Flipkart
What each role focuses on in Flipkart's seller ecosystem
| Role | Focus Area | Key Skills Expected |
|---|---|---|
| Salesforce Admin | Seller onboarding workflows, dispute queues, compliance tracking | Flows, Assignment Rules, Reports, Einstein Analytics |
| Salesforce Developer | Bulk seller data processing, API integration with internal microservices | Apex (Batch/Queueable), REST/SOAP, Platform Events, LWC |
| Salesforce Architect | CRM architecture for 500K+ seller ecosystem, multi-region design | Data Model Design, Integration Patterns, Performance at Scale |
| Integration Engineer | Salesforce ↔ Flipkart microservices (Order, Logistics, Payments) | MuleSoft/middleware, Kafka, REST APIs, Named Credentials |
| CRM Analytics Engineer | Seller performance dashboards, Einstein Analytics, data pipelines | CRM Analytics, SOQL, Reports, Tableau, SQL |
🎯
Interview Round Structure
Typical Flipkart Salesforce process — 4 to 5 rounds
Round 1
Recruiter / HR Screen
Background, CTC expectations, notice period, Salesforce experience overview
HRBackground
Round 2
Technical Phone Screen
Salesforce fundamentals, Apex, governor limits, data model, basic scenario questions
ApexGovernor LimitsSOQL
Round 3
Technical Deep Dive
Scale architecture, bulk processing, integration design, Bharat-specific technical challenges
ArchitectureBulk ApexIntegration
Round 4
Scenario / Case Study
Design Salesforce solution for a Flipkart problem — seller onboarding, dispute resolution, Big Billion Days
System DesignTrade-offs
Round 5
Culture Fit / Leadership
Behavioral questions around Flipkart's Bharat-first values, ownership, data-driven decisions
Bharat ValuesBehavioral
🇮🇳
Bharat-First Values — Culture Round Prep
7 values Flipkart assesses in behavioral rounds — with Salesforce context for each
01
Scale Thinking — Bharat Scale or Nothing
What It Means
At Flipkart, everything must work for 350M users, 500K sellers, and 10x traffic spikes during Big Billion Days. Your Salesforce solution must be designed for this scale from day one.
In Salesforce Context
Bulkified Apex (200-record chunks), Batch jobs for mass seller updates, Platform Events for async microservice communication, selective SOQL with indexes. Never write code that breaks at 201 records.
Sample Interview Question
"We need to update the status of 800,000 seller accounts when our compliance policy changes. How would you design this in Salesforce?"
02
Customer Obsession — Seller is the Customer
What It Means
At Flipkart, the seller IS the customer. Every CRM decision must reduce friction for sellers — especially small kirana-style sellers in Tier 2/3 cities who may have limited digital literacy.
In Salesforce Context
Simplified Experience Cloud portals, auto-populated fields (reduce manual entry), WhatsApp integration for seller notifications, vernacular language support in case descriptions.
Sample Interview Question
"A small seller in Patna is complaining the Salesforce portal is too complex. How would you redesign the experience?"
03
Bias for Action — Ship Fast, Fix Fast
What It Means
Flipkart moves fast. Waiting 3 months for a perfect solution is worse than shipping something good in 3 weeks. Make decisions with 70% information and iterate.
In Salesforce Context
Build MVP with Flows first, then Apex if needed. Feature flags via Custom Metadata for quick rollbacks. Deploy to sandbox → test → production without waiting for perfect specs.
Sample Interview Question
"Big Billion Days is in 2 weeks and we need a real-time seller performance dashboard. What's your plan?"
04
Data-Driven Decisions — Numbers over Opinions
What It Means
Every Flipkart decision must be backed by data. Opinions are starting points, not conclusions. When designing Salesforce solutions, always ask: How will we measure success?
In Salesforce Context
Dashboards before features (measure what matters), Einstein Analytics for seller behavior insights, custom KPI fields on Account — Dispute Rate, On-Time Delivery %, COD Confirmation Rate.
Sample Interview Question
"How would you design a Salesforce system that helps the business decide which sellers to promote vs delist?"
05
Ownership — You Own End-to-End
What It Means
At Flipkart, you don't just deliver a feature — you own it. That means writing the code AND monitoring it in production, handling the 3 AM alert AND fixing the root cause next day.
In Salesforce Context
Setting up AsyncApexJob failure monitoring, writing comprehensive test classes with real assertions, documenting post-deployment runbooks, fixing technical debt you created.
Sample Interview Question
"Your Batch Apex job failed silently over the weekend and 10,000 seller records have wrong status. How do you own this?"
06
Inclusion — Built for Every Indian
What It Means
Flipkart serves every Indian — not just English-speaking metro users. Your Salesforce solution must work for a seller in Tamil Nadu who speaks only Tamil, or a buyer in UP on a 2G connection.
In Salesforce Context
Multi-language field support (Unicode for Hindi/Tamil/Telugu addresses), lightweight LWC components for low bandwidth, Translation Workbench for seller portal UI labels, accessible WCAG-compliant UI.
Sample Interview Question
"Seller addresses come in mixed Hindi and English. How would you handle this in Salesforce data model and validation?"
07
Frugality — Do More with Less
What It Means
Flipkart optimizes for cost-efficiency. Don't buy an AppExchange package if you can build it in 2 days. Don't add 10 custom objects when 3 will do. Simplicity is a feature.
In Salesforce Context
Prefer standard objects over custom (avoid license cost), use Flows before Apex (no code maintenance), keep data model lean, reuse existing fields before creating new ones.
Sample Interview Question
"We have a Rs 50 lakh budget for a Salesforce implementation that originally required Rs 1.2 crore. What do you cut and what do you keep?"
⚙️
Technical Questions — 15 Bharat Scale Scenarios
Real Salesforce technical challenges unique to Flipkart's e-commerce ecosystem — with full code
Tech Q1Batch ApexScale🔥 Most Asked
Flipkart has 500,000 seller accounts. A new compliance policy requires updating Seller_Status__c based on 5 business rules. How do you design and execute this bulk update?
✅ Database.Batchable Apex processing 200 sellers per batch using Database.Stateful to track errors, with a Scheduled Apex trigger at 2 AM IST. Never a single synchronous operation on 500K records.
🔑 Key Design Points
• Batch Apex only: Only option for 500K records. Each execute() call gets fresh governor limits• Database.Stateful: Track errorCount and failedIds across all batches
• Database.update(scope, false): allOrNone=false — partial success per batch
• Off-peak scheduling: 2 AM IST when seller portal traffic is near zero
• finish() notification: Email Ops team — X succeeded, Y failed, Z skipped
• Error logging: Insert Error_Log__c for failed accounts for manual review
public class SellerComplianceBatch implements Database.Batchable<sObject>, Database.Stateful {
public Integer errorCount = 0;
public List<Id> failedIds = new List<Id>();
public Database.QueryLocator start(Database.BatchableContext bc) {
// Selective SOQL — index on RecordType + IsActive reduces scan
return Database.getQueryLocator(
'SELECT Id, Seller_Status__c, GST_Verified__c, KYC_Status__c ' +
'FROM Account WHERE RecordType.Name = \'Seller\' AND IsActive__c = true'
);
}
public void execute(Database.BatchableContext bc, List<Account> scope) {
for(Account a : scope) {
a.Seller_Status__c = SellerComplianceHelper.evaluate(a);
}
List<Database.SaveResult> results = Database.update(scope, false);
for(Integer i = 0; i < results.size(); i++) {
if(!results[i].isSuccess()) {
errorCount++;
failedIds.add(scope[i].Id);
}
}
}
public void finish(Database.BatchableContext bc) {
Messaging.SingleEmailMessage mail = new Messaging.SingleEmailMessage();
mail.setPlainTextBody('Batch complete. Errors: ' + errorCount);
Messaging.sendEmail(new Messaging.SingleEmailMessage[]{mail});
}
}
// Schedule for 2 AM IST
System.schedule('Seller Compliance', '0 0 2 * * ?', new SellerComplianceBatch());
🏭 Real World at Flipkart Scale
At 200 records/batch, 500K sellers = 2,500 execute() calls. Each call gets fresh limits. At 2 AM IST, the batch runs across ~3-4 hours. The Ops team gets an email by 6 AM with success/failure summary before the business day starts.
💡 "For 500K records I use Database.Batchable with Database.Stateful to track errors, process 200 per batch with allOrNone=false for partial success, and schedule at 2 AM IST — never a synchronous operation."
Tech Q2FlowIndia-Specific🇮🇳 Unique
For COD (Cash on Delivery) orders, sellers must confirm availability within 2 hours or the order auto-cancels. How would you design this automated workflow in Salesforce?
✅ Record-Triggered Flow on Order__c creation where Payment_Type__c = 'COD' — Scheduled Path waits 2 hours, checks Seller_Confirmation__c, auto-cancels if false. Platform Event notifies logistics asynchronously.
🔑 COD Flow Design
• Trigger: Record-Triggered Flow fires when Payment_Type__c = 'COD' AND Status = 'Placed'• Scheduled Path: 2-hour delay → IF Seller_Confirmation__c = false → update Status = 'Auto-Cancelled'
• 90-min escalation: Second scheduled path at 90 min → notification to Seller Relationship Manager
• Platform Event: Publish COD_Confirmation_Event__e → Logistics system subscribes and releases slot
• WhatsApp alert: Seller notification via custom action (not just email — most sellers use WhatsApp)
• Reporting: COD confirmation rate tracked on Seller Scorecard — affects seller search ranking
| Scenario | Salesforce Action | Downstream Effect |
|---|---|---|
| COD order placed | Flow triggered, 2-hr timer starts | WhatsApp notification to seller |
| Seller confirms <2 hrs | Seller_Confirmation__c = true, flow exits | Platform Event → Logistics assigns delivery |
| No confirm in 90 min | Escalation alert to SRM | SRM calls seller directly |
| No confirm in 2 hrs | Status = Auto-Cancelled | Customer notified, slot released |
🏭 Why COD is Uniquely Indian
~40-50% of Flipkart orders are still COD, especially in Tier 2/3 cities. Unlike US e-commerce where everything is prepaid, Flipkart needs this confirmation workflow running at millions of orders per day. Sellers with low COD confirmation rates get penalized in search ranking — all tracked in Salesforce.
💡 "For COD confirmation I use a Record-Triggered Flow with Scheduled Path for the 2-hour auto-cancel, a 90-minute escalation to the SRM, and a Platform Event to notify logistics — COD confirmation rate feeds back to the Seller Scorecard."
Tech Q3Territory MgmtIndia-Specific🇮🇳 Unique
Flipkart operates across 19,000+ pin codes in India. Seller Relationship Managers (SRMs) are assigned by pin code clusters. Design Salesforce Territory Management for this scale.
✅ Enterprise Territory Management with 4-level hierarchy (Zone → State → District → Pin Code Cluster), a custom Pin_Code_Territory__c mapping object, and rule-based assignment that auto-routes sellers to the correct SRM when their pin code is captured.
🔑 Territory Design for 19K+ Pin Codes
• Hierarchy: Zone (5) → State (28) → District (750+) → Pin Code Cluster (190 clusters of 100-200 pins each)• Custom Object: Pin_Code_Territory__c — maps each pin code to a Territory record
• Rule-Based Assignment: Account.BillingPostalCode set → Apex lookup of Pin_Code_Territory__c → assign Territory → SRM auto-assigned
• Data sync: India Post updates pin codes quarterly — Scheduled Batch Apex syncs via internal API
• SRM reassignment: When SRM leaves, Territory reassignment workflow moves all sellers to new SRM automatically
• Challenge: Pin codes don't follow neat geographic boundaries — one district may have 50-200 pins
| Level | Example | Count | Assigned To |
|---|---|---|---|
| Zone | West India | 5 | Regional VP |
| State | Maharashtra | 28 | State Head |
| District | Pune District | 750+ | District Manager |
| Pin Code Cluster | 411001–411030 | ~190 clusters | SRM (Seller RM) |
💡 "For 19K+ pin codes I use Enterprise Territory Management with a 4-level hierarchy, a custom Pin_Code_Territory__c mapping object, and Apex-triggered rule-based assignment on Account creation — with quarterly Batch sync from India Post API."
Tech Q4ScaleArchitecture🔥 Hot
During Big Billion Days, order volume spikes 10x. Your Salesforce automation handles seller dispute cases. How do you prevent Salesforce from hitting governor limits and becoming a bottleneck?
✅ Decouple Salesforce from real-time order flow using Platform Events as a buffer — microservices publish events, Salesforce subscribes asynchronously, Queueable Apex processes in controlled batches, Custom Metadata BBD_Mode flag switches to lightweight automation.
🔑 Big Billion Days Architecture
• Decouple: Never call Salesforce API synchronously from the order processing path during BBD• Platform Events: Order system publishes Dispute_Event__e → Salesforce trigger → Queueable processes async
• BBD_Mode flag: Custom Metadata Boolean — when true, disables non-critical Flows and automation
• Priority queuing: Payment disputes (P1) processed first, listing disputes (P3) queued for post-BBD
• Circuit breaker: If Limits.getDMLRows() > 80% consumed in Queueable, chain stops and re-queues
• Pre-BBD (48 hrs before): Archive old cases, pre-warm event subscribers, test with 10x simulated load in sandbox
| Normal Day | Big Billion Days | Design Change |
|---|---|---|
| 10K cases/day | 100K+ cases/day | Platform Events buffer queue |
| Sync API calls | Async Queueable chains | No blocking the order system |
| All automation active | BBD_Mode = true (lite mode) | Only critical flows run |
| Normal processing order | Priority queue by case type | P1 first, P3 deferred |
💡 "During BBD I decouple with Platform Events as a buffer, switch to BBD_Mode via Custom Metadata to disable non-critical automation, use priority Queueable chains for controlled case processing, and archive old data 48 hours before — Salesforce processes at its own pace without blocking the order system."
Tech Q5Data Model🇮🇳 Unique
Seller addresses and product descriptions come in Hindi, Tamil, Telugu, Kannada and English — sometimes mixed in the same field. How do you handle multi-language data in Salesforce?
✅ Salesforce natively supports Unicode (UTF-8) so Hindi/Tamil/Telugu stores correctly. Strategy: generous field sizing for multi-byte chars, Unicode-aware REGEX validation, separate English and regional address fields, Translation Workbench for seller portal UI.
🔑 Multi-Language Handling
• Storage: Text fields support Unicode natively — no encoding changes needed for Indian scripts• Field size: Unicode chars are 2-4 bytes — a 255-char field may not hold 255 Hindi characters. Size fields at 2x
• Validation: Use REGEX() with Unicode ranges: avoid English-only patterns like [a-zA-Z] on address fields
• Separate fields: Store Address_English__c AND Address_Regional__c — English for system integration, regional for display
• Translation Workbench: Field labels and Help Text translated to Hindi/Tamil/Telugu for seller portal
• Search: SOQL LIKE works with Unicode. For full-text cross-language search, External Objects with Elasticsearch
🏭 Real Flipkart Data Challenge
A saree seller from Varanasi enters their shop name as "रेशम साड़ी भंडार" — this must store in Salesforce, display correctly on the seller portal, AND be searchable by SRMs. The logistics integration also needs the address to map to India Post pin codes. Separate English and regional fields solve this cleanly.
💡 "Salesforce natively stores Unicode — I use generous field lengths, Unicode-aware REGEX validation, separate English and regional language address fields, and Translation Workbench for seller portal labels. For full-text search I use External Objects with Elasticsearch."
Tech Q6IntegrationMicroservices
Flipkart's internal stack is microservices-based (Order Service, Inventory Service, Payments, Logistics). Design Salesforce integration with this microservices architecture.
✅ Event-driven integration — Flipkart microservices publish to Kafka, a middleware consumer calls Salesforce REST API inbound. Salesforce publishes Platform Events for outbound triggers. External IDs on every object enable idempotent upserts without SOQL lookups.
🔑 Integration Architecture
• Inbound (Microservice → SF): Kafka topic → Consumer service → Salesforce REST API upsert using External_ID__c → Named Credentials for OAuth• Outbound (SF → Microservice): Platform Event published → Trigger subscriber → Queueable callout → REST endpoint with Named Credential
• External IDs: Every SF record has External_ID__c matching microservice's internal ID — upsert with no prior lookup needed
• Idempotency: All upserts are safe to replay — duplicate Kafka events won't create duplicate records
• Error handling: Failed callout → retry Queueable (max 3 retries) → Error_Log__c + Slack alert
• API versioning: Always use /v1/, /v2/ endpoints — microservices evolve independently
| Microservice | Direction | SF Object | Pattern |
|---|---|---|---|
| Order Service | Microservice → SF | Order__c | Kafka → REST upsert |
| Seller Service | Bidirectional | Account (Seller) | Platform Events + REST |
| Logistics Service | SF → Microservice | Case (Dispute) | Platform Event trigger |
| Payments Service | Microservice → SF | Payment__c | Webhook → REST API |
💡 "For Flipkart's microservices I use event-driven integration — Kafka events consumed by middleware calling Salesforce REST API inbound, Platform Events with Queueable callouts outbound — External IDs on every object enable idempotent upserts."
Tech Q7Service Cloud50K Cases/Day
Flipkart receives 50,000+ seller dispute cases per day. Design an auto-routing and priority-based resolution system in Salesforce Service Cloud.
✅ Einstein Case Classification auto-categorizes disputes, criteria-based Assignment Rules route to specialist queues, Omni-Channel with skill-based routing distributes within queues, Entitlement SLAs enforce response times, and a Flow auto-resolves small-value disputes without human review.
🔑 Dispute Resolution Architecture
• Auto-classification: Einstein Case Classification predicts Dispute_Category__c (Return Fraud, Payment Delay, Listing Error, Logistics Damage) from case description — 85%+ accuracy after training• Assignment Rules: Payment cases → Finance Queue, Listing errors → Catalog Queue, Logistics → Ops Queue
• Omni-Channel: Skill-based routing within queues — agents with "Logistics" skill get logistics cases first
• Entitlement SLAs: P1 (Payment): 4-hr response, P2 (Returns): 24-hr, P3 (Listing): 72-hr. Milestone alerts if approaching breach
• Auto-resolution Flow: Dispute_Amount__c < Rs 500 AND policy clearly violated → auto-resolve + issue credit → eliminates ~30% of case volume
• Seller portal: Experience Cloud self-service — sellers track case, upload evidence, see resolution ETA
💡 "For 50K daily disputes: Einstein Classification for auto-categorization, Assignment Rules for queue routing, Omni-Channel skill-based distribution, Entitlement SLA milestones, and a Flow that auto-resolves small-value cases — eliminating ~30% of volume without human review."
Tech Q8AnalyticsKPI Dashboard
Design a real-time Seller Performance Scorecard in Salesforce tracking: Order Fulfillment Rate, COD Confirmation Rate, Return Rate, Dispute Rate, and Customer Rating — with automated flagging of underperformers.
✅ Seller_Scorecard__c custom object updated nightly by Batch Apex aggregating child records. Composite Seller_Score__c formula (0-100 weighted). Weekly scheduled Flow flags sellers below threshold and auto-creates SRM review Case.
🔑 Scorecard Data Model + Formula
• Object: Seller_Scorecard__c — one record per seller per week. Lookup to Account• Composite Score: (Fulfillment×30) + (COD_Rate×20) + ((1−Return_Rate)×20) + ((1−Dispute_Rate)×20) + (Rating/5×10) = 0-100
• Batch Apex nightly: Aggregate Order__c, Case__c, Rating__c per seller → upsert Seller_Scorecard__c
• Scheduled Flow weekly: Query scorecards where Seller_Score__c < 60 → create Review_Case__c assigned to SRM
• 3-week rule: Score < 40 for 3 consecutive weeks → Suspension_Warning__c = true → Compliance team notified
• CRM Analytics: Dashboard showing score trends, geographic at-risk seller map, distribution histogram
| KPI | Weight | Source | Alert Threshold |
|---|---|---|---|
| Order Fulfillment Rate | 30% | Order__c aggregate | < 90% |
| COD Confirmation Rate | 20% | Order__c (COD only) | < 85% |
| Return Rate | 20% | Return__c aggregate | > 15% |
| Dispute Rate | 20% | Case aggregate | > 5% |
| Customer Rating | 10% | Rating__c average | < 3.5 / 5 |
💡 "Seller Scorecard = Seller_Scorecard__c updated nightly by Batch Apex, weighted 0-100 composite formula, weekly Flow auto-creates review Cases for sub-60 sellers, 3-week consecutive low score triggers suspension warning — visualized in CRM Analytics with geographic distribution map."
Tech Q9FlowCustom Metadata
Flipkart has complex return policies — 7-day for electronics, 30-day for apparel, no return for perishables, seller-specific overrides. How do you automate returns eligibility and refund workflow in Salesforce?
✅ Custom Metadata Types for return policy configuration (no hardcoding), Record-Triggered Flow calculates eligibility by querying policy and comparing order date, seller overrides checked first, approved returns create Refund_Request__c that triggers Platform Event to Payments microservice.
🔑 Returns Automation Design
• Custom Metadata (Return_Policy__mdt): Category__c, Return_Window_Days__c, Is_Returnable__c. No hardcoding — Ops team can update without deployment• Flow logic: Return_Request__c created → get Product Category from related Order → query Return_Policy__mdt → Days_Since_Order = TODAY() − Order_Date__c
• Eligibility: IF Days_Since_Order ≤ Return_Window_Days AND Is_Returnable → Approved ELSE Rejected
• Seller override: Check Seller.Custom_Return_Policy__c first — sellers can EXTEND (not restrict) standard window
• Approved: Create Refund_Request__c → Finance Queue → Platform Event → Payments microservice
• Rejected: Auto-email with policy reason → Case created if customer escalates
🏭 Why Custom Metadata — Not Hardcoding
During Big Billion Days, Flipkart extends return windows (10 days for electronics). During partnership events, specific seller categories get custom policies. Custom Metadata lets Ops update return windows without a Change Set deployment — changes take effect in minutes.
💡 "Return eligibility uses Custom Metadata for policy config, a Record-Triggered Flow calculates eligibility, seller-specific overrides checked first, approved returns create Refund_Request__c triggering Platform Events to the Payments microservice — Ops can change policy windows without code deployment."
Tech Q10Data ModelArchitecture
Design the complete Salesforce data model for Flipkart's seller ecosystem — seller onboarding, catalog, orders, disputes, and performance tracking.
✅ Account (Seller) as the hub with 3 RecordTypes for seller tiers, Master-Detail Order__c for cascade deletion, standard Case with dispute RecordTypes, Seller_Scorecard__c for weekly KPI snapshots — all connected via External IDs for microservice integration.
| Object | Type | Relationship | Key Custom Fields |
|---|---|---|---|
| Account (Seller) | Standard | Hub | GST_Number__c, Seller_Tier__c, Pin_Code__c, Regional_Language__c |
| Order__c | Custom | MD → Account | Payment_Type__c, COD_Confirmation__c, External_Order_ID__c, Status__c |
| Case (Dispute) | Standard | Lookup → Account | Dispute_Amount__c, Evidence_Uploaded__c, Dispute_Category__c |
| Seller_Scorecard__c | Custom | Lookup → Account | Composite_Score__c, Week_Ending__c, Risk_Flag__c |
| Return_Request__c | Custom | Lookup → Order__c | Return_Reason__c, Eligibility_Status__c, Refund_Amount__c |
| Pin_Code_Territory__c | Custom | Standalone | Pin_Code__c, Territory_ID__c, SRM_User__c |
🔑 Design Decisions
• MD vs Lookup on Order__c: MD (not Lookup) so deleting a test Account also deletes its Orders. Also enables rollup summaries for seller-level order counts/amounts• Case as standard object: Leverage built-in Case Assignment, Escalation Rules, Entitlements, Email-to-Case without reinventing
• 3 RecordTypes on Account: Gold_Seller, Silver_Seller, Bronze_Seller — different page layouts, different automation, different Scorecard thresholds
• External IDs on all objects: Enable idempotent upserts from microservices without SOQL lookup overhead
💡 "Account as hub with 3 tier RecordTypes, Master-Detail Order__c for rollup summaries and cascade delete, standard Case for disputes (leverage built-in entitlements), Seller_Scorecard__c for weekly KPI snapshots — External IDs on every object for microservice idempotent upserts."
Tech Q11QueueableAsync Pattern🔥 Common
After a seller's account is approved, you need to: (1) send a welcome email, (2) create an onboarding Task for the SRM, (3) call Flipkart's internal API to provision seller access, (4) update the Seller Portal record. These steps must happen in order but can't block the user. How do you design this?
✅ Queueable chain pattern — each step is a separate Queueable class, each class enqueues the next class in its execute() method. The first Queueable is triggered from a Flow or trigger after account approval. Steps are sequential, async, and each has fresh governor limits.
🔑 Queueable Chain Design
• Why Queueable over Future: Queueable can pass objects as state, can chain to next job, supports monitoring via AsyncApexJob• Chain limit: Maximum depth varies by org — design for 5 or fewer chained jobs to stay safe
• Error handling: Each job checks for errors before enqueuing next — if Step 3 (API call) fails, log error, don't proceed to Step 4
• Idempotency: Each step checks if already completed before executing (in case of retry)
• Monitoring: Query AsyncApexJob to track which step failed if chain breaks
// Step 1: Send welcome email, then enqueue Step 2
public class SellerOnboardingStep1 implements Queueable {
private Id sellerId;
public SellerOnboardingStep1(Id sellerId) { this.sellerId = sellerId; }
public void execute(QueueableContext ctx) {
// Step 1: Send welcome email
SellerEmailHelper.sendWelcomeEmail(sellerId);
// Chain to Step 2
System.enqueueJob(new SellerOnboardingStep2(sellerId));
}
}
// Step 2: Create SRM Task, then enqueue Step 3
public class SellerOnboardingStep2 implements Queueable {
private Id sellerId;
public SellerOnboardingStep2(Id sellerId) { this.sellerId = sellerId; }
public void execute(QueueableContext ctx) {
// Step 2: Create onboarding Task for SRM
insert new Task(WhatId=sellerId, Subject='Seller Onboarding Call', Status='Not Started');
System.enqueueJob(new SellerOnboardingStep3(sellerId));
}
}
// Step 3: External API call to provision seller access
public class SellerOnboardingStep3 implements Queueable, Database.AllowsCallouts {
private Id sellerId;
public SellerOnboardingStep3(Id sellerId) { this.sellerId = sellerId; }
public void execute(QueueableContext ctx) {
// Step 3: Provision seller in Flipkart internal system
Http h = new Http();
HttpRequest req = new HttpRequest();
req.setEndpoint('callout:Flipkart_Internal_API/v1/sellers/provision');
req.setMethod('POST');
req.setBody('{"sellerId":"' + sellerId + '"}');
HttpResponse res = h.send(req);
if(res.getStatusCode() == 200) {
System.enqueueJob(new SellerOnboardingStep4(sellerId));
} else {
// Log error — don't chain Step 4
insert new Error_Log__c(Record_Id__c=sellerId, Error__c=res.getBody());
}
}
}
💡 "For ordered async operations I use a Queueable chain — each class enqueues the next in its execute() method. Step 3 uses Database.AllowsCallouts for the external API call. Error in any step logs to Error_Log__c and stops the chain — no silent failures."
Tech Q12Experience CloudSeller Portal
Design a Salesforce Experience Cloud Seller Portal for Flipkart that allows sellers to: view their scorecard, raise disputes, track case status, view COD confirmation stats, and access their pin code territory assignment. What are the key design and security considerations?
✅ Experience Cloud with Customer Community Plus license for each seller. Partner/Customer community template, LWC components for scorecard and dispute forms, Sharing Sets to ensure sellers only see their own data, Guest user disabled, MFA enforced, mobile-first responsive design for Bharat users.
🔑 Seller Portal Design
• License: Customer Community Plus (full Salesforce UI capabilities including cases and custom objects)• Template: Build Your Own (LWR) for modern performance — critical for low-bandwidth Tier 2/3 sellers
• Data isolation: Sharing Sets — seller Contact can only access records where Account = their seller Account
• Components: Custom LWC: SellerScorecard, DisputeForm, CaseTracker, CODStatsWidget, PincodeTerritory
• Security: MFA enforced, Guest user disabled (no anonymous access), HTTPS only, CSP headers configured
• Performance: Lazy load heavy components, minimize API calls, cache scorecard data (refreshes nightly anyway)
• Mobile-first: 60%+ of Tier 2/3 sellers access via mobile — all components responsive, large touch targets, minimal forms
🏭 Bharat-First Portal Considerations
A seller in Bhilwara, Rajasthan accessing the portal on a 4G connection with a budget Android phone is NOT the same as a metro-based seller with a laptop. Design for: page load < 3 seconds on 4G, single-column layout on mobile, form fields pre-filled where possible, progress indicators for slow network, regional language labels via Translation Workbench.
💡 "Seller Portal: Customer Community Plus license, LWR template for performance, Sharing Sets for data isolation, MFA enforced, custom LWC components for scorecard and disputes, mobile-first design with <3s load time on 4G — Translation Workbench for regional language labels."
Tech Q13CRM AnalyticsEinstein
Build a CRM Analytics (Einstein Analytics) dashboard for Flipkart's Seller Ops team showing: at-risk seller map by geography, weekly score trend, category-wise dispute rate, and BBD readiness score per seller tier. What datasets, recipes, and lenses would you create?
✅ Three datasets (Seller, Scorecard, Case), one Dataflow recipe joining them with pin-code → state geocoding, four lenses (geo map, trend line, bar chart, gauge), composed into a single App with filters for date range, seller tier, and state.
🔑 CRM Analytics Build Plan
• Dataset 1 — Seller_DS: Account fields: Seller_Tier__c, State__c, Pin_Code__c, GST_Number__c (for count)• Dataset 2 — Scorecard_DS: Seller_Scorecard__c fields: Composite_Score__c, Week_Ending__c, Risk_Flag__c, all 5 KPIs
• Dataset 3 — Dispute_DS: Case fields: Dispute_Category__c, CreatedDate, Resolution_Time__c, Dispute_Amount__c
• Recipe: Join Seller + Scorecard on AccountId. Add geocoding step (Pin_Code → Lat/Lng for map). Filter last 12 weeks. Aggregate by State, Tier, Category
• Dashboard — 4 widgets: (1) Geographic heat map of at-risk sellers by state, (2) Line chart: score trend by week per tier, (3) Bar chart: dispute rate by category, (4) Gauge: BBD Readiness Score (composite of all Green/Amber/Red KPIs)
• Filters: Global filter for date range, seller tier, state — applied to all widgets simultaneously
💡 "Three datasets (Seller, Scorecard, Dispute), joined via Dataflow recipe with geocoding for pin codes, four lenses in one App — geo heat map, score trend line, dispute category bar chart, and BBD readiness gauge — with global filters for tier and state."
Tech Q14Named CredentialsHTTP Callout
Salesforce needs to call Flipkart's internal Seller Verification API (OAuth 2.0) to validate GST numbers in real-time when a seller account is created. How do you implement this securely without hardcoding credentials?
✅ Named Credential with External Credential for OAuth 2.0 — stores client_id and client_secret securely in Salesforce. Apex callout references the Named Credential endpoint (callout:Flipkart_GST_API). Token refresh handled automatically. Zero credentials in Apex code.
🔑 Secure Integration Setup
• Step 1 — External Credential: Setup → External Credentials → New. Protocol: OAuth 2.0, Client Credentials flow. Enter client_id, client_secret (encrypted at rest)• Step 2 — Named Credential: Setup → Named Credentials → New. URL: https://api.flipkart-internal.com. External Credential: linked above. Allow Formulas in HTTP Body: enabled
• Step 3 — Permission Set: Assign Named Credential access to integration user profile only (principle of least privilege)
• Apex callout: Endpoint = 'callout:Flipkart_GST_API/v1/gst/validate' — no URL or token in code
• Token refresh: Salesforce handles automatically when token expires
• Testing: MockHttpCalloutFactory in test classes — never calls real endpoint in tests
// Secure callout — no credentials in code
public class GSTVerificationService {
public static Boolean verifyGST(String gstNumber) {
Http h = new Http();
HttpRequest req = new HttpRequest();
// Named Credential handles OAuth token automatically
req.setEndpoint('callout:Flipkart_GST_API/v1/gst/validate?gst=' + gstNumber);
req.setMethod('GET');
req.setTimeout(10000); // 10 second timeout
HttpResponse res = h.send(req);
if(res.getStatusCode() == 200) {
Map<String,Object> body = (Map<String,Object>)JSON.deserializeUntyped(res.getBody());
return (Boolean)body.get('isValid');
}
return false; // Default to false on error
}
}
// In test class — NEVER calls real API
@isTest
public class GSTVerificationTest {
@isTest
static void testVerifyGST() {
Test.setMock(HttpCalloutMock.class, new GSTMockCallout());
Test.startTest();
Boolean result = GSTVerificationService.verifyGST('27AABCU9603R1ZX');
Test.stopTest();
System.assertEquals(true, result);
}
}
💡 "Named Credential with External Credential for OAuth 2.0 — client_id and client_secret encrypted in Salesforce, Apex uses 'callout:Flipkart_GST_API' with no credentials in code, Salesforce auto-refreshes tokens, and MockHttpCalloutFactory handles tests without real API calls."
Tech Q15ApexTrigger Framework🔥 Architecture
Flipkart's Salesforce org has 20+ developers working on the seller platform. Three different teams have written separate triggers on Account. There are performance issues and recursive loops. How do you solve this and design a scalable trigger framework?
✅ Implement a Trigger Framework: one trigger per object that delegates to a Handler class, a TriggerHandler base class with recursion prevention, and a Custom Metadata bypass mechanism. Eliminates multiple triggers competing on the same object and prevents recursive loops.
🔑 Trigger Framework Design
• One trigger per object: AccountTrigger.trigger — delegates all logic to AccountTriggerHandler• Handler class: AccountTriggerHandler — methods: beforeInsert(), beforeUpdate(), afterInsert(), afterUpdate(), etc.
• TriggerHandler base class: Abstract class with recursion prevention (static Set of already-processed IDs)
• Bypass mechanism: Trigger_Settings__mdt — IS_TRIGGER_ACTIVE__c per object. Admins can disable specific triggers without code deployment (for data migrations)
• Bulkification: All handler methods accept List<SObject> — never process single records
• Context separation: Clear separation of before/after, insert/update/delete contexts prevents unexpected side effects
// ONE trigger per object — no logic here
trigger AccountTrigger on Account (
before insert, before update, after insert, after update, after delete
) {
// Check bypass Custom Metadata first
if(TriggerBypassHandler.isBypassed('Account')) return;
AccountTriggerHandler handler = new AccountTriggerHandler();
if(Trigger.isBefore) {
if(Trigger.isInsert) handler.beforeInsert(Trigger.new);
if(Trigger.isUpdate) handler.beforeUpdate(Trigger.new, Trigger.oldMap);
}
if(Trigger.isAfter) {
if(Trigger.isInsert) handler.afterInsert(Trigger.new);
if(Trigger.isUpdate) handler.afterUpdate(Trigger.new, Trigger.oldMap);
}
}
// Bypass check via Custom Metadata
public class TriggerBypassHandler {
private static Map<String,Boolean> bypassCache;
public static Boolean isBypassed(String objectName) {
if(bypassCache == null) {
bypassCache = new Map<String,Boolean>();
for(Trigger_Settings__mdt ts : [
SELECT Object_Name__c, Is_Active__c FROM Trigger_Settings__mdt
]) {
bypassCache.put(ts.Object_Name__c, !ts.Is_Active__c);
}
}
return bypassCache.containsKey(objectName) && bypassCache.get(objectName);
}
}
🏭 Why This Matters at Flipkart Scale
With 20+ developers, multiple teams writing Account triggers independently creates chaos — unpredictable execution order, recursive loops when triggers update the same records, impossible to debug. A Trigger Framework enforces: one entry point per object, clear ownership, and Custom Metadata bypass for data migrations (critical when loading 500K seller records without triggering automation).
💡 "Trigger Framework: one trigger per object delegating to a Handler class, TriggerHandler base class with recursion prevention, Custom Metadata bypass (Trigger_Settings__mdt) so admins can disable triggers for data migrations without deployment — mandatory for any org with 20+ developers."
🗣️
Behavioral Questions — Flipkart Style
STAR format. Quantify impact. Connect every answer to a Bharat-first value.
Behavioral Q1Ownership + Scale
Tell me about a time you built something that impacted a large number of users or had significant scale.
✅ Tests "Scale Thinking" and "Ownership." Frame with numbers — how many records, users, what was the performance impact. Show you thought about scale UPFRONT, not as an afterthought.
🔑 Structure
S: Set scale context early — "We had 200,000 records to process..."T: Your specific responsibility (not the team's)
A: Specific design choices FOR scale (Batch Apex, indexed SOQL, async processing, Database.Stateful)
R: Quantify — "Processed 200K records in 4 hours instead of estimated 3 days. Zero governor limit errors in production."
Flipkart loves: "I designed for 10x the expected volume", "I added monitoring before go-live", "I tested with production-scale data in sandbox"
💡 "I built a Batch Apex solution processing [X] records — designed for 10x expected volume from day one, tested with production-scale data, added AsyncApexJob monitoring to catch failures before they became incidents. [Result with numbers]."
Behavioral Q2Bias for Action
Tell me about a time you had to make a technical decision with incomplete information and a tight deadline.
✅ Tests "Bias for Action." Show calculated risk-taking — you moved forward with 70% information but built in the ability to reverse quickly (Custom Metadata flags, Feature toggles, phased rollout).
🔑 Key Points to Cover
• What information was missing and why couldn't you wait?• What specific decision you made and what assumption you were making
• How you built in reversibility (Custom Metadata toggle, sandbox testing, phased rollout)
• Was your assumption right or wrong — and how did you adapt either way?
• What you would do differently (shows learning, not just success)
💡 "I made the design decision with 70% of requirements confirmed, used Custom Metadata as a feature flag so we could switch behavior without deployment, shipped on time, and refined based on real usage in the next sprint — waiting would have meant missing the deadline entirely."
Behavioral Q3Cross-Team
Describe a time you had to work with a team that had conflicting priorities on a Salesforce implementation.
✅ Tests collaboration and "Influence Without Authority." Flipkart is extremely cross-functional — Ops, Product, Engineering, Data all have opinions on CRM design. Show you used data (not just authority) to align conflicting stakeholders.
🔑 What Flipkart Wants to Hear
• You identified the UNDERLYING business goal of each stakeholder (not their stated position)• You used DATA to frame the trade-off (not just opinions vs opinions)
• You proposed a phased solution that addressed the most urgent need first
• You escalated appropriately — not too early (shows weakness), not too late (blocks progress)
• You maintained the relationship after the conflict resolved
💡 "I mapped each stakeholder's underlying goal (not their stated position), ran a quick analysis that quantified the trade-off, proposed a phased approach addressing the most urgent need first, and got alignment in one meeting instead of 3 weeks of email threads."
🏗️
Design Scenarios — System Design Round
Open-ended design questions. Think out loud. Show trade-off awareness. Say what you WON'T build.
Scenario Q1Architecture🔥 Very Common
Design a complete Salesforce Seller CRM for Flipkart. You have 6 months and a team of 5. Walk through your approach — data model, features, integration, and what you would NOT build.
✅ Phase 1 (Month 1-2): Core data model + seller onboarding. Phase 2 (Month 3-4): Disputes + COD workflow + Territory. Phase 3 (Month 5-6): Scorecard + Analytics + Microservice integration. NOT building: Einstein AI (needs clean data first), mobile app, complex CPQ.
🔑 6-Month Phased Plan
Month 1-2 — Foundation: Account data model (3 seller tier RecordTypes), Seller onboarding Flow, basic Case for disputes, Reports/Dashboards for Ops visibility. Team of 5 can ship this comfortably.Month 3-4 — Operations: COD confirmation automation, Territory Management (pin code mapping), Einstein Case Classification for dispute routing, Seller Experience Cloud portal v1.
Month 5-6 — Analytics + Integration: Seller Scorecard (Batch Apex nightly), CRM Analytics dashboards, microservice integration (Order, Logistics data sync), auto-flagging at-risk sellers.
NOT building in 6 months: Einstein Prediction Builder (need 6+ months of clean data to train), Mobile app (seller portal web is v1), CPQ for seller agreements (Phase 2), Multi-language UI (Translation Workbench in Phase 2)
🔑 What Impresses Flipkart Interviewers
Saying what you WON'T build is as important as what you will. Flipkart values frugality and prioritization — a candidate who draws clear scope boundaries and justifies them with business reasoning is more impressive than one who tries to design everything upfront.
💡 "Three phases: Foundation (data model + onboarding), Operations (disputes + COD + territory), Analytics + Integration (scorecard + CRM Analytics + microservices). I'd explicitly NOT build Einstein features until we have 6 months of clean data — and no mobile app in Phase 1."
Scenario Q2BBD Prep
Big Billion Days starts in 48 hours. You need to make sure Salesforce doesn't become a bottleneck. What do you do right now?
✅ 48-hour BBD prep: archive old data, enable BBD_Mode Custom Metadata flag, disable non-critical automation, stress test with 10x load in sandbox, set up governor limit monitoring alerts, brief on-call team with specific runbook.
🔑 48-Hour BBD Checklist
48 hours before:✅ Archive Cases older than 6 months via Batch Apex (reduces record count for queries)
✅ Set BBD_Mode__c = true in Custom Metadata → lightweight automation mode
✅ Disable non-critical Flows (email notifications for minor events, cosmetic automation)
✅ Verify Platform Event subscribers are healthy and processing
24 hours before:
✅ Stress test with simulated 10x event volume in Full Copy sandbox
✅ Verify Queueable chain is processing without errors end-to-end
✅ Set up monitoring: AsyncApexJob failure alerts, API usage % threshold alerts (Splunk/Datadog)
✅ Brief on-call team with runbook: who calls who, how to abort Batch jobs, escalation path
1 hour before:
✅ Final governor limit consumption health check
✅ Confirm all Platform Event subscribers running
✅ Slack war-room channel active with key engineers online
💡 "48 hours before BBD: archive old data, enable BBD_Mode Custom Metadata for lightweight automation, run 10x load stress test in sandbox, set governor limit monitoring alerts, brief on-call team with specific runbook — not generic escalation. 1 hour before: final health check, war-room channel active."
💰
Salary Guide 2026 — Flipkart Salesforce Roles
Based on Glassdoor, AmbitionBox, LinkedIn Salary. Estimates only.
| Role | Experience | Base Salary (LPA) | Total CTC (Bonus + ESOP) |
|---|---|---|---|
| Salesforce Admin | 2-4 years | Rs 8-14 LPA | Rs 10-18 LPA |
| Salesforce Developer | 3-6 years | Rs 15-26 LPA | Rs 18-32 LPA |
| Senior Salesforce Developer | 6-9 years | Rs 26-38 LPA | Rs 32-48 LPA |
| Salesforce Architect | 8-12 years | Rs 38-55 LPA | Rs 48-70 LPA |
| Integration Engineer (SF) | 4-8 years | Rs 20-35 LPA | Rs 25-45 LPA |
| CRM Analytics Engineer | 4-7 years | Rs 18-30 LPA | Rs 22-38 LPA |
🏆 10 Tips to Crack the Flipkart Salesforce Interview
1
Think Bharat, not Silicon Valley. Every answer should consider Tier 2/3 cities, COD, regional languages, and low-bandwidth users. This immediately differentiates you from candidates with only US-market CRM experience.
2
Always quantify at scale. Don't say "I built a bulk update." Say "I processed 200,000 seller records in 3 hours using Batch Apex with 200-record chunks and off-peak scheduling." Numbers signal scale thinking.
3
Know Big Billion Days cold. It's Flipkart's biggest event and a natural topic for system design rounds. Understand what 10x traffic means for Salesforce automation and have a ready answer involving Platform Events and BBD_Mode flags.
4
COD is not an edge case — it's the norm. ~40-50% of Indian e-commerce is still COD. If your workflow only handles prepaid orders, you've missed the point of designing for Bharat.
5
Platform Events over direct API calls. For any integration with Flipkart's microservices, always default to event-driven async architecture. Synchronous API calls during high traffic are single points of failure.
6
Custom Metadata over hardcoding. Flipkart's business rules change frequently — return windows, SLA thresholds, assignment criteria. Use Custom Metadata so Ops can update without code deployment.
7
Say what you WON'T build. Flipkart values frugality and prioritization. "We wouldn't build Einstein features in Phase 1 because we don't have 6 months of clean data to train models on" is a senior developer answer.
8
STAR format with numbers. Every behavioral answer: Situation, Task, Action, Result. Result MUST be quantified. "The team was happy" is not a result. "Reduced dispute resolution time from 72 hours to 24 hours" is.
9
Trigger Framework matters. With 20+ developers at Flipkart's scale, mention Trigger Framework (one trigger per object, Handler class, Custom Metadata bypass) — it signals you think about team-scale engineering, not just your own code.
10
Pin codes are a unique challenge. India's 19,000+ pin codes don't follow neat boundaries. Show you understand pin code-based territory management and the quarterly India Post sync challenge — this is uniquely Bharat.
🔗 Also Read — Product Company Prep Series
Amazon Salesforce Interview Questions 2026 — Leadership Principles + AWS Integration
Google Salesforce Interview Questions 2026 — Googleyness + GCP Integration
Microsoft Salesforce Interview Questions 2026 — Growth Mindset + Azure Integration
← Back to SF Interview Pro Home
SF
By SF Interview Pro
Salesforce Interview Prep Team
Practical Q&A by working Salesforce professionals · LWC, Apex, Data Cloud & AI
☕
☕ Enjoyed this article?
SF Interview Pro is 100% free and maintained by a Salesforce professional. No ads, no paywalls, and no signup required. If this guide helped you prepare for an interview, earn a certification, or grow your Salesforce career, consider buying me a coffee! ☕💜
🇮🇳 UPI (India)
Pay by QR
GPay · PhonePe · Paytm · BHIM
Keep Preparing
New interview questions every week
Follow for fresh Salesforce Q&A, free courses, and real interview experiences — straight from the trenches.
Follow Us ↗