Q: What is a User Story and why does it matter?

A User Story is a short, user-focused description of a feature in a standardised template: As a [role] , I want [goal] , so that [reason] . Example: "As a sales manager, I want to see my team's pipeline by stage in one dashboard, so that I can identify deals that need attention." The format forces three things: 1. Identifying the user — not "the system should..." but "as a sales rep". Reveals which role benefits. 2. Articulating the goal — what the user wants to accomplish. 3. Capturing the reason — why it matters. Distinguishes high-value from low-value features. User stories often come with acceptance criteria — observable conditions that prove the story is done. Given I am a Sales Manager logged into Salesforce When I open the My Team's Pipeline dashboard Then I see a chart of opportunities grouped by Stage, filtered to my direct reports. The Given/When/Then format makes acceptance criteria testable. Why user stories beat traditional specs: - User-centric — keeps the team focused on outcomes, not features. - Fits Agile cadence — small enough to ship in one sprint. - Conversation starter — story prompts questions that surface details. - Estimatable — small stories are easier to e

Q: What is User Acceptance Testing (UAT) and why does it matter?

UAT (User Acceptance Testing) is the phase where actual end-users test the system to confirm it meets their needs before go-live. Distinct from unit/integration tests (which devs run) — UAT is human-centred. Process: 1. UAT plan — define which scenarios will be tested, by whom, on what data, against what success criteria. 2. UAT environment — typically a Full Sandbox loaded with realistic data, deployed with the build that's planned for production. 3. UAT execution — users walk through scenarios, log defects, suggest improvements. 4. Defect triage — separate genuine bugs (don't go live) from "wishes" (feedback for next iteration). 5. Sign-off — business stakeholders formally accept the build for production. Common pitfalls: - UAT done by the wrong people. Should be real users, not project team members. Project team is too close to the system. - No formal UAT plan — users test ad-hoc, miss critical paths. - UAT environment not production-realistic — bugs that manifest only with real data volume / sharing get missed. - Defects piling up without triage — need a daily standup to keep moving. - No clear sign-off mechanism — "are we done?" lingers. Duration: 2-4 weeks for typical project

Q: Walk me through a typical Salesforce implementation methodology.

Most Salesforce implementations follow a phased methodology — variations of waterfall + agile hybrid. Phase 1: Pre-engagement / Sales (1-2 weeks) - Initial scoping. SOW / contract. Team formation. Phase 2: Discovery (2-6 weeks) - Stakeholder interviews, process mapping, requirements catalogue. - High-level architecture and data model. - Roadmap and sequencing. - Output: Solution Design Document, signed-off scope. Phase 3: Build (4-12 weeks, often longer) - Configuration and customisation in sandboxes. - Frequent iterations, sprint demos to stakeholders. - Concurrent: data migration prep, integration build, training material development. - Often agile: 2-week sprints with backlog grooming, sprint planning, retros. Phase 4: Test (2-4 weeks, overlapping Build) - System Integration Testing (SIT) — engineers verify the system works as a whole. - UAT — business users verify it fits their workflow. - Performance / load testing if applicable. - Defect triage and fixes. Phase 5: Deploy / Go-Live (1-2 weeks) - Final data migration to production. - Code deployment with a deployment runbook. - User provisioning and training. - Go-live event with hypercare standby. Phase 6: Hypercare (2-4 weeks

Q: How do you estimate a Salesforce project?

Project estimation is part science, part judgement, part hedging. Approach: 1. Decompose into work units. Don't estimate "implement Sales Cloud"; break into objects, page layouts, validation rules, flows, integrations, reports, dashboards, training modules. 2. Estimate per unit using past benchmarks. Most consultancies maintain effort tables: - Custom field with validation: 2 hours. - New custom object with full security: 8 hours. - Standard flow with 5 elements: 4-8 hours. - Complex integration with auth + transformation + retry: 80-160 hours. - Lightning Record Page redesign: 8-16 hours per page. 3. Add time for non-build work : Discovery (15-25% of total), Test (15-20%), Project Management (10-15%), Training (5-10%), UAT support (10%), Hypercare (5%). 4. Add buffer for unknowns. Junior estimators forget to add buffer; seniors always do. Typical buffer: 20-30% on top of the bottom-up estimate. 5. Validate top-down. Compare to similar past projects. If your bottom-up says 200 days but past similar work was 400, something's missing. 6. Document assumptions explicitly. "Estimate assumes 1 sandbox, 5 user profiles, no Field Service, single-org, English-only data." Each assumption is

Question 1

What does a Salesforce Consultant do day-to-day?

Accepted Answer

A Salesforce Consultant sits between the business and the platform — translating goals into solutions and orchestrating delivery. Day-to-day work clusters into four areas: 1. Discovery. Interviewing stakeholders, mapping current-state processes, defining future-state, capturing requirements, identifying risks. Workshops, demos, and constant question-asking. 2. Solution design. Architecting the configuration and (when needed) customisation: data model, automation, page layouts, security, integrations. Producing solution design documents that admins/developers implement. 3. Delivery oversight. Coordinating with admins, developers, architects, QA. Sprint planning, story refinement, demos, sign-offs. Course-correcting when scope drifts or technical reality challenges the plan. 4. Change management. Training users, writing documentation, running adoption metrics, helping the business absorb the change. Often the hardest part — technology rarely fails; adoption does. Consultants come in implementation flavours (Sales Cloud, Service Cloud, Field Service, Marketing Cloud, Industries) and project flavours (greenfield builds, legacy migrations, optimization). Typical week: 30% in client meet

Question 2

What is the difference between Sales Cloud and Service Cloud?

Accepted Answer

Both are flagship Salesforce products built on the same platform but optimised for different workflows. Sales Cloud — automates the sales process . Core objects: Lead, Opportunity, Account, Contact. Features: pipeline management, forecasting, sales paths, opportunity teams, quotes, products, price books, Sales Engagement (cadences). Used by Sales Reps, Sales Managers, RevOps. Service Cloud — automates customer support . Core objects: Case, Account, Contact, Knowledge Article, Entitlement. Features: case routing (assignment + escalation rules), Service Console, Omni-Channel (skill-based routing), knowledge base, Field Service, Live Agent / Chat, social customer service. Used by Support Agents, Service Managers, Field Technicians. Overlap: both run on the same Salesforce org; many customers use both. Account and Contact are shared. A single user can have access to both clouds. Other clouds : - Marketing Cloud (separate platform; integrates) — outbound marketing, journeys. - Commerce Cloud — B2C and B2B e-commerce. - Field Service — extension of Service Cloud for on-site work. - CPQ / Revenue Cloud — extension of Sales Cloud for complex quoting and billing. - Industries Clouds — Finan

Question 3

What is a Discovery phase in a Salesforce project?

Accepted Answer

Discovery is the first phase of a Salesforce implementation — the time spent understanding what the business needs before building. What happens in Discovery: 1. Stakeholder identification. Who are the decision-makers, end-users, and SMEs? 2. Current-state mapping. How does the business work today? What systems, processes, pain points? 3. Future-state vision. What should the experience look like post-implementation? 4. Requirements capture. Functional (what the system does), non-functional (performance, security, scale). 5. Solution exploration. What out-of-the-box features fit? What needs configuration vs custom? 6. Risk identification. Integrations? Data migration? Compliance? Change management. 7. Roadmap and sequencing. What's the phased delivery plan? Outputs: Discovery Document (or Solution Design Document), stakeholder map , requirements catalogue , high-level architecture , timeline and budget estimate . Typical duration: 2-6 weeks for a mid-size project, longer for enterprise. Why it matters: building the wrong thing is the 1 reason projects fail. Discovery validates assumptions before commitment. Common mistake: treating Discovery as a checkbox. Rushing produces vague req

Question 4

How do you gather requirements from business stakeholders?

Accepted Answer

Effective requirements-gathering is part interview, part facilitation, part judgement. Techniques: 1. Stakeholder interviews — 1:1 conversations with each role. Understand their day, pain points, wishes. 2. Workshops — group sessions where multiple stakeholders work through a process or scenario. Faster than serial interviews; catches inter-team dependencies. 3. Process mapping — draw the current workflow on a whiteboard or BPMN tool. Visual = easier to challenge and adjust. 4. Day-in-the-life shadowing — sit with a user as they work. Reveals pain that interviews don't. 5. Survey / questionnaires — for breadth across many users with similar roles. 6. Existing systems audit — what does the current tool do? What works? What doesn't? Skills that matter: - Active listening — don't interrupt; let people fully describe their world. - Open-ended questions — "Walk me through how you handle a renewal" beats "Do you handle renewals?" - Probing for "why" — surface true needs vs surface requests. - Documentation discipline — capture verbatim where possible; summaries can drift. - Confirmation loops — repeat back what you heard; let them correct. Common pitfalls: - Trusting the loud voice over

Question 5

What is a Stakeholder Map and why does it matter?

Accepted Answer

A Stakeholder Map is a visual or tabular representation of everyone who has interest in the project: their role, their concerns, their level of influence, and their level of support. Common framework: Power vs Interest grid (a 2×2 with Power on Y, Interest on X): - High power, high interest — manage closely. Executives, key business owners. Constant communication. - High power, low interest — keep satisfied. C-suite who don't care about details but need to know it's going well. - Low power, high interest — keep informed. End users, daily-affected staff. - Low power, low interest — monitor. Tangential stakeholders. For each stakeholder, capture: - Name and role . - Stake — what do they gain or lose? - Concerns — what do they worry about? - Influence — how much can they affect the project (formally and informally)? - Support level — strong supporter, neutral, opposed. - Engagement plan — how will you keep them engaged appropriately? Why it matters: - Project failures often have a "stakeholder gap" — someone important wasn't engaged early, surfaces a blocker late. - Different stakeholders need different communication — execs want summaries; admins want detail. - Change management — kn

Question 6

What's the difference between functional and technical requirements?

Accepted Answer

Both describe what the system needs to do, but at different levels. Functional requirements — what the system does from a user/business perspective. Examples: - "When a sales rep marks an opportunity as Closed Won, the customer should automatically receive a welcome email." - "Cases above $10K in potential refund must be routed to a manager for approval." - "The dashboard must show pipeline by stage, refreshed every 15 minutes." Functional requirements are business-language , observable , testable by an end user. Technical requirements — how the system implements the functional behaviour. Examples: - "Email sent via Marketing Cloud transactional API; payload includes order details JSON." - "Approval routing implemented via Apex trigger calling Approval Process; manager set via custom Lookup field." - "Dashboard backed by Reporting Snapshot scheduled every 15 mins, captured to a custom object, displayed via standard Dashboard component." Technical requirements are implementation-language , architecture-specific , testable by developers. Non-functional requirements are a third category — properties of the system rather than features: - "Page load time < 2 seconds for 95th percentile.

Question 7

What is a User Story and why does it matter?

Accepted Answer

A User Story is a short, user-focused description of a feature in a standardised template: As a [role] , I want [goal] , so that [reason] . Example: "As a sales manager, I want to see my team's pipeline by stage in one dashboard, so that I can identify deals that need attention." The format forces three things: 1. Identifying the user — not "the system should..." but "as a sales rep". Reveals which role benefits. 2. Articulating the goal — what the user wants to accomplish. 3. Capturing the reason — why it matters. Distinguishes high-value from low-value features. User stories often come with acceptance criteria — observable conditions that prove the story is done. Given I am a Sales Manager logged into Salesforce When I open the My Team's Pipeline dashboard Then I see a chart of opportunities grouped by Stage, filtered to my direct reports. The Given/When/Then format makes acceptance criteria testable. Why user stories beat traditional specs: - User-centric — keeps the team focused on outcomes, not features. - Fits Agile cadence — small enough to ship in one sprint. - Conversation starter — story prompts questions that surface details. - Estimatable — small stories are easier to e

Question 8

What is User Acceptance Testing (UAT) and why does it matter?

Accepted Answer

UAT (User Acceptance Testing) is the phase where actual end-users test the system to confirm it meets their needs before go-live. Distinct from unit/integration tests (which devs run) — UAT is human-centred. Process: 1. UAT plan — define which scenarios will be tested, by whom, on what data, against what success criteria. 2. UAT environment — typically a Full Sandbox loaded with realistic data, deployed with the build that's planned for production. 3. UAT execution — users walk through scenarios, log defects, suggest improvements. 4. Defect triage — separate genuine bugs (don't go live) from "wishes" (feedback for next iteration). 5. Sign-off — business stakeholders formally accept the build for production. Common pitfalls: - UAT done by the wrong people. Should be real users, not project team members. Project team is too close to the system. - No formal UAT plan — users test ad-hoc, miss critical paths. - UAT environment not production-realistic — bugs that manifest only with real data volume / sharing get missed. - Defects piling up without triage — need a daily standup to keep moving. - No clear sign-off mechanism — "are we done?" lingers. Duration: 2-4 weeks for typical project

Question 9

Walk me through a typical Salesforce implementation methodology.

Accepted Answer

Most Salesforce implementations follow a phased methodology — variations of waterfall + agile hybrid. Phase 1: Pre-engagement / Sales (1-2 weeks) - Initial scoping. SOW / contract. Team formation. Phase 2: Discovery (2-6 weeks) - Stakeholder interviews, process mapping, requirements catalogue. - High-level architecture and data model. - Roadmap and sequencing. - Output: Solution Design Document, signed-off scope. Phase 3: Build (4-12 weeks, often longer) - Configuration and customisation in sandboxes. - Frequent iterations, sprint demos to stakeholders. - Concurrent: data migration prep, integration build, training material development. - Often agile: 2-week sprints with backlog grooming, sprint planning, retros. Phase 4: Test (2-4 weeks, overlapping Build) - System Integration Testing (SIT) — engineers verify the system works as a whole. - UAT — business users verify it fits their workflow. - Performance / load testing if applicable. - Defect triage and fixes. Phase 5: Deploy / Go-Live (1-2 weeks) - Final data migration to production. - Code deployment with a deployment runbook. - User provisioning and training. - Go-live event with hypercare standby. Phase 6: Hypercare (2-4 weeks

Question 10

How do you estimate a Salesforce project?

Accepted Answer

Project estimation is part science, part judgement, part hedging. Approach: 1. Decompose into work units. Don't estimate "implement Sales Cloud"; break into objects, page layouts, validation rules, flows, integrations, reports, dashboards, training modules. 2. Estimate per unit using past benchmarks. Most consultancies maintain effort tables: - Custom field with validation: 2 hours. - New custom object with full security: 8 hours. - Standard flow with 5 elements: 4-8 hours. - Complex integration with auth + transformation + retry: 80-160 hours. - Lightning Record Page redesign: 8-16 hours per page. 3. Add time for non-build work : Discovery (15-25% of total), Test (15-20%), Project Management (10-15%), Training (5-10%), UAT support (10%), Hypercare (5%). 4. Add buffer for unknowns. Junior estimators forget to add buffer; seniors always do. Typical buffer: 20-30% on top of the bottom-up estimate. 5. Validate top-down. Compare to similar past projects. If your bottom-up says 200 days but past similar work was 400, something's missing. 6. Document assumptions explicitly. "Estimate assumes 1 sandbox, 5 user profiles, no Field Service, single-org, English-only data." Each assumption is

Question 11

Waterfall vs Agile for Salesforce projects — which would you pick?

Accepted Answer

Neither universally wins; the right choice depends on context. Waterfall — sequential phases (Discovery - Build - Test - Deploy). Plan everything upfront; deliver at the end. Pros: - Predictable budget and timeline (in theory). - Heavy documentation suits regulated industries. - Fixed scope = fixed price contracts. - Clear governance gates. Cons: - No course-correction during Build — late stakeholder feedback = expensive rework. - Long time before users see anything. - Requirements drift between Discovery and go-live; built solution may be outdated. Agile — iterative sprints (typically 2 weeks). Ship small increments. Adjust scope based on feedback. Pros: - Early and frequent demos = early validation. - Course-correction is cheap. - Higher engagement from business users. - Better adaptation to changing priorities. Cons: - Predictability harder — "we'll know what we built when we're done". - Documentation often lags. - Fixed-price contracts hard to write against agile delivery. - Demands disciplined product ownership and stakeholder availability. Pure Agile rarely fits Salesforce projects because: - Many Salesforce implementations are upfront integrations (data migration, single-org

Question 12

How do you handle scope creep on a Salesforce project?

Accepted Answer

Scope creep is the gradual expansion of project scope beyond what was originally agreed — usually without proportional adjustment to budget or timeline. Why it happens: - Stakeholders see the system come together; new ideas appear. - Original requirements were incomplete; gaps surface during Build. - Adjacent business needs become "obvious" once the platform is live. - Pressure from leadership: "while we're at it, can you also...". Why it's dangerous: - Schedule slippage compounds (every "small ask" is rarely small). - Quality drops as the team rushes. - Original commitments get missed. - Team burns out. Management approach: 1. Establish a clear scope baseline upfront. Solution Design Document. Signed off. Reference document. 2. Change control process. Every new request goes through a defined gate: - Capture: what's being asked, why, who from. - Assess: effort, dependencies, risk. - Decide: approve, defer, or reject. - Communicate: whatever the answer is, document and broadcast. 3. Use "in scope" / "out of scope" / "future" labels. Don't reject ideas; defer them. Builds backlog for Phase 2. 4. Track impact transparently. "If we add this, X is delayed by 2 weeks and Y is at risk." M

Question 13

What is a Solution Design Document and what does it contain?

Accepted Answer

A Solution Design Document (SDD) is the consolidated artefact that captures what the implementation will be — produced at the end of Discovery, signed off before Build begins. Sections: 1. Executive Summary — problem, proposed solution, success metrics, in 1-2 pages for sponsors. 2. Stakeholders & Users — roles, responsibilities, expected user counts. 3. Current State — process maps, system landscape, pain points. 4. Future State — process maps, vision, user journeys. 5. Functional Requirements — what the system will do, by feature area. 6. Non-Functional Requirements — performance, security, compliance, scale. 7. Data Model — objects, fields, relationships. ERD. 8. Security Model — profiles, permission sets, sharing rules, OWD. 9. Automation — flows, validation rules, approval processes, triggers. 10. UI Design — Lightning Record Pages, page layouts, custom components, mobile considerations. 11. Integrations — systems to connect, integration patterns, data flows. 12. Data Migration — source systems, mapping rules, cleansing approach, sequence. 13. Reporting & Analytics — key reports, dashboards, KPIs. 14. Org Strategy — sandboxes, deployment approach, namespace. 15. Project Plan —

Question 14

How do you decide between configuration and customization?

Accepted Answer

Configuration — using out-of-the-box Salesforce features (page layouts, validation rules, flows, reports). No code. Customization — writing Apex, LWC, or other code. Or installing AppExchange managed packages. Decision criteria, ordered by importance: 1. Out-of-the-box first. Always check if a standard feature solves the need. Salesforce ships an enormous amount of functionality; "we can configure that" is the cheapest answer. 2. Configuration second. If standard doesn't fit but declarative tools do, choose configuration. Faster to build, faster to deploy, easier to modify later, accessible to admins. 3. AppExchange third. If a packaged solution exists at reasonable cost, evaluate it. Buying often beats building when the problem is generic. 4. Custom code last. Only when configuration and AppExchange can't deliver. Code is the most expensive to build, deploy, and maintain. Why this order matters: - Time to market — custom code requires design, build, test, deploy, all longer than configuration. - Future maintenance — every line of custom code is a long-term liability. - Talent dependency — declarative config can be maintained by admins; code needs developers. - Salesforce upgrades

Question 15

Walk me through Discovery for a sales org implementation.

Accepted Answer

Sales Cloud Discovery has specific workshops and artefacts. Stage 1: Strategic alignment - Meet with the VP Sales / CRO. Understand: revenue model, sales motion (inbound/outbound, B2B/B2C, transactional/enterprise), sales team structure, KPIs. - Confirm vision: what's Salesforce expected to deliver? Stage 2: Sales process mapping - Workshop with sales leaders + reps. - Map the funnel : lead generation - qualification - opportunity - close. - Capture stage definitions, exit criteria, who owns each stage. - Capture multiple sales motions if they exist (new business, renewals, expansions). Stage 3: Data model design - Lead, Account, Contact, Opportunity, Product, Pricebook, Quote, Order, Asset. - Custom objects for vertical needs (e.g., for B2B SaaS: Subscription, Renewal). - Relationships and what cascades. - External Id fields for data migration. Stage 4: Pipeline & forecasting - Stages - Forecast Categories mapping. - Probability per stage. - Quota structure. - Forecast hierarchy. - Reports and dashboards needed for sales managers. Stage 5: Lead management - Lead source tracking. - Lead routing rules (region, industry, segment). - Lead conversion process (when does Lead become Acco

Question 16

How do you handle requirements that conflict between stakeholders?

Accepted Answer

Conflicting requirements are the norm, not the exception. Different stakeholders have different stakes; their wants don't align. Common conflict types: - Sales wants flexibility; Finance wants control. "Reps should be able to discount up to 30%" vs "Every discount needs approval". - Marketing wants data access; Privacy wants restrictions. "Marketing should see all customer info" vs "GDPR limits PII access". - Field Service wants offline capability; IT wants single-source-of-truth. "Reps need to work without connectivity" vs "All data must live in Salesforce". - Sales Manager wants visibility into rep deals; rep wants privacy. "Show me all my reps' opps" vs "Only my deals visible to me". Resolution approach: 1. Surface the conflict explicitly. Don't paper over it; name it. 2. Trace to the underlying need. Ask "why" repeatedly until you hit the actual concern. "I want to see everything" usually means "I worry about pipeline accuracy" — which has many solutions besides total visibility. 3. Find the common ground. Both stakeholders usually share a higher-level goal (revenue, customer success). Anchor in that. 4. Propose options. Don't dictate; offer 2-3 paths with trade-offs. 5. Escala

Question 17

What's the typical role split on a Salesforce project (architect, developer, admin, QA, consultant)?

Accepted Answer

Functional Consultant — owns business analysis, requirements, solution design. Bridge between business and technical team. Drives Discovery, writes SDD, runs UAT. Sometimes called Business Analyst (BA) on smaller projects. Solution Architect — owns the technical architecture. Approves data model, security model, integration patterns, deployment strategy. Reviews developer designs. Senior than the dev team. Technical Architect (TA) — even more senior. Often a Certified Technical Architect (CTA). Engaged on enterprise / complex projects. Owns the org's strategic technical direction. Salesforce Developer — implements custom code (Apex, LWC, integrations). Reports to architect. May also do declarative work. Salesforce Admin — implements declarative configuration (objects, fields, flows, page layouts, permissions, reports). Typically owns the org post-go-live for ongoing changes. QA / Tester — designs and executes test cases (functional, regression, integration). Reports defects, validates fixes. May also automate testing (Provar, Selenium, Cypress). Project Manager (PM) — runs the project: timeline, budget, resourcing, risk, status reporting. Coordinates with the client's PM. Scrum Mas

Question 18

How do you architect Sales Cloud for a complex enterprise?

Accepted Answer

Enterprise Sales Cloud rollouts have specific architectural challenges. Key dimensions: 1. Multi-region / multi-currency - Multi-currency org (irreversible decision; plan early). - Region-specific record types, page layouts, processes. - Currency conversion strategy (Advanced Currency Management for historical accuracy). - Localisation (translations, locale-aware formats). 2. Multi-segment go-to-market - Often: SMB, mid-market, enterprise — each with distinct sales motions. - Record types per segment differentiating opportunity stages, required fields, approval thresholds. - Different page layouts, paths, validation rules. 3. Sales hierarchy - Role hierarchy mirroring sales org chart (rep - manager - director - VP). - Territory Management 2.0 if sales territories matter (geographic, account-based, hybrid). - Account Teams for enterprise cross-functional engagement. 4. Forecast strategy - Collaborative Forecasts with multiple Forecast Types (revenue, ARR, opportunity quantity). - Quota loading by user/period. - Multi-stage forecast adjustments through the hierarchy. 5. Integration with non-Sales systems - Marketing automation (Pardot/MCAE/Marketo) for lead nurture. - ERP (SAP/Oracle

Question 19

How do you architect Service Cloud for a multi-channel contact centre?

Accepted Answer

Multi-channel: customers reach support via email, phone, chat, social, web form, mobile app, in-app messaging — and the contact centre needs unified handling. Architecture components: 1. Channel ingestion - Email-to-Case — inbound emails create cases, threading by case ID. - Web-to-Case — public form submission. - Phone via CTI (Salesforce CTI / Open CTI / Service Cloud Voice) — call data on Cases. - Chat / Live Agent / Messaging — real-time conversations attached to Case or Contact. - Social channels — Twitter, Facebook DM, WhatsApp via Social Customer Service or Messaging for In-App. - API webhook ingestion — for niche channels (Discord, app-specific). 2. Routing - Omni-Channel — skill-based routing across all channels. Configure presence statuses, skills, capacity per agent. - Assignment Rules + Escalation Rules for case-by-case overrides. - Predictive Routing (Einstein) — AI-suggested routing based on historical patterns. 3. Service Console - Console layout — agent's main work surface. - Utility bar with Macros, Quick Text, History, Telephony, Notes. - Lightning Record Page for Case with key panels (highlights, Knowledge, related records, Activity). - Compact layout for fast sc

Question 20

How do you handle a project that's behind schedule and over budget?

Accepted Answer

Project recovery is a different skill set than steady-state delivery. Steps in order: 1. Acknowledge reality. Don't sugarcoat. Status reports that say "on track" when the project isn't lose trust faster than honest red status. 2. Diagnose the cause. Common patterns: - Scope creep — requirements grew without proportional resources. - Underestimation — original estimate was unrealistic. - Resource issues — team smaller than planned, key people unavailable, junior team. - Technical complexity — surprises in integration or migration. - Stakeholder churn — key stakeholders changing midstream. - Quality debt — defects piling up; team spending more time fixing than building. - Process dysfunction — bad rituals, poor communication. Each cause has different remediation; mis-diagnosis wastes recovery effort. 3. Re-baseline the project. Don't try to recover by working harder; replan formally: - New timeline. - New budget. - Re-prioritised scope (typically reduced). - Updated risk register. 4. Cut scope ruthlessly. Identify must-have for go-live vs nice-to-have. Defer nice-to-haves to Phase 2. Be candid: "we'll go live with feature A, B, C and add D, E, F in Phase 2." 5. Add capacity strategic

Question 21

How do you migrate from Salesforce Classic to Lightning Experience at scale?

Accepted Answer

Salesforce Classic is deprecated; orgs still on it must migrate. The challenges scale with org complexity. Phase 1: Assessment - Lightning Experience Readiness Check (Setup - Lightning Experience) — automated tool that scans the org and flags blockers. Run it; review every flag. - Inventory: VF pages, custom buttons (especially JavaScript Buttons — Classic-only), custom Apps, custom Tabs, integrations using Classic-specific URLs. - Estimate effort: simple orgs 3 months, complex orgs 12+ months. Phase 2: Plan - Decide: phased rollout (group by group) or big-bang. - Train the team on Lightning concepts (App Builder, Lightning Pages vs page layouts, Quick Actions). - Set up sandboxes for the Lightning build. Phase 3: Build - Lightning Apps for each persona (Sales Console, Service Console, etc.). - Lightning Record Pages in App Builder per object — replaces Classic page layouts as the primary UX. - Quick Actions to replace JavaScript Buttons (which don't run in Lightning). - Custom Lightning Components or LWCs to replace any Classic-specific Visualforce pages. - Compact Layouts for highlights panels. Phase 4: Test - UAT in sandbox with real users. - Compare feature-by-feature: does the

Question 22

How do you architect data migration from a legacy CRM to Salesforce?

Accepted Answer

Data migration is often the highest-risk phase of any Salesforce implementation. Strategy: 1. Inventory and Profiling (Week 1-2) - Source systems : identify every system holding migrate-able data. - Object mapping : source tables - Salesforce objects. - Data profiling : row counts, field completeness, data quality issues, duplicates. - Cleansing decisions : what gets migrated, what gets archived, what gets fixed. 2. Mapping Specification (Week 2-4) - Field-level mapping : source field - Salesforce field, with transformation rules. - Default values for required Salesforce fields not in source. - Lookup translations : source IDs - Salesforce IDs (often via External Id fields). - Picklist value mappings : source values - Salesforce picklist values. - Special handling : nested data, attachments, audit history. 3. Order of Operations Migrate parents before children: 1. Users (system context for ownership). 2. Accounts. 3. Contacts (linked to Accounts). 4. Opportunities (linked to Accounts). 5. Activities (linked to anything). 6. Custom objects and dependent records. 4. Migration Tooling - Salesforce Data Loader / Dataloader.io — for moderate volume, structured migrations. - Bulk API 2.0

Question 23

How do you make a build-vs-buy decision (custom vs AppExchange vs Salesforce native)?

Accepted Answer

Build-vs-buy is a recurring architectural choice. Frameworks help. Three options: 1. Salesforce native — out-of-the-box features. 2. AppExchange / managed package — third-party app installed. 3. Custom build — your team writes Apex/LWC/integration. Decision criteria: 1. Does Salesforce native solve it? If yes: STOP. Use it. Cheapest, most maintainable, evolves with the platform. 2. Does an AppExchange solution exist? Evaluate: - Functionality fit : does it cover 80%+ of the requirement? - Vendor health : financially stable? Active development? Recent reviews? - Security review : Salesforce Security Reviewed? When? - Customer references : comparable customers using it successfully? - Pricing : total cost of ownership over 3-5 years. - Customisability : does it allow the customisations you'll need? - Exit strategy : can you migrate off it later if needed? If yes to most: BUY. Faster to market, robust, supported. 3. Custom build when: - Highly specific business logic — generic packages don't fit. - Integration with proprietary systems that no package supports. - Compliance / security requires code your team controls . - Cost over time of licensing exceeds dev cost. - Customisation dep

Question 24

Walk me through change management for a major Salesforce release.

Accepted Answer

Change management = preparing the organization to absorb the change. It's distinct from technical deployment. Activities span the project lifecycle: Phase 1: Awareness (early Discovery) - Vision communication — why is this happening? Sponsor leads with the "why". - Stakeholder identification — power and interest map. - Champion network — recruit advocates in each affected team. Phase 2: Engagement (during Build) - Demo cadence — sprint demos with users, not just stakeholders. - Champion involvement — they preview features, give feedback, evangelize. - Newsletter / updates — periodic written communication on progress. - Q&A sessions — open forums for concerns. Phase 3: Training (closer to UAT) - Curriculum design — role-based: what each persona needs to know. - Multiple formats — instructor-led, video, written, in-app guidance. - Trailhead modules — Salesforce's free training; orgs can build custom Trails. - In-app guidance (Setup - In-App Guidance) — tooltips, walkthroughs inside Salesforce. - Train-the-trainer model — champions train their teams, scaling reach. - Certification for power users / champions to deepen adoption. Phase 4: Launch (go-live) - Cutover communication — what'

Question 25

How do you measure the success of a Salesforce implementation?

Accepted Answer

Beyond "did it ship", success has multiple dimensions. 1. Adoption metrics - Daily/weekly active users — what percentage of licensed users log in regularly? - Feature usage — are key features being used? Which features sit unused? - Records created — is data flowing in? - Time spent in Salesforce vs alternatives (sales reps still in Excel = adoption issue). Source: Lightning Usage App, Event Monitoring, custom reports. 2. Business outcomes - Revenue impact : pipeline coverage, win rate, deal velocity. - Operational efficiency : case resolution time, agent productivity, sales cycle length. - Customer satisfaction : CSAT, NPS movement. - Cost reduction : legacy systems decommissioned, manual work automated. These should map back to the project's original justification ("we said this would improve X by Y%; did it?"). 3. Quality metrics - Defect rates — open vs closed; severity distribution. - Production incidents — frequency and impact. - Code quality — test coverage, PMD findings, audit findings. 4. Process maturity - Release cadence — how often can you deploy without drama? - Time from idea to production — backlog - live. - Rollback rate — how often do you have to undo deploys? 5. U

Question 26

What is Salesforce Field Service and when do you implement it?

Accepted Answer

Field Service (formerly Field Service Lightning) is a Service Cloud add-on for organizations with a mobile workforce — service technicians, field reps, installers — who travel to customer locations. Key components: - Work Orders / Work Order Line Items — what work needs doing. - Service Appointments — scheduled visits with start/end times. - Service Resources — the technicians. - Service Territories — geographic regions. - Service Crews — multi-person work. - Dispatcher Console — visual scheduling tool. - Field Service Mobile App — offline-capable app for technicians. - Schedule Optimization — AI-driven appointment routing. - Crew Management, Inventory, Maintenance Plans . Implement Field Service when: customers need technicians dispatched (HVAC, telecom, healthcare home visits, equipment repair), inventory tracking matters, route optimization saves time/cost, or contractors need a coordinated dispatch system. Configuration is significantly more complex than core Service Cloud — typically a 3-6 month implementation in its own right.

Question 27

What is the difference between Marketing Cloud and Pardot (now MCAE)?

Accepted Answer

Both are marketing automation but for different audiences and runtimes. Pardot / Marketing Cloud Account Engagement (MCAE) — B2B-focused. Lives inside Salesforce. Lead nurture, scoring, email campaigns, marketing-to-sales handoff. Primary objects: Prospect (separate from Salesforce Lead/Contact), Form, Landing Page, Email Template, Engagement Studio. Marketing Cloud Engagement (MCE, formerly ExactTarget) — B2C-focused. Separate platform; integrates with Salesforce. High-volume email, mobile push, SMS, social, advertising. Primary tools: Email Studio, Journey Builder, Mobile Studio, Audience Builder, Contact Builder. Differences: - Volume : Pardot hundreds of thousands sends/month; MCE millions/billions. - Audience : Pardot for businesses (lead nurture); MCE for consumers (newsletters, transactional). - Architecture : Pardot inside Salesforce; MCE outside but integrated. - Pricing : Pardot per Salesforce-license-tier; MCE based on contact list and send volume. Decision: B2B SaaS / enterprise sales - Pardot/MCAE. Consumer brand / B2C - Marketing Cloud Engagement. Both can coexist for hybrid B2B/B2C orgs.

Question 28

What is Salesforce CPQ and when do you implement it?

Accepted Answer

CPQ (Configure, Price, Quote) is Salesforce's add-on for businesses with complex quoting needs. Use when: - Multi-product configurations — bundles, options, dependent products. - Tiered pricing — volume discounts, term-based pricing, multi-year deals. - Approval workflows for non-standard pricing or terms. - Subscriptions — annual/multi-year recurring revenue with renewals. - Quote-to-cash integration — quote feeds into orders, billing, revenue recognition. Without CPQ, sales reps build quotes in Excel or directly on opportunities — error-prone, inconsistent, no approval enforcement. CPQ adds: - Product configurator — guided selling for complex SKUs. - Price rules — automatic pricing adjustments based on conditions. - Discount approval — workflow gates non-standard discounts. - Quote document generator — branded PDF quotes. - Subscription management — auto-renewals, mid-term changes (amendments). - Contract management — connects quotes to contracts and renewals. Implementation complexity: 3-9 months for typical org. Requires deep product catalog and pricing modeling. Salesforce's roadmap shifts CPQ + Billing into "Revenue Cloud" — same capability, evolving brand. Alternatives: Aptt

Question 29

What are Salesforce Industry Clouds and when do you use one?

Accepted Answer

Industry Clouds are pre-built Salesforce solutions tailored to vertical industries — Financial Services, Health, Manufacturing, Consumer Goods, Education, Nonprofit, Public Sector, Media, Communications, Energy/Utilities, Automotive. Each ships with: - Vertical data model — industry-specific objects (e.g., Financial Services Cloud has Insurance Policy, Account Plan, Financial Account). - Pre-built page layouts and Lightning Record Pages . - OmniStudio components (FlexCards, OmniScripts, Integration Procedures) for industry workflows. - Pre-built integrations to vertical systems. - Pre-defined automation — flows for common scenarios. When to use: organization is in one of the supported verticals AND the standard Salesforce schema doesn't cover their needs out of the box. Alternative: Sales Cloud + Service Cloud + custom objects to model the same domain. Sometimes cheaper and simpler if needs are narrow. Trade-offs: - Industry Cloud : faster start, vertical best practices baked in, but tied to Salesforce's Industry Cloud roadmap and pricing. - Custom : more flexibility, full ownership, but slower to build, requires deep Discovery to capture vertical needs from scratch. Decision often

Question 30

What is Experience Cloud and what's it used for?

Accepted Answer

Experience Cloud (formerly Communities) is Salesforce's platform for building external-facing portals — customer self-service, partner relationship management, employee intranets, Help Centers. Built on the same Salesforce platform as core CRM, but exposed to external users with their own license types: - Customer Community / Plus — for customers (limited record access). - Partner Community — for partners (more access, deeper CRM integration). - External Apps / Self-Service — newer license types. Common use cases: - Customer self-service portal : knowledge base + case submission + community discussion. - Partner portal : partners view their leads, submit deals, track commissions. - Help Center : knowledge + FAQ + support form. - Vendor portal : suppliers update their data. - Idea / feedback community : customers vote on feature requests. Built using LWR (Lightning Web Runtime) — the modern site builder that's fast, SEO-friendly, mobile-responsive — or older Salesforce Tabs / Visualforce templates. Key architectural decisions: - Sharing : external users get their own OWD column. Sharing Sets common for HVPU. - Authentication : SSO via SAML/OAuth, or Salesforce-managed accounts. - Br

Question 31

What are the main Salesforce license types and how do you choose?

Accepted Answer

Salesforce licensing is complex; oversimplification: Internal user licenses: - Salesforce (full CRM) — most expensive, full platform access. - Salesforce Platform — limited objects (no standard Sales/Service objects), good for line-of-business apps. - Lightning Platform Starter / Plus — newer; cheaper than full Salesforce. - Customer Community / Customer Community Plus — external users, customer-facing. - Partner Community — external users, partners. - External Apps / Self-Service — newer external licenses with different access models. - Identity — login-only, no CRM access. - Chatter Free / Chatter Only — limited; mostly retired. Add-on licenses: - Sales Cloud / Service Cloud edition tiers (Essentials, Professional, Enterprise, Unlimited). - CPQ, Marketing Cloud, Field Service, Industry Clouds — separate add-ons. - Permission Set Licenses (PSL) — feature unlocks. Choosing: - Internal Sales/Service users - Salesforce (full CRM) license. - Internal users on a custom app only (not touching Account/Contact/Opp) - Salesforce Platform. - External customers - Customer Community / Plus. - External partners - Partner Community. - Read-only viewers - Login + Identity-only license. Pricing v

Question 32

How do you calculate ROI of a Salesforce implementation?

Accepted Answer

ROI = (Benefits - Costs) / Costs , expressed as percentage or multiple over a time period. Costs (typically captured well): - License fees (per user, per month or year). - Implementation services (consulting fees). - AppExchange add-ons. - Internal team time (often forgotten). - Training. - Ongoing support and admin team salaries. - Hardware / connectivity (rare for Salesforce, but for Field Service mobile devices). Benefits (harder to quantify): Direct revenue impact: - Faster sales cycle - more deals closed in same time. - Better lead conversion - more revenue from same lead volume. - Cross-sell / upsell visibility - larger deals. Cost reduction: - Replaced legacy CRM licenses. - Reduced headcount in routing/dispatching (automation). - Reduced manual data entry hours. - Faster case resolution - fewer support staff per ticket. Productivity: - Sales rep time saved per week - more selling time. - Self-service deflection - fewer support tickets. Customer experience: - Higher CSAT/NPS - retention - lifetime value. - Faster response times - customer satisfaction. Strategic / harder to monetize: - Better data quality - better decisions. - Single source of truth - faster reporting. - Com

Question 33

What is the consultant's role in pre-sales?

Accepted Answer

Pre-sales is the phase before contract signing — when the consulting firm is competing for or scoping the work. Activities: - Discovery calls with prospect — understand their needs. - Scoping — what's in/out, rough effort, timeline. - Demo — show the proposed solution working. - Proposal writing — Statement of Work (SOW), pricing, timeline. - RFP responses — formal answers to enterprise procurement questions. - Proof of Concept (POC) — working prototype to demonstrate feasibility. - Capability presentations — to executives evaluating the firm. Role split: - Account Executive (AE) owns the commercial relationship. - Solution Engineer / Pre-Sales Engineer owns the technical demo. - Consultant / Solution Architect is brought in for scoping, complex Discovery, or POC. Skills consultants bring to pre-sales: - Right-sizing the scope — credibly committing to deliverables. - Identifying risk — flagging dealbreakers early. - Calibrating estimates — bottom-up cost analysis. - Demo design — what scenarios to show, what features to feature. - Reference customer stories — evidence of past success. Pitfalls: - Over-promising in pre-sales to win the deal — bites in delivery. - Under-scoping to lo

Question 34

How do you run an effective Discovery workshop?

Accepted Answer

Workshops are concentrated requirements-gathering sessions — multiple stakeholders, half-day to full-day, structured agenda. Pre-workshop: - Define objective clearly. "Map the lead-to-cash process" not "talk about CRM". - Invite the right people. Decision-makers + at least one user per affected role + maybe an SME or two. Too many people = paralysis. - Pre-read — share an agenda, share existing doc, ask people to come prepared. - Logistics — room booked, whiteboard / digital boards, supplies (sticky notes, markers). - Facilitator role — usually consultant. Plans, leads, stays neutral. - Scribe — captures notes, doesn't participate. During: - Set ground rules — phones away, one conversation at a time, no laptops unless agreed. - Start with context — recap project goals, today's objective. - Mix techniques : - Process mapping on whiteboard — collaborative, visual. - Sticky-note brainstorming — surface diverse ideas without anchoring. - Affinity grouping — cluster ideas. - Voting / dot-prioritisation — rank items. - Role-play — walk through scenarios as a customer. - Devil's advocate exercises — challenge assumptions. - Manage airtime — quiet voices need explicit invitation; loud voic

Question 35

How do you architect the Sales-Marketing handoff (Lead -> Opportunity)?

Accepted Answer

The handoff is where deals get won or lost organisationally. Architecture decisions: 1. Lead capture and enrichment - Marketing channels create Leads: forms, events, MQL imports. - Enrichment — third-party tools (Clearbit, ZoomInfo) or Pardot/MCAE adds firmographic data. - Lead scoring — combine demographic + behavioural to compute fit + interest. 2. Lead qualification stages - MQL (Marketing Qualified Lead) — meets marketing's criteria; ready for sales touch. - SAL (Sales Accepted Lead) — sales has reviewed and accepted ownership. - SQL (Sales Qualified Lead) — sales has confirmed budget, authority, need, timeline (BANT). Each stage has explicit criteria and SLA for movement. 3. Routing - Lead Assignment Rules route to regions, segments, AEs. - Round-robin within a queue for fair distribution. - SLA on first touch — escalation if not contacted in X hours. 4. Lead conversion - When SQL: Convert the Lead — creates Account, Contact, Opportunity. - Mapping : Lead fields - Account/Contact/Opportunity fields. - Custom logic — sometimes additional records (Subscription, Asset) created. - Original Lead retained — read-only post-conversion. 5. Campaign attribution - Campaign Influence — wh

Question 36

How do you design a Salesforce sharing model?

Accepted Answer

Sharing model design is the architectural step that determines who sees what. Done wrong: data leaks or users locked out. Process: 1. Data sensitivity classification. For each object, what's the sensitivity? - Public (everyone can see) — Products, Pricebook. - Internal (all internal users see, not external) — most operational data. - Restricted (specific groups only) — financial, HR, deal teams. - Highly restricted (one or two roles) — compliance-driven, mergers. 2. OWD baseline. Set per object based on sensitivity: - Public Read/Write — fully shared, fastest performance. - Public Read Only — visible, owner-edits. - Private — owner-only, sharing layered on top. Bias toward more open OWD; tighten only when sensitivity demands. Private with millions of records causes performance pain. 3. Role hierarchy — model the org chart. Managers see records below them automatically (unless "Grant Access Using Hierarchies" is unchecked). 4. Sharing rules — declarative grants. Common patterns: - Region-based : "All Accounts in EMEA region readable to EMEA team". - Owner-based : "Records owned by users in Sales team readable to Sales Manager group". - Cross-team : "Marketing readable to all Sales".

Question 37

When do you push for a specific solution vs let the client decide?

Accepted Answer

Consulting style ranges from prescriptive (consultant decides) to consultative (consultant facilitates client decision). The right balance shifts. Push (be prescriptive) when: - Technical issue with clear right answer. "Should we use Workflow Rules?" — no, use Flow. Don't pretend it's an open question. - Salesforce best practice is well-established. Bulkify triggers; one trigger per object. - Client is heading toward a known mistake. Multi-currency once enabled is irreversible — prescribe carefully. - Time-critical — no time for extensive deliberation; need a decision. - Compliance / security risk — these aren't optional. Facilitate (be consultative) when: - Business decision with multiple valid paths. "Should sales reps see all opportunities or just their own?" — depends on culture, trust, accountability. Client decides. - Cultural fit matters. Process changes that work in one org won't in another. Client knows their culture. - Stakeholder alignment needed. When multiple stakeholders disagree, facilitating consensus is more valuable than dictating. - Long-term ownership — client has to live with it; they should choose. Common mistakes: - Too prescriptive in early career — junior c

Question 38

How do you architect a multi-language, multi-currency global rollout?

Accepted Answer

Three dimensions: language, currency, region. Language: - Enable Translation Workbench for all target languages from day one. - User Locale + Language settings on User record drive what each user sees. - Translate: field labels, picklist values, validation messages, custom apps, custom labels (used by code/components). - Knowledge articles support per-language translation workflow. - Reports/dashboards: titles translatable; data not. Currency: - Decide single-currency vs multi-currency BEFORE go-live (irreversible). - For multi-currency: Activate Multiple Currencies, set corporate currency, add active currencies. - Use Advanced Currency Management (ACM) for accurate historical reporting (dated rates). - Every currency field on every object carries CurrencyIsoCode. Plan integration impact. Region: - For single global org: use Public Group + Sharing Rules to limit cross-region visibility, regional Page Layouts for different fields. - For multi-org strategy (separate EU, US, APAC orgs): federate via SSO, integrate via Mulesoft. - Choose based on data residency requirements, regulatory needs, business autonomy. Time zones: - User TimeZone setting drives display. - Build formula fields

Question 39

How do you design the data model differently for B2B vs B2C?

Accepted Answer

The Salesforce data model has roots in B2B (Account-Contact-Opportunity). B2C requires adjustments. B2B (default): - Account = company. - Contact = person at that company. - Opportunity = potential deal with the Account. - Lead = pre-qualified company + contact info. - Many-to-many : a Contact can be on multiple Accounts via Account Contact Relationships. This works for any B2B (selling to other companies). B2C (consumer): - The Account-Contact split is awkward — a consumer is a single person, not a company with contacts. - Person Accounts — Salesforce's solution. A record represents both an Account AND a Contact in one. Enable once; irreversible. - Alternative: keep B2B model but use a fake Account "Consumers" with all individual contacts. Limits some features (Account Hierarchy, Account-driven sharing). Hybrid B2B + B2C: - Person Accounts for individual customers. - Business Accounts for companies. - Both coexist; record types differentiate. Other B2C considerations: - High volume — millions of consumers; LDV strategy mandatory. - External-facing portals (Experience Cloud) heavily used. - Marketing Cloud Engagement instead of Pardot/MCAE. - Identity verification, login more empha

Question 40

How do you design Account Hierarchy for complex organizations?

Accepted Answer

Account Hierarchy uses the Parent Account field to link related companies in a tree — parent companies, subsidiaries, divisions. Common scenarios: 1. Parent / Subsidiary — "Acme Corp (parent) - Acme East (subsidiary) - Acme East Sales (division)". 2. Holding company — financial holding owns multiple operating companies. 3. Franchise model — corporate parent + franchise locations. 4. Account branches — large bank with thousands of branches; each branch is an Account, parent is the corporate entity. Configuration: - Parent Account field (lookup to Account) on every Account. - Salesforce displays a hierarchical view — clicking "View Hierarchy" on an Account shows the tree. - Account Hierarchy UI — built-in, with up to 16 levels. Sharing implications: - Sharing on parents does NOT cascade to children. Each level has its own sharing. - For "all access on parent + children" patterns: use sharing rules referencing custom fields, or Apex Managed Sharing. Reporting implications: - Standard reports don't auto-aggregate across hierarchy. Use custom report types or Roll-Up Summary fields (only across master-detail, not Account Hierarchy). - For aggregated views: build a custom field "Total Hie

Question 41

What is a Salesforce Center of Excellence (CoE) and when do you set one up?

Accepted Answer

A Salesforce CoE (Center of Excellence) is a centralised team responsible for governance, standards, and continuous improvement of the Salesforce platform across the organization. Why establish one: - Multiple Salesforce orgs / business units can drift in different directions without governance. - Without CoE : each team builds their own way, creating "shadow Salesforce" — inconsistent processes, duplicated effort, security gaps. - With CoE : shared standards, reusable assets, coordinated roadmap. CoE responsibilities: - Governance — change control, deployment standards, security review, naming conventions. - Architecture — reference architectures, data model standards, integration patterns. - Tooling — shared CI/CD, source control, testing tools. - Reusable assets — common LWCs, integration patterns, shared training content. - Skills development — training, certifications, internal knowledge sharing. - Roadmap coordination — quarterly release planning across teams. - Vendor management — Salesforce relationship, AppExchange decisions, partner agency oversight. Typical CoE roles: - CoE Lead (usually a senior architect / director). - Solution Architect(s) — guide line-of-business tea

Question 42

How do you adapt agile / Scrum to Salesforce projects?

Accepted Answer

Agile works on Salesforce, with adaptations. Standard Scrum elements applied: - Sprints — typically 2 weeks. Demos at end. Retrospectives. - Backlog — user stories prioritised by Product Owner. - Sprint planning — team commits to a sprint goal. - Daily standup — 15 min, what I did, what I'm doing, blockers. - Sprint review / demo — show working software to stakeholders. - Sprint retrospective — what to improve. Salesforce-specific adaptations: 1. Discovery first. Pure Scrum starts with a backlog and iterates. Salesforce projects need upfront Discovery and Solution Design. Treat as Sprint 0 (or several sprints) before Build sprints. 2. UAT can't always fit in a sprint. Some features need 2 sprints to build, then UAT. Plan UAT cycles separately. 3. Data migration is monolithic. Migration runs once at cutover; can't be sprinted incrementally. 4. Integrations have their own cycles. External systems' availability, schedules, and capacity drive integration timing. 5. Sandboxes complicate environments. Multiple sandboxes for different sprints/teams; refresh strategy matters. 6. Tests are mandatory. 75% Apex coverage required for production deploys; not "we'll write tests later". 7. Salesf

Question 43

Walk me through Discovery for a Service Cloud implementation.

Accepted Answer

Service Cloud Discovery has its own workshops and emphasis. Stage 1: Customer journey mapping - How do customers find support today? Phone, email, chat, portal, social? - What's the journey from "I have a problem" to "I'm satisfied"? - Pain points at each step. Stage 2: Channel strategy - Which channels are in scope? Phone (CTI integration), email, chat, social, web form, mobile, in-app? - Volume per channel. - Skill / language coverage required. Stage 3: Case taxonomy - Case types (Question, Bug, Request, Complaint). - Categories / subcategories. - Priority/severity matrix. - Routing logic per type. Stage 4: Routing & assignment - Skills and capacity per agent. - Assignment rules vs Omni-Channel. - Queue structure. - Escalation criteria and SLA targets. Stage 5: Service Console design - What information does an agent need? Customer 360, history, knowledge. - Macros and Quick Text for repetitive responses. - Utility bar configuration. - Mobile vs desktop experience. Stage 6: Knowledge management - Article structure: types, categories, fields. - Authoring workflow: who creates, reviews, publishes. - Self-service exposure (Experience Cloud). - Article-to-case linking. Stage 7: SLA /

Question 44

How do you architect a data quality strategy for Salesforce?

Accepted Answer

Bad data corrupts every downstream feature. Data quality strategy spans inputs, ongoing maintenance, and measurement. 1. Prevention (best leverage): - Validation rules at every save — required fields, format, cross-field constraints. - Picklists, not free-text — constrain value sets. Use Picklist Value Sets globally. - Lookup relationships, not text — foreign keys, not name strings. - Field-level help — guide users on what to enter. - Required at API level — no "optional via the API" loopholes for integrations. 2. Duplicate prevention: - Matching Rules + Duplicate Rules on Lead, Contact, Account. - Merge UI for users to consolidate dupes. - External Id fields — stable keys that integrations use to upsert without creating dupes. 3. Enrichment: - Third-party data — Clearbit, ZoomInfo, D&B Hoovers append firmographic data. - Pardot/MCAE auto-enriches Lead data. - Geocoding — address standardisation. 4. Cleansing (one-time): - Profile current data — assess completeness, accuracy, consistency. - Identify duplicates — surface and merge. - Standardise formats — country codes, phone formats, capitalisation. - Fill gaps — required fields with sensible defaults or via enrichment. - Archive s

Question 45

How do you design a reporting strategy for a sales org?

Accepted Answer

A reporting strategy answers: who needs what data, when, in what format. 1. Identify audiences: - Reps — their own pipeline, today's tasks, this week's activity. - Managers — team pipeline, forecast, performance metrics, coaching opportunities. - VPs / Directors — segment / region rollups, win rates, deal velocity, ramp metrics. - Executives — total revenue, growth metrics, strategic KPIs. - Marketing — lead quality, campaign ROI, conversion funnel. - RevOps — operational metrics, data quality, process compliance. 2. Per-audience: what decisions are they making? - Reps : which deal to work next? Where am I against quota? - Managers : which deals are at risk? Who needs coaching? - VPs : are we going to hit the quarter? Where are gaps? - Execs : is the business healthy? What's the trend? Reports answer decisions, not just "show data". 3. Per-audience: cadence? - Reps : real-time / on-demand. - Managers : daily glance + weekly deep-dive. - VPs : weekly summary + monthly review. - Execs : monthly + quarterly business review. 4. Format: - Dashboards for at-a-glance — most users start here. - Reports for drill-down — when dashboards prompt questions. - Scheduled email — periodic summary

Question 46

What are the main Salesforce integration patterns?

Accepted Answer

Salesforce documents 5 canonical patterns. Understanding them helps choose the right one. 1. Request-Reply (Synchronous) - Salesforce calls external (or vice versa); waits for response. - Use case: real-time data lookup ("get current inventory"). - Tooling: REST/SOAP callouts, External Services for declarative. - Trade-off: blocking; failure mode is ambiguous. 2. Fire-and-Forget - Salesforce sends data; doesn't wait for response. - Use case: notifications, audit logging. - Tooling: Outbound Messages, Platform Events. - Trade-off: no confirmation of receipt; need separate retry mechanism. 3. Batch Data Synchronization - Periodic bulk sync of large datasets. - Use case: nightly reload of inventory, weekly sync of price lists. - Tooling: Bulk API 2.0, Heroku Connect, ETL tools. - Trade-off: not real-time; data drift between syncs. 4. Remote Process Invocation (Request-Reply with Process) - Salesforce kicks off a long-running process in external; gets ID; checks status later. - Use case: complex computation, AI inference, long workflows. - Tooling: Heroku/Functions with async pattern; webhook callback when done. 5. UI Update Based on Data Changes - Salesforce displays data from externa

Question 47

How do you set up governance to prevent customization sprawl?

Accepted Answer

Customization sprawl: 800+ custom fields per object, 200+ flows on the same object, dozens of triggers. Eventually unmaintainable. Governance mechanisms: 1. Architecture Review Board (ARB). A small group of senior architects/admins reviews proposed changes above a threshold (e.g., new custom object, new integration, more than 10 hours of work). Approves, denies, suggests alternatives. Cadence: weekly or bi-weekly. 2. Standards documentation. - Naming conventions — fields, classes, flows. - Trigger framework — one trigger per object, handler pattern. - Sharing patterns — when to use what. - Custom code criteria — when is custom code justified. - Field deprecation process — how unused fields get retired. 3. Change request process. Before building: submit a request explaining the business need, alternatives considered, estimated effort. Reviewed and prioritised. 4. Quarterly cleanup sprints. Once a quarter, dedicate a sprint to: - Removing unused fields. - Consolidating redundant flows. - Updating deprecated patterns. - Closing out tech-debt items. 5. Metrics dashboard. - Custom field count per object. - Active flow count per object. - Apex class count and total lines of code. - Test

Question 48

How do you advise a team on Salesforce certifications?

Accepted Answer

Salesforce certifications validate skills; they're widely recognised and part of consulting credibility. Certification tracks: Admin track: - Admin (entry) — every Salesforce professional should have this. - Advanced Admin — deeper config, security, automation. - Platform App Builder — declarative dev (objects, fields, automation). Consulting track: - Sales Cloud Consultant — Sales Cloud expertise. - Service Cloud Consultant — Service Cloud expertise. - Field Service Consultant — Field Service. - Experience Cloud Consultant — Communities/Experience Cloud. - Industry-specific — Financial Services, Health, Education, etc. Developer track: - Platform Developer I (PD1) — entry-level Apex/Visualforce. - Platform Developer II (PD2) — advanced Apex, integration. - JavaScript Developer I — LWC focus. Architect track: - Sharing & Visibility, Data Architecture, Integration Architecture, Identity & Access Management, Development Lifecycle & Deployment, B2C Solution Architect , etc. - Pinnacle: Certified Technical Architect (CTA) — board-reviewed, hardest cert in the ecosystem. Other: - Marketing Cloud Email Specialist, Account Engagement (Pardot) Specialist, CRM Analytics Consultant . Advice

Question 49

How do you build a sales funnel analysis dashboard for a CRO?

Accepted Answer

A CRO (Chief Revenue Officer) wants to see: where deals get stuck, where they leak, and where to invest. Standard funnel stages: Lead - MQL - SAL - SQL - Opportunity - Closed Won. KPIs at each stage: Volume : how many at this stage right now? Velocity : average time from entering this stage to leaving? Conversion rate : what % progress to next stage? Conversion value : average deal size for those that convert? Dashboard composition: Top section: pipeline health - Total pipeline value (sum of open opportunities). - Pipeline coverage ratio (pipeline / quota target). Healthy: 3-5x. - Pipeline by stage (funnel chart). - Pipeline by region / segment (geographic / segment view). Middle: velocity - Average time at each stage (bar chart). - Stage-stuck deals (Opportunities in same stage 30 days, list). - Velocity vs target. Conversion - Stage-to-stage conversion rates (funnel with percentages). - Win rate (Closed Won / (Closed Won + Closed Lost)). - Loss reason breakdown. Productivity - Pipeline per rep. - Activities per rep (calls, meetings). - Quota attainment per rep. Trend - Pipeline trend (3-month, weekly snapshots). - Win rate trend. - Deal size trend. Architecture: - Source reports

Question 50

How would you architect Salesforce integration with SAP / Oracle ERP?

Accepted Answer

Salesforce + ERP is the most common enterprise integration. ERP holds the source of truth for accounts, products, orders, invoices; Salesforce drives sales and service. Common data flows: Inbound to Salesforce (from ERP): - Account master data — Customer name, billing address, credit status. - Product catalogue — SKUs, pricing. - Inventory — stock levels (real-time or near-real-time). - Order/Invoice history — for reps to see customer history. Outbound from Salesforce (to ERP): - Quote - Order — when quote becomes order, push to ERP. - New Account creation — Salesforce as system-of-engagement; ERP as system-of-record. - Customer master updates — Salesforce changes flow back. Architecture options: 1. Mulesoft as middleware. Salesforce <- Mulesoft <- SAP/Oracle. Mulesoft handles transformation, retry, error logging, schema differences. Most enterprise pattern. 2. Native ERP connectors. Salesforce ships connectors for some ERPs (older, less flexible). 3. iPaaS (Boomi, Informatica, MuleSoft). Cloud-based integration platforms. Less code than custom; more flexible than connectors. 4. Custom REST APIs on both sides. Salesforce calls SAP; SAP calls Salesforce. More work; full control. 5.

Question 51

How do you design training for a Salesforce rollout?

Accepted Answer

Effective training is layered, role-based, and continuous. Training types: 1. Trailhead modules — Salesforce's free interactive training. Free, high-quality, self-paced. Good for foundational skills. 2. Custom Trailmix — bundle Trailhead modules + custom content into a curated learning path per role. 3. Live training — instructor-led webinars or in-person. Best for nuanced topics, Q&A. 4. Recorded videos — short, role-specific walkthroughs. Reusable. Great for asynchronous learners. 5. Written documentation — quick reference guides, cheat sheets, FAQs. 6. In-app guidance — Setup - In-App Guidance lets you build tooltips and walkthroughs that show inside Salesforce. 7. Champion network — peer training. Senior reps train juniors. 8. Office hours — recurring time slots for ad-hoc questions. Role-based curriculum: - Salespeople : how to log calls, manage opportunities, run reports. - Managers : dashboards, forecasting, coaching. - Admins : configuration, deployments, troubleshooting. - Service agents : console navigation, case handling, knowledge use. Timing: - Pre-launch — overview / vision sessions for buy-in. - At launch — hands-on training for affected users. - Post-launch — refres

Question 52

How do you integrate Salesforce with Slack?

Accepted Answer

Salesforce acquired Slack; integration is deep. Capabilities: - Salesforce notifications in Slack channels — opportunity updates, case alerts, etc. - Slack as the front-end — query Salesforce via slash commands ( ). - Approval requests in Slack — approver clicks "Approve" without leaving Slack. - Channel-per-deal / channel-per-case — auto-created Slack channel for high-priority records, linked to the Salesforce record. - Sales Coach in Slack — AI suggestions inside the channel. Configuration: 1. Install Salesforce app in Slack workspace. 2. Set up the Slack app in Salesforce — Setup - Slack. 3. Configure user mapping — Salesforce User <- Slack User. 4. Per-feature setup — record-channel auto-creation, notification routing, slash commands. Common use cases: - Sales : opportunity won notifications to a wins channel; large deal alerts to leadership. - Service : high-severity case alerts to support managers; case channel for complex multi-team incidents. - Cross-functional : deal-team channel auto-created when an opportunity exceeds threshold; notes synced back. Architecture decisions: - Notifications — what to send, to whom, at what frequency? Too many = noise; too few = missed signal

Question 53

How do you design a self-service customer portal?

Accepted Answer

Self-service portal = customers find answers themselves rather than calling support. Right design saves money and improves experience; wrong design frustrates. Capabilities to include: 1. Knowledge base — searchable articles answering common questions. 2. Case submission — form for issues that need human help. 3. Case status tracking — customer sees their open cases. 4. Account management — update contact info, password, preferences. 5. Community / forum — peer-to-peer help; community-driven Q&A. 6. Order / subscription history — for B2C / SaaS, customers manage subscriptions. 7. Documents — invoices, contracts, statements. 8. Chatbot — Einstein Bots for common queries; handoff to live agent if needed. Architecture: - Experience Cloud (formerly Communities) is the foundation. - Customer Community / Plus license for portal users. - LWR template for modern, fast, SEO-friendly site (vs older Tabs templates). - Knowledge integration — articles surface based on user's question; data categories drive filtering. - Authentication : SSO (OAuth/SAML) or Salesforce-managed login. - Sharing model — Sharing Sets for HVPU users; case visibility filtered to user's own cases (or their account's ca

Question 54

What documentation should a Salesforce implementation produce?

Accepted Answer

Documentation is a deliverable, not an afterthought. Comprehensive docs: Project-phase docs: - Solution Design Document (SDD) — primary blueprint of what's built. - Discovery Outputs — process maps, requirements catalogue, stakeholder maps. - Risk Register — known risks with mitigation. - Test Plans — UAT scenarios, integration test cases. - Runbook for go-live — step-by-step deployment plan. - Hypercare playbook — issue triage process during early days. Permanent docs (live in Confluence / similar): - Architecture Diagram — data model, integrations, sharing model, deployment topology. Visual. - Object & Field Catalog — every object/field with purpose, owner, sample data. - Automation Catalog — flows, validation rules, triggers, with what they do and when. - Integration Catalog — every integration, source, target, frequency, ownership, troubleshooting. - Security Model — sharing, profiles, permission sets — visualised. - Naming Conventions & Standards — for future development. User-facing docs: - Quick Reference Guides per persona — 1-2 pages, common tasks. - Process Documentation — how to handle specific workflows. - FAQ — answers to common questions. - Knowledge articles — for bo

Question 55

How do you manage a project with multiple vendors (Salesforce SI + Mulesoft SI + offshore dev)?

Accepted Answer

Multi-vendor projects multiply complexity. Each vendor has their own methodology, incentives, communication style. Common configurations: - Big SI (lead) + niche SI (Mulesoft, etc.) . - Onshore (consulting) + offshore (development) . - Two SIs in competition — sometimes a customer hires two for de-risking. - Customer + 2-3 vendors — customer's internal team plus partners. Critical practices: 1. Single integration manager (often the customer's PM or a dedicated coordinator). Without one, vendors point fingers when things break. The IM owns the cross-vendor handoffs and dependencies. 2. Joint working sessions. Don't ping-pong across emails; bring vendors together for live decisions. Reduces ambiguity. 3. Shared project plan. Every vendor sees the unified plan, not their own slice. Dependencies visible. 4. Shared issue/risk register. One source of truth. 5. Communication channels. Slack channel per project including all vendors; weekly cross-vendor sync; monthly steering committee with leadership. 6. Clear interface ownership. "Mulesoft team owns integration A; Salesforce team owns Salesforce side." Document what each delivers and what they expect from others. 7. Schedule alignment. D

Question 56

How do you manage risk on a Salesforce project?

Accepted Answer

Risk management = identifying, prioritizing, and addressing things that could derail the project. Risk categories: Technical risks: - Integration with unfamiliar external system. - Custom code that pushes platform limits. - Data migration with poor source data. - Performance under expected load. - Salesforce platform changes during project. Process risks: - Inadequate Discovery. - Scope creep. - Stakeholder churn. - Late UAT findings. - Insufficient testing. Organizational risks: - Sponsor change. - Re-org during project. - Conflicting stakeholders. - Inadequate change management. - Resource availability (vacation, illness, attrition). Commercial risks: - Underestimated effort - budget overrun. - Vendor performance. - Currency / regulatory shifts (international). Risk register format: For each risk: ID, description, category, probability (low/med/high), impact (low/med/high), score (probability × impact), owner, mitigation, contingency. Mitigation vs Contingency: - Mitigation : actions to reduce probability or impact. "Stand up a sandbox early to test the integration." - Contingency : what we'll do if the risk materialises. "If integration testing reveals data format issues, we'll

Question 57

What is hypercare and how do you run it well?

Accepted Answer

Hypercare = the heightened-support period immediately after go-live. Typically 2-4 weeks; longer for complex implementations. Why it matters: - Defects emerge post-launch despite testing — real users find what test cases miss. - Adoption questions flood in — "where's my data", "how do I do X". - Confidence is fragile — early bad experiences can permanently damage trust. - Knowledge transfer — the project team needs to handover to the steady-state support team. Activities: - Daily standup with project team for first 1-2 weeks; weekly thereafter. - Heightened support presence — extra hours, faster SLA on issues. - Issue tracking — a dedicated channel (Slack, helpdesk) for hypercare issues. - Triage cadence — multiple times per day; severity-based. - Quick fixes released frequently — a "hypercare patch" cadence (daily or every other day). - Communication to users — daily updates on known issues, fixes coming, workarounds. - Adoption monitoring — login rates, feature usage; flag concerning trends. Roles: - Hypercare Lead — owns the hypercare period; usually the project consultant lead. - Triage team — devs/admins available to fix issues fast. - Change manager — handles user communicati

Question 58

How do you track adoption post-go-live?

Accepted Answer

Adoption is the difference between a feature shipped and a feature delivering value. Metrics by depth: Basic (login-based): - Daily / weekly / monthly active users. - Login frequency per user / role. - Mobile vs desktop usage. Engagement (action-based): - Records created per day / per user. - Reports run. - Dashboards viewed. - Searches performed. - Feature usage (e.g., "% of opportunities with full required fields filled"). Outcome (impact-based): - KPIs you care about: pipeline coverage, win rate, case resolution time, etc. - Did the metric move post-launch? Tools: - Lightning Usage App — Salesforce's built-in adoption dashboard. Login activity, page performance, custom component usage. - Custom reports — build your own adoption dashboard from the standard data model. - Event Monitoring (Shield) — detailed user-level activity logs. - PendoApp / Walkme — third-party adoption tools with in-app analytics and guidance. Cadence: - Week 1-2 : daily check on login and basic engagement. - Month 1 : weekly review of adoption + issue rate. - Month 3 : depth metrics — are users using key features? - Month 6 : outcome metrics — is the business goal moving? - Month 12 : full ROI assessment. A

Question 59

What's the difference between a Salesforce Consultant and a Salesforce Architect?

Accepted Answer

The roles overlap but emphasise different skills. Salesforce Consultant (typically a Functional Consultant or Senior Consultant): - Business analysis — understanding the customer's process and goals. - Requirements gathering — workshops, interviews, story-writing. - Solution design — at the feature/process level. - Stakeholder management — engagement, communication, change management. - Project delivery — day-to-day coordination. Outputs: SDD, user stories, demos, training material. Salesforce Architect (Solution Architect, Technical Architect, CTA): - Technical architecture — at the platform/system level. - Data model design — objects, relationships, scalability. - Integration patterns — how systems talk to each other. - Security model — sharing, FLS, auth. - Code review — Apex/LWC quality, performance. - Reusable framework decisions — what gets standardised across the org. Outputs: architecture diagrams, technical specifications, ADRs, code reviews. Overlap: - Both think about solution fit and trade-offs. - Both engage with senior stakeholders. - A senior Consultant has architectural awareness; a senior Architect has business awareness. Career progression: - Junior Consultant — g

Question 60

How do you analyze and improve a business process during Salesforce implementation?

Accepted Answer

Salesforce isn't just automation — it's an opportunity to rethink processes. Done right, you don't just digitise what exists; you improve it. Process analysis steps: 1. Map the current state. - Walk through the process with users. Whiteboard / BPMN diagram. - Capture every step, every handoff, every decision point, every system touched. - Note how long each step takes and how often it loops or branches. 2. Identify pain points. - Where do users complain? - Where does the process break? - Where are workarounds (Excel, email, sticky notes)? - Where does work get duplicated? 3. Calculate cost of pain. - 5 minutes per case × 1000 cases per day × 250 days = significant. - Customer dissatisfaction costs. - Opportunity cost of bottleneck. 4. Imagine the future state. Don't just lift-and-shift. Ask: - Should this step exist at all? Many processes have "we've always done it" steps that add no value. - Can this be automated? Most Yes/No decisions and simple field updates are automatable. - Can this be eliminated by data quality? "Manually look up customer" disappears with proper integration. - Can this be parallelised? Some sequential steps could run concurrently. - Who really needs to be in

Question 61

How do you identify and deliver "quick wins" early in a Salesforce program?

Accepted Answer

Quick wins build momentum, validate the platform, and earn stakeholder trust. Without them, big-bang launches are high-risk. Characteristics of a good quick win: - Visible to leadership — they should see it work. - Demonstrably better than current state — clear improvement. - Low effort — buildable in 1-2 sprints. - Low risk — can't break critical workflows if it goes wrong. - Reusable foundation — sets up something larger. Common quick wins: - Simple dashboard for an executive — pipeline at-a-glance, replaces manual Excel report. - Email template standardisation — consistent customer communication. - A few key reports that consolidate scattered data. - Automated email alert on a critical event (large opportunity, escalated case). - Basic Lightning App for a specific role — focused workspace for a small team. - Replace one Workflow Rule with a better Flow — smoother behaviour, modern tool. - Migration of one report from Excel to Salesforce — saves analyst hours. - Removing a permission that was over-broad — security improvement. - A single integration to a frequently-asked-about source — reduces a manual step. How to identify them: - During Discovery, ask: "If you could fix one thi

Question 62

How does a Salesforce consultant build credibility with clients?

Accepted Answer

Credibility = clients trust your judgement and follow your recommendations. Without it, you're just a vendor; with it, you're a trusted advisor. Built through: 1. Demonstrated expertise. - Salesforce certifications (Admin, App Builder, Cloud Consultant minimum). - Past projects you can describe specifically — challenges, decisions, outcomes. - Knowing the platform deeply — not just "you can do this" but "here are three ways and these are the trade-offs". 2. Active listening. - Don't lecture early. Ask questions; listen carefully; understand before suggesting. - Reflect back what you heard; let stakeholders correct. - Validate concerns even when you disagree. 3. Calibrated confidence. - Strong opinions where you have evidence. - Honest "I don't know, but I'll find out" where you don't. - Acknowledging trade-offs, not pretending one path is perfect. 4. Delivering on small commitments. - "I'll send you the meeting notes by EOD" — and you do. - "I'll have the prototype ready by Friday" — and you do. - Reliability on small things signals reliability on big things. 5. Bringing solutions, not just problems. - "We've got an issue with the data migration" + "Here are three options to addres

Question 63

When do you recommend a phased rollout vs big-bang go-live?

Accepted Answer

Big-bang : everyone goes live on the same day. Phased : roll out by team, region, function, or user group over time. Big-bang advantages: - Single cutover event; clean break from old system. - No "two systems running simultaneously" complexity. - Forces full readiness; no procrastination on remaining gaps. - Marketing: a single "Salesforce is live!" moment. Big-bang disadvantages: - High risk: if something fails, everyone is affected. - Heavy training in compressed window. - Hypercare overload — can't help thousands of users at once. - Defects discovered post-launch impact everyone. Phased advantages: - Lower risk per phase; each launch is smaller. - Lessons learned in Phase 1 improve Phase 2-3. - Hypercare manageable per phase. - Earlier benefit to early phases (some users live sooner). - Adjust scope based on Phase 1 reality. Phased disadvantages: - Longer total timeline. - Two systems coexisting (legacy + Salesforce) for some duration — complex integrations needed. - "Phase 1 lives in Salesforce, Phase 2 still in old system" causes confusion. - Project team locked in longer. - Interdependencies — if Phase 2 needs Phase 1 data, the migration must already happen. When phased works

Question 64

How do you design a sandbox strategy for a Salesforce project?

Accepted Answer

Different sandboxes serve different purposes. A clear strategy avoids "everything in one sandbox" chaos. Common sandbox tiers: 1. Developer sandbox(es) — per-developer, for individual feature work. Refreshable daily. Small. 2. Integration / Build sandbox — shared by the project team for integration testing. Daily/weekly refresh. 3. UAT sandbox — for business user testing. Near-production data; refreshed less often (Partial Copy or Full). 4. Staging / Pre-Production — final testing environment that mirrors production. Last stop before deploy. 5. Training sandbox — separate so users can practice without disturbing UAT. 6. Production org — the live system. Sizing decisions: - Developer sandboxes : 200 MB metadata-only. - Developer Pro : 1 GB; useful when sample data is needed. - Partial Copy : 5 GB with selected production data; useful for UAT. - Full sandbox : same as production size; for performance testing, full UAT, training. Refresh cadence: - Dev sandboxes : refresh frequently (weekly). - Integration sandbox : refresh weekly or biweekly. - UAT/Full sandbox : refresh less often (every 2-4 weeks); preserves test data. - Training sandbox : refresh less; training material based on s

Salesforce Consultant interview questions

Top 10 must-know

All 100 questions

Easy

Medium

Hard

Top 10 must-know

1What does a Salesforce Consultant do day-to-day?easy

2What is a Discovery phase in a Salesforce project?easy

3Walk me through a typical Salesforce implementation methodology.medium

4How do you estimate a Salesforce project?medium

5How do you handle scope creep on a Salesforce project?medium

6How do you decide between configuration and customization?medium

7How do you handle a project that's behind schedule and over budget?hard

8Walk me through change management for a major Salesforce release.hard

9How do you measure the success of a Salesforce implementation?hard

10What habits separate junior Salesforce consultants from senior ones?hard

All 100 questions

Easy

What does a Salesforce Consultant do day-to-day?easy

What is the difference between Sales Cloud and Service Cloud?easy

What is a Discovery phase in a Salesforce project?easy

How do you gather requirements from business stakeholders?easy

What is a Stakeholder Map and why does it matter?easy

What's the difference between functional and technical requirements?easy

What is a User Story and why does it matter?easy

What is User Acceptance Testing (UAT) and why does it matter?easy

What is Salesforce Field Service and when do you implement it?easy

What is the difference between Marketing Cloud and Pardot (now MCAE)?easy

What is Salesforce CPQ and when do you implement it?easy

What are Salesforce Industry Clouds and when do you use one?easy

What is Experience Cloud and what's it used for?easy

What are the main Salesforce license types and how do you choose?easy

How do you calculate ROI of a Salesforce implementation?easy

What is the consultant's role in pre-sales?easy

How do you design training for a Salesforce rollout?easy

How do you integrate Salesforce with Slack?easy

What are Salesforce Partner Tiers and why does it matter?easy

How do you write an effective Salesforce project proposal?easy

How do you hand off a project to managed services or the client team?easy

How do you build continuous improvement into a Salesforce program?easy

When do you walk away from a Salesforce project?easy

Medium

Walk me through a typical Salesforce implementation methodology.medium

How do you estimate a Salesforce project?medium

Waterfall vs Agile for Salesforce projects — which would you pick?medium

How do you handle scope creep on a Salesforce project?medium

What is a Solution Design Document and what does it contain?medium

How do you decide between configuration and customization?medium

Walk me through Discovery for a sales org implementation.medium

How do you handle requirements that conflict between stakeholders?medium

What's the typical role split on a Salesforce project (architect, developer, admin, QA, consultant)?medium

How do you run an effective Discovery workshop?medium

How do you architect the Sales-Marketing handoff (Lead -> Opportunity)?medium

How do you design a Salesforce sharing model?medium

When do you push for a specific solution vs let the client decide?medium

How do you architect a multi-language, multi-currency global rollout?medium

How do you design the data model differently for B2B vs B2C?medium

How do you design Account Hierarchy for complex organizations?medium

What is a Salesforce Center of Excellence (CoE) and when do you set one up?medium

How do you adapt agile / Scrum to Salesforce projects?medium

Walk me through Discovery for a Service Cloud implementation.medium

How do you architect a data quality strategy for Salesforce?medium

How do you design a reporting strategy for a sales org?medium

What are the main Salesforce integration patterns?medium

How do you set up governance to prevent customization sprawl?medium

How do you advise a team on Salesforce certifications?medium

How do you build a sales funnel analysis dashboard for a CRO?medium

How would you architect Salesforce integration with SAP / Oracle ERP?medium

How do you design a self-service customer portal?medium

What documentation should a Salesforce implementation produce?medium

How do you manage a project with multiple vendors (Salesforce SI + Mulesoft SI + offshore dev)?medium

How do you manage risk on a Salesforce project?medium

What is hypercare and how do you run it well?medium

How do you track adoption post-go-live?medium

What's the difference between a Salesforce Consultant and a Salesforce Architect?medium

How do you analyze and improve a business process during Salesforce implementation?medium

How do you identify and deliver "quick wins" early in a Salesforce program?medium

How does a Salesforce consultant build credibility with clients?medium

When do you recommend a phased rollout vs big-bang go-live?medium

How do you design a sandbox strategy for a Salesforce project?medium

What are the most common Discovery mistakes and how do you avoid them?medium

How do you communicate project status effectively to executives?medium

What are the exit criteria for going live with a Salesforce implementation?medium

How do you handle data classification and privacy in Salesforce?medium

How do you align a customer's roadmap with Salesforce's platform direction?medium