Salesforce Interview Questions

The big ones are usually about doing too much work inside one transaction.

• SOQL or DML inside loops, which quickly hits query or DML limits. Fix it with bulkification, collections, and moving work outside loops.
• Trigger recursion, where updates cause the same automation to fire again. Prevent it with recursion guards, change checks, and careful trigger design.
• Too many records processed at once, especially with Flow plus Apex together. Use selective logic, async processing like Queueable or Batch, and split work when needed.
• Unselective queries, which can hit CPU time or query row limits. Use indexed filters, query only needed fields, and avoid querying huge data sets.
• Heavy synchronous logic, like complex loops, callouts, or multiple automations on the same object. Consolidate automation, reduce nested loops, and offload non-urgent work asynchronously.

In interviews, I’d say: bulkify first, minimize automation overlap, and monitor with debug logs and Apex tests.

They overlap, but they solve different problems in Salesforce.

• External ID identifies a record using a value from another system, great for upserts, integrations, and matching during imports.
• Unique field enforces no duplicates in that field, like email or employee number, it is a data quality rule.
• Indexed field improves query performance, especially for large data volumes, it helps SOQL filters run faster.

A few nuances matter: - An External ID is usually indexed automatically. - A field can be Unique without being an External ID. - A field can be indexed without being Unique, for example a custom index added by Salesforce. - You can mark some fields as both External ID and Unique if you want fast lookups plus duplicate prevention.

I’d answer this like a quick career story, then tailor it to the role.

My background is in end-to-end Salesforce delivery across mid-market and enterprise orgs. I’ve worked in Sales Cloud and Service Cloud most heavily, with experience in Experience Cloud, CPQ, and some Marketing Cloud integrations. The orgs ranged from single-org setups to more complex multi-sandbox, multi-integration environments with ERP, telephony, and data warehouse connections.

• I’ve done admin and dev work, automation, security, data model design, Apex, LWC, flows, and integrations.
• Typical projects included lead-to-cash, case management, partner portals, approval processes, and quote automation.
• I’ve supported both greenfield implementations and legacy org cleanups, especially reducing technical debt.
• I’ve worked in Agile teams, partnering with admins, BAs, QA, architects, and business stakeholders.
• I focus on scalable design, user adoption, and keeping solutions maintainable after go-live.

I usually start with discovery, then turn that into user stories, process maps, and a proposed Salesforce design the business can validate.

• I meet with end users, managers, and exec sponsors separately, because they care about different outcomes.
• I ask about current pain points, desired KPIs, exceptions, approvals, and what success looks like.
• Then I document requirements as user stories with acceptance criteria, plus process flows and data needs.
• I map those needs to Salesforce features, like objects, fields, Flows, validation rules, security, reports, or integrations.
• I play back the solution in a workshop, confirm priorities, and flag tradeoffs early.

Example, for a sales ops project, stakeholders wanted better lead conversion visibility. I found the real issue was inconsistent qualification and handoffs, so I designed stage criteria, automation, and reporting dashboards that improved conversion tracking and rep accountability.

I’d answer this with a quick STAR structure: situation, what went wrong, the actions I took, and the result.

On one project, we were rolling out a Sales Cloud process with approval automation, and midway through UAT the sales team flagged that the opportunity stages and required fields did not match how they actually sold. We had built from the documented requirements, but the discovery phase had missed a few real-world exceptions. I pulled together a fast working session with the sales manager, top reps, QA, and the admin, mapped the true process, and split fixes into must-haves for launch and nice-to-haves for phase two. We adjusted validation rules, updated the path, retrained users, and reset expectations with leadership. We launched one week later, but adoption was strong because the process actually fit the team.

I look at scale from both a data and platform perspective, not just object relationships.

• Start with business processes, reporting needs, and expected record growth over 1 to 3 years.
• Choose relationships carefully, lookup for flexibility, master-detail only when rollups, ownership inheritance, or tight coupling are needed.
• Design for performance, selective filters, indexed fields, skinny tables if justified, and avoid overloading one object with too many formulas or automations.
• Think about data quality, validation rules, duplicate management, required fields, and clear ownership.
• Plan for sharing and security early, because role hierarchy and sharing models can heavily affect performance.
• Keep integrations and archival in mind, especially with large data volumes, external IDs, and data retention strategy.

These control whether Apex respects Salesforce record-level sharing rules for the current user.

• with sharing: Enforces sharing rules, role hierarchy, manual sharing, teams, etc. Use it for user-facing logic like controllers and service methods.
• without sharing: Ignores record-level sharing, so code can access records the user normally cannot. Useful for admin-style processing, but handle carefully.
• inherited sharing: Adopts the sharing mode of the caller. If called from with sharing, it enforces sharing. If called from without sharing, it does not.

A couple of nuances: - They affect record-level access, not object permissions or field-level security. - If not specified, the class runs in the caller’s context in many cases, which can be ambiguous, so inherited sharing is the safer explicit choice for reusable classes.

Governor limits shape almost every Salesforce design choice because they force you to think in bulk, async, and efficient patterns from the start.

• In Apex, I bulkify everything, avoid SOQL or DML in loops, use collections, and design for 200 records, not 1.
• I keep logic centralized with handler frameworks so triggers stay lean and reusable, which also helps avoid duplicate automation.
• For flows, I’m careful with record-triggered flow sprawl, extra Get Records, and loops that do updates one-by-one.
• For integrations, I watch callout, heap, and transaction limits, so I use Platform Events, Queueables, or Batch for scale.
• I also design for mixed automation, because limits get hit faster when Apex, flows, validation rules, and managed packages all fire together.

In interviews, I’d say limits are not just restrictions, they’re design guardrails.

I’d explain it as Salesforce’s save pipeline, the sequence the platform follows when a record is created or updated. If you know the order, you can predict why validation, flows, triggers, and automation fire when they do.

• System validation runs first, checking required fields, formats, layout rules.
• Before-save flows, then before triggers run, so you can update fields before commit.
• Custom validation rules, duplicate rules, then the record is temporarily saved.
• After triggers run, then assignment rules, auto-response, workflow, process, and record-triggered flows that fire after save.
• If workflow updates the record, Salesforce can run part of the cycle again.
• Escalation rules, roll-up summaries, sharing rules, and post-commit logic like emails, async Apex, and platform events happen later.

I’d also tell them, when debugging, always ask, “What automation touched this record, and at what stage?”

I’d use a record-triggered Flow when the logic is straightforward, declarative, and needs to be easy for admins to maintain.

• Best for simple create or update automation, field updates, related record creation, email alerts, and approval handoffs.
• Use before-save Flow for fast field updates on the same record, it’s efficient and avoids extra DML.
• Use after-save Flow when you need related records, callouts through actions, or more complex branching.
• Choose Flow when requirements may change often and you want lower maintenance and better visibility.
• I’d switch to Apex trigger if I need complex loops, advanced bulk handling, custom error control, recursion management, or logic Flow can’t express cleanly.

A practical answer in interviews is, “Flow first, Apex when complexity, performance, or technical limits require code.”

I’d answer this with a quick STAR structure, situation, task, action, result, and keep the focus on business impact.

At my last company, I led a Sales Cloud implementation for a mid-sized B2B team that was managing pipeline in spreadsheets and emails. The goal was to standardize lead-to-opportunity tracking, improve forecast accuracy, and cut manual admin work. I partnered closely with sales leadership, mapped the real process before designing anything, then built streamlined page layouts, validation rules, approval flows, dashboards, and a light integration with marketing. What made it successful was strong stakeholder buy-in, phased delivery, and user training tailored to each role. Within a few months, adoption was high, forecast accuracy improved significantly, and sales reps were spending more time selling instead of updating spreadsheets.

I use a simple rule: start with clicks for speed and maintainability, then move to code when the requirement gets too complex or needs tighter control.

• Use clicks for standard automation, validations, approvals, page layouts, reports, and most Flow-based processes.
• Choose code when you need complex logic, reusable services, custom integrations, async processing, or performance optimization at scale.
• I also look at who will support it, admins can own declarative solutions more easily than Apex.
• Security, testability, and governor limits matter too, sometimes code is safer and more predictable than a very complex Flow.
• My preference is not clicks versus code, it is the right tool with the lowest long-term cost.

In practice, I often prototype in Flow first, then switch to Apex if it becomes hard to debug, version, or extend.

Changing a relationship type in a live Salesforce org has big ripple effects, and in many cases you cannot directly convert it.

• Lookup to Master-Detail is sometimes possible, but only if every child has a parent, no orphaned records exist, and ownership/security can roll up cleanly.
• Master-Detail to Lookup is allowed more often, but you lose inherited sharing, roll-up summaries tied to that relationship, and some cascade behavior.
• Data model impact matters, child record ownership may change, requiredness changes, and existing automation, validation rules, flows, Apex, and reports can break.
• Security changes are a big deal, master-detail inherits sharing and ownership, lookup does not.
• Deployment needs planning, sandbox test first, check integrations, backfill data, and assess reporting dependencies.

In practice, I’d treat it as a mini migration project, not just a field tweak.

Think of Salesforce access in layers: object and field permissions, then record access.

• Profiles are the baseline, they control what a user can do, like object CRUD, field-level security, tabs, apps, and login settings.
• Permission sets add extra access without changing the profile, useful for exceptions like giving one team access to Export Reports.
• Role hierarchy controls record visibility, users higher in the hierarchy can usually see records owned by people below them.
• Sharing rules open record access horizontally, for example sharing Accounts owned by West Sales with Support as Read Only.
• OWD, org-wide defaults, set the starting record access level, like Private or Public Read Only.

How they work together: profile and permission sets answer "can I access this object or field?", while role hierarchy, OWD, and sharing rules answer "which records can I see or edit?". Access is cumulative, Salesforce generally adds permissions, not subtracts them.

Overusing Flow can create the same problems as overusing code, just in a different place.

• Performance issues, especially with many record-triggered flows, loops, and repeated queries or updates.
• Harder debugging, because logic gets split across multiple flows, paths, subflows, and entry criteria.
• Unpredictable automation, when several flows, validation rules, Apex, and Process Builder all fire on the same record.
• Maintenance risk, because large flows become fragile, hard to test, and difficult for admins or new team members to understand.
• Governance risk, if teams treat Flow as "easy" and skip design standards.

To manage complexity, I keep flows small and single-purpose, use subflows for shared logic, document entry criteria and order of execution, and prefer one record-triggered flow per object per event when possible. I also use naming conventions, fault paths, good test coverage, and move complex or heavy logic to Apex when Flow stops being the right tool.

I keep triggers very thin and push logic into handler and service classes. The trigger should really just route context, like before insert or after update, into one handler entry point.

• One trigger per object, so execution is predictable and easy to find.
• Use a handler framework, trigger calls methods like beforeInsert, afterUpdate.
• Bulkify everything, loop through Trigger.new, use collections, and do SOQL and DML outside loops.
• Separate concerns, trigger handler for orchestration, service class for business logic, selector class for queries.
• Use maps and sets heavily, especially Map<Id, SObject> and related record ID sets.
• Add recursion control carefully, usually with static guards only when truly needed.
• Write tests for bulk scenarios, mixed data, and all trigger contexts you support.

That structure keeps code readable, easier to extend, and safe for governor limits.

Bulkification means writing Apex and automation so they handle many records efficiently in one transaction, not just a single record. In Salesforce, triggers, flows, and API loads often process batches, so your logic has to scale.

• Work on collections, not single records, like Trigger.new instead of one record at a time.
• Move SOQL and DML outside loops, then query and update in bulk.
• Use maps and sets to relate data efficiently and avoid repeated database calls.
• It matters because Salesforce has governor limits, like 100 SOQL queries and 150 DML statements per transaction.
• Without bulkification, code may work in testing with one record but fail during data loads, integrations, or mass updates.

I start with the business process, then design for ownership, reporting, and lifecycle of the data.

• Use master-detail when the child is tightly dependent on the parent.
• The child inherits owner, sharing, and security from the parent.
• Choose it when you need roll-up summary fields or cascade delete.
• Use lookup when the relationship is looser and records should stand alone.
• Lookup is better if the child needs its own owner, sharing, or optional parent.

Example: Invoice Line to Invoice is usually master-detail, because line items should follow the invoice and roll up totals. Contact to Account is often lookup in flexible models, especially if you do not want strict dependency, though standard Salesforce behavior can influence that choice.

I start with least privilege, then layer access in a predictable order so it stays secure and maintainable.

• Set Org-Wide Defaults first, usually Private for sensitive objects, then open only what users need.
• Use role hierarchy for manager visibility, but do not rely on it for process-driven access.
• Prefer criteria-based sharing rules for broad patterns, owner-based rules for team ownership models.
• Use public groups to simplify sharing targets, because groups scale better than sharing to roles one by one.
• For exceptions, use Apex managed sharing or teams, only when declarative options cannot handle it.
• Control field exposure separately with profiles, permission sets, and field-level security.
• For truly complex models, map access by persona, record type, lifecycle, and reporting needs before building.

I handle it by staying collaborative, not just saying no. The goal is to understand the business outcome first, then guide them to the safest scalable option.

• First, I ask what problem they are trying to solve, because the initial request is often not the real need.
• Then I explain the Salesforce constraint or best practice in business terms, like performance, maintainability, security, or user adoption.
• I usually offer 2 to 3 alternatives, with tradeoffs, so stakeholders still feel they have choices.
• If needed, I bring prototypes or data, like governor limits, reporting impact, or admin effort, to make the decision concrete.
• When there is still tension, I document risks, align with governance, and escalate decisions through the right sponsor.

Example, a stakeholder wanted heavy custom logic on page load. I proposed async processing and a cleaner UX instead, which met the need without hurting performance.

I usually answer this with a simple pattern, identify friction, fix it with users, then measure adoption.

At one company, reps were avoiding Salesforce because logging activity felt slow and reports were inconsistent. I interviewed a few power users and a few skeptics, then found the biggest issues were too many required fields, confusing page layouts, and weak training. I streamlined the layout by role, automated field population with flows, added list views and dashboards people actually used, and created short, task-based training sessions. I also set up adoption metrics like login frequency, opportunity updates, and dashboard usage. Within about two months, data completeness improved, pipeline reviews got cleaner, and weekly active usage went up because the system felt helpful instead of administrative.

I’d answer this with a quick STAR structure, situation, task, action, result, and keep the focus on empathy plus adoption.

At one company, I rolled out a new lead qualification flow in Salesforce with required fields and an approval step. Sales reps pushed back because they felt it slowed them down and thought leadership was adding admin work. I first met with a few top reps and managers to understand the friction, then reviewed actual usage data to separate perception from real issues. We found two fields were unnecessary and the approval criteria were too broad. I simplified the flow, added in-app guidance, and ran a short training showing how cleaner data improved routing and reporting. Within a month, adoption improved, complaints dropped, and lead conversion reporting became much more reliable.

I treat documentation like part of the deliverable, not an afterthought. My goal is to make it useful for admins, developers, support, and auditors.

• For configuration, I document object model changes, field purpose, validation rules, flows, page layouts, permissions, and dependencies.
• For customizations, I capture business requirement, design decision, Apex or LWC behavior, deployment notes, test coverage expectations, and known limitations.
• For integrations, I document source and target systems, auth method, data mapping, API endpoints, error handling, retry logic, and monitoring.
• I usually keep lightweight docs in Confluence or a repo README, and link user stories, diagrams, and deployment artifacts.
• I also update docs during every release, because stale documentation is almost worse than none.

I stay current with a mix of official Salesforce sources and hands-on testing, then I filter everything through business value, risk, and effort.

• I review release notes, Salesforce Admin and Developer blogs, Trailhead, and release webinars every cycle.
• I join community groups, follow MVPs and architects, and watch what other teams are actually adopting.
• I spin up features in a sandbox first, especially anything that impacts automation, security, or user experience.
• I evaluate adoption based on ROI, user impact, technical debt reduction, licensing, and change management effort.
• I prioritize features that solve a real pain point, fit the roadmap, and are low-risk to roll out incrementally.

In an interview, I’d add a quick example, like adopting Dynamic Forms after sandbox testing showed cleaner page layouts and less admin maintenance.

I’d start by figuring out whether the slowness is from poor selectivity, too much data, or the way the query is used in Apex.

• Use the Query Plan tool to check cost, cardinality, and whether Salesforce is using an index.
• Make the filter selective, like filtering on indexed fields such as Id, lookup, master-detail, RecordTypeId, audit dates, or external IDs.
• Avoid leading wildcard LIKE, NOT, and broad filters on large text fields, because they often prevent index use.
• Only query fields you actually need, and add LIMIT if the use case allows it.
• If standard indexes are not enough, consider a custom index and redesign filters around that field.
• In Apex, move SOQL out of loops, cache results when possible, and use batch or async processing for very large datasets.

Here’s the clean way to explain it in an interview:

• Validation Rules stop bad data from being saved, using formula logic and an error message.
• Workflow Rules are old automation for simple if/then actions like email alerts or field updates, but they’re being retired.
• Process Builder is also legacy, more powerful than workflow, but slower and harder to maintain than Flow.
• Flow is the modern automation tool. It handles screen flows, record-triggered automation, scheduled logic, approvals, and complex branching.

Current best practice: use Validation Rules for data quality at save time, and use Flow for almost all automation. Avoid building new Workflow Rules or Process Builders because Salesforce is moving everything to Flow. In real projects, I’d also mention keeping automation consolidated, bulk-safe, and well documented so it’s easier to debug and scale.

I handle duplicates with a mix of prevention, detection, and cleanup.

• First, I use Matching Rules and Duplicate Rules to catch likely duplicates on fields like email, phone, and company.
• For prevention, I decide whether users should be blocked or just warned, depending on the business process.
• I also standardize data entry with validation rules, picklists, and clean integrations, because inconsistent data creates duplicates fast.
• For existing duplicates, I use merge tools, duplicate record sets, or AppExchange tools when volume is high.
• On larger projects, I set up reports and dashboards to monitor duplicate trends and train users on search-before-create behavior.

If I were answering in an interview, I would also mention balancing data quality with user productivity, because being too strict can slow the business down.

I handle data migration in four phases: assess, design, load, validate. The biggest mistake is treating it like a one-time import instead of a data quality project.

• Planning: identify source systems, object mapping, field transformations, owners, volume, dependencies, and success criteria.
• Data prep: cleanse duplicates, standardize formats, define external IDs, and decide load order for parents, then children.
• Migration execution: use Data Loader, Data Import Wizard, or ETL tools, usually testing in a sandbox first with small batches.
• Validation: reconcile record counts, spot-check critical records, verify relationships, run user testing, and compare reports to source data.
• Cutover and rollback: freeze source changes, back up data, document issues, and have a rollback plan if validation fails.

In interviews, I would mention governance too, especially security, auditability, and post-load monitoring.

I’d group the biggest risks into data quality, design mistakes, and operational issues during cutover.

• Poor data quality, duplicates, bad mappings, missing owners, mitigate with profiling, cleansing, dedupe rules, and business sign-off on mappings.
• Wrong data model fit, legacy fields moved without purpose, mitigate by defining target-state objects, relationships, and archive strategy before loading.
• Broken relationships, parent-child loads fail or lookups mismatch, mitigate with external IDs, load sequencing, and reconciliation reports.
• Automation and security conflicts, flows, validation rules, sharing, mitigate with a migration runbook, temporary bypass strategy, and full sandbox testing.
• Downtime and user distrust, mitigate with mock migrations, performance testing, rollback plan, and post-load validation with record counts and spot checks.

In interviews, I’d mention dry runs and reconciliation, because that shows you think beyond just getting data in.

I usually answer this by tying reporting to a real decision, not just saying I built dashboards.

• I start by meeting stakeholders, sales, service, or leadership, to define the KPI and the action they want to take.
• Then I build reports with the right filters, row level formulas, bucket fields, and summary formulas so the data is actually decision ready.
• I’ve created dashboards for pipeline health, case backlog, SLA risk, and campaign performance, with components tailored to each audience.
• One example, sales leadership needed better forecast visibility, so I built a dashboard showing stage aging, conversion rates, and rep level pipeline gaps.
• That helped them rebalance territories, coach reps earlier, and improve forecast accuracy because they were acting on trends, not gut feel.

SOQL is for querying specific objects with structured conditions, kind of like SQL in a relational database. SOSL is for text-based searching across multiple objects and fields at once.

• Use SOQL when you know the object, fields, and filters, like SELECT Id, Name FROM Account WHERE Industry = 'Tech'
• SOQL returns records from one object, or related objects through relationships
• Use SOSL when you only know a keyword or phrase and need to search broadly, like contacts, accounts, and leads together
• SOSL is faster for full-text search scenarios, especially across many objects
• In practice, SOQL is for targeted data retrieval, SOSL is for global search-style use cases

A simple way to say it in an interview: if I know where the data lives, I use SOQL. If I need to find where it lives, I use SOSL.

I handle large data volumes by designing for selectivity, async processing, and minimal record touches. The goal is to keep queries fast, avoid locks, and stay within governor limits.

• Use selective SOQL, indexed fields, skinny tables when justified, and Query Plan to validate cost.
• Archive or offload old data, and use Big Objects or external objects if the data does not need full transactional access.
• Process in batches with Batch Apex, Queueables, Bulk API, and platform events instead of synchronous transactions.
• Reduce automation per transaction, consolidate Flows and triggers, avoid recursive updates, and update only changed fields.
• Design for sharing and ownership at scale, because skew, role hierarchy depth, and lookup hot spots can kill performance.

I usually start by narrowing down whether the slowdown is UI, automation, integration, or database-related, then I use platform tools to isolate the bottleneck quickly.

• Debug Logs, to trace Apex, Flow, validation rules, and see where execution time spikes.
• Developer Console and Query Plan, to check SOQL selectivity, long-running queries, and CPU usage.
• Salesforce Optimizer and Lightning Usage App, to spot org-level inefficiencies and heavy page usage patterns.
• Flow Interviews and Flow debug tools, to find loops, unnecessary updates, or record-triggered flow recursion.
• Apex Jobs, AsyncApexJob, and Scheduled Jobs, to review queue backups or failing async processes.
• Event Monitoring and browser dev tools, for page load issues, network latency, and slow Lightning components.

If I were answering in an interview, I would also mention root cause patterns like non-selective queries, too much automation on one object, and poor bulkification.

I’ve used a mix, and I usually choose based on latency, volume, ownership, and error-handling needs.

• Real-time: REST and SOAP callouts for credit checks, pricing, and account sync, where users needed near-instant feedback.
• Batch: Scheduled integrations with Bulk API or middleware for nightly product, invoice, and legacy data loads.
• Platform Events: Event-driven updates for order status and downstream notifications, especially when systems needed loose coupling.
• Middleware: MuleSoft mostly, to handle transformation, orchestration, retries, and monitoring across multiple systems.
• Asynchronous patterns: Queueables and outbound messaging when I wanted to avoid blocking transactions and improve resilience.

One example, I used MuleSoft plus Platform Events for order processing, Salesforce published the event, middleware enriched and routed it, and we got better scalability and replay options than a direct point-to-point callout.

I secure Salesforce integrations in layers, starting with identity, then data access, then monitoring.

• Use OAuth 2.0 with the right flow, usually JWT Bearer for server-to-server, so no shared usernames and passwords.
• Create a dedicated integration user, with least privilege, permission sets, IP restrictions, and only the object and field access it needs.
• Protect secrets and certificates in a vault, rotate them regularly, and prefer signed JWTs or mutual TLS for higher trust.
• Enforce transport security with HTTPS/TLS, and encrypt sensitive data at rest if needed, using Shield Platform Encryption where appropriate.
• Add controls like Connected App policies, API rate limits, named credentials, and event monitoring to track unusual behavior.

In practice, I also review error logs, audit API usage, and validate payloads to prevent overexposure or injection issues.

I decide based on what changed, who needs it, and the delivery guarantees.

• Use Platform Events when you need custom event-driven integration, decoupled publishers/subscribers, or app-to-app communication with custom payloads.
• Use Change Data Capture when external systems need near real-time record change notifications for standard or custom objects, with field-level change details.
• Use Outbound Messaging when you want a simple declarative push from workflow or Flow to an external SOAP endpoint, with built-in retry.
• If consumers are multiple or loosely coupled, I lean Platform Events.
• If the requirement is “tell downstream every create, update, delete on this object,” I lean CDC.
• If it is a low-code legacy integration and SOAP is acceptable, Outbound Messaging is often enough.

I also check replay needs, volume, ordering expectations, and whether the consumer can handle CometD versus SOAP.

My approach is layered, so I catch issues early in dev, validate business outcomes with users, and protect existing functionality before release.

• For unit testing, I focus on Apex coverage plus quality, positive and negative cases, bulk scenarios, permission-based behavior, and realistic test data using @testSetup.
• I keep tests isolated, no dependency on org data, and I verify outcomes with assertions, not just code coverage.
• For UAT, I partner with business users on clear test scripts tied to requirements, real-world scenarios, expected results, and sign-off criteria.
• For regression testing, I identify impacted areas from the change set, then run a mix of manual regression and automated checks for critical flows.
• In practice, if I change an Opportunity trigger, I test related validations, automations, integrations, reports, and user profiles before deployment.

I usually start with the business event, what data moves, how fast it needs to move, and who owns failures. Then I pick the simplest integration pattern that fits.

• For real-time, I’ve used REST APIs, Platform Events, and outbound callouts from Apex or Flow.
• For bulk sync, I’ve supported MuleSoft, ETL tools, and Bulk API jobs for nightly loads.
• I define clear ownership, field mappings, idempotency rules, and retry handling up front.
• Security-wise, I’ve worked with OAuth, Named Credentials, IP restrictions, and encrypted sensitive fields.
• For support, I monitor failures with logs, dead-letter or error queues, email alerts, and reconciliation reports.

One example, I helped integrate Salesforce with an ERP for Accounts, Products, and Orders. Orders were near real-time, product and pricing updates were batch. We reduced duplicate records by adding external IDs and upsert logic, and cut support tickets by giving ops a simple error dashboard.

Here’s the clean way to explain it in an interview: each API fits a different integration pattern.

• REST API, lightweight and easy to use, best for mobile, web apps, and simple CRUD with JSON.
• SOAP API, more formal and schema-driven, best for enterprise systems that need strict contracts via WSDL and XML.
• Bulk API, built for very large data loads, async processing for inserts, updates, deletes, and queries on thousands or millions of records.
• Streaming API, event-based, lets clients subscribe to near real-time changes instead of polling.

If I were answering live, I’d add: use REST for simplicity, SOAP for contract-heavy integrations, Bulk for high-volume data movement, and Streaming when the business needs real-time notifications.

I’d answer this with a quick STAR story, focused on impact, diagnosis, action, and prevention.

At my last project, a Salesforce to ERP integration started failing right after a minor ERP-side API update, and orders were stuck in a pending state. I first noticed it through failed Platform Event retries and a spike in integration error emails. I checked debug logs, middleware logs, and the API response payload, and found the ERP had changed a required field format without backward compatibility. To restore service fast, I paused outbound processing, worked with the ERP team to confirm the contract change, hotfixed the mapping and validation in middleware, then replayed the failed messages from the queue. After that, I added stronger monitoring, contract version checks, and a pre-release integration smoke test so the same issue wouldn’t reach production again.

Test data setup is how you create the records your unit tests need, like Accounts, Contacts, Users, or custom objects. The goal is to make tests reliable, readable, and independent from org data.

• Use @testSetup for shared baseline data, it runs once per test class and speeds things up.
• Create small test data factory methods, so record creation is reusable and consistent.
• Keep each test focused, only create the data needed for that scenario.
• Avoid SeeAllData=true, tests should not depend on real org data.
• Use meaningful names and helper methods, so intent is obvious when someone reads the test.
• For maintainability, separate setup, action, and assertion clearly, and test one behavior per method.

A solid answer in an interview is: build reusable factories, use @testSetup, and keep tests isolated and easy to read.

I’d answer this by showing both the process and the tradeoffs.

• For simple admin changes, I use Change Sets between related orgs, mainly when speed matters and the scope is small.
• For team-based development, I prefer SFDX with source control, usually Git, so every change is versioned, reviewable, and easier to validate.
• I deploy with metadata API tools or CI/CD pipelines, using scratch orgs or sandboxes for build and test, then promote to UAT and production.
• I separate config, code, and data migration. Data usually moves with Data Loader, ETL, or scripts, not with metadata deployment.
• Before production, I run validation, automated tests, and a deployment checklist, then plan rollback, user communication, and post-deploy smoke testing.

If they want more depth, I’d mention unlocked packages for modular deployments.

I treat source control as the system of record, not the org. Git is the backbone, and the branching model depends on team size and release pace, but I keep it simple and enforceable.

• Use Git with Salesforce DX, source format, and scratch orgs or sandboxes for isolated work.
• Keep main always deployable, use short lived feature branches, and merge through pull requests.
• For release heavy teams, I like trunk based development; for scheduled releases, a light GitFlow variant can work.
• Validate every PR with CI, run Apex tests, static analysis, and metadata validation before merge.
• Avoid direct org changes in higher environments, everything should flow through version control and the pipeline.
• Resolve metadata conflicts early by modularizing work and agreeing on package boundaries or ownership areas.

I focus on tests that prove behavior, not just raise coverage.

• Create all data in the test, usually with a small @testSetup, so tests are isolated and repeatable.
• Test one business scenario per method, with clear names like testOpportunityClosesWhenAmountValid.
• Assert outcomes deeply, not just System.assert(true), check field values, record counts, errors, and side effects.
• Cover positive, negative, bulk, and permission-sensitive paths, especially trigger and async behavior.
• Use Test.startTest() and Test.stopTest() to reset limits and force async jobs to run.
• Avoid org dependencies like existing data, hard-coded IDs, and fragile assumptions.
• If logic is complex, separate it from triggers into handler or service classes, then unit test that logic directly.

A strong test class reads like documentation for the feature and catches regressions early.

I’ve worked across the maturity curve, from change sets in smaller orgs to Salesforce DX, unlocked packages, and CI/CD in enterprise setups.

• Change sets: used them early on for simple admin-driven releases, but I treat them as a fallback because they’re manual and hard to audit.
• Salesforce DX: used scratch orgs, source tracking, and CLI-based deployments to support feature branching and cleaner team collaboration.
• Unlocked packages: split shared functionality into modular packages, which made deployments more predictable and reduced regression risk.
• CI/CD: built pipelines with GitHub Actions and Azure DevOps to run PMD, Apex tests, validation deploys, and promote changes by branch.
• In one project, moving from manual deployments to package-based CI/CD cut release time from hours to about 20 minutes and improved rollback confidence.

Before production, I try to remove surprises with a mix of validation, controls, and communication.

• Confirm scope, dependencies, and impacted objects, automations, profiles, integrations, and data volumes.
• Deploy to a full or partial sandbox first, then run unit, regression, UAT, and integration testing.
• Review security, FLS, sharing, permission sets, and make sure no hard-coded IDs or environment-specific references exist.
• Use a deployment checklist, back-out plan, and data backup strategy, especially for schema or data changes.
• Schedule around business impact, notify stakeholders, and line up post-deploy smoke tests plus monitoring.

A strong example is a CPQ release I supported, where we caught a pricing rule conflict in UAT, fixed it before production, and avoided a revenue-impacting issue.

I’d answer this with a quick STAR structure: situation, tradeoff, action, result, with emphasis on how I reduced risk while still meeting the deadline.

At one company, sales needed a new approval flow in Salesforce before quarter end, but the org already had brittle Apex triggers and hardcoded logic. Rebuilding it properly would have delayed the launch, so I split the work into two tracks. First, I delivered the urgent piece using a scoped, low-risk solution with clear guardrails, test coverage, and minimal touchpoints to existing automation. Then I documented the technical debt, created follow-up stories, and got leadership to agree on a cleanup timeline. After launch, we refactored the trigger logic into a more maintainable pattern and moved pieces to Flow where it made sense. The business hit the deadline, and we reduced future incident risk instead of letting the shortcut become permanent.

I’d answer this with a simple STAR structure, situation, task, action, result, and keep the technical jargon light.

At my last role, I had to explain Salesforce sharing and record visibility to a sales leadership team that was frustrated some reps could not see certain opportunities. Instead of talking about roles, profiles, and sharing rules right away, I compared it to office building access, some doors are open to everyone, some depend on your team, and some require special permission. Then I mapped that analogy back to Salesforce with one slide and a real example from their pipeline. That helped them quickly understand why the issue existed, and we aligned on a cleaner sharing model. After that, approval time on access requests dropped because they finally understood the logic behind it.

I prioritize with a mix of business value, risk, effort, and dependency mapping, then make the tradeoffs visible to stakeholders.

• Start by clarifying the ask: problem, users impacted, urgency, and success metric.
• Score each item on business impact, compliance or operational risk, effort, and strategic alignment.
• Separate quick wins from larger initiatives, a small high-value fix can move fast.
• Check dependencies, release timing, data model impact, and whether it affects integrations or security.
• Review priorities with product owner and business leads, so ranking is shared, not arbitrary.

In practice, I usually use a simple rubric like Impact, Effort, Risk, and Dependency. For example, a validation rule fix blocking Sales closes would outrank a nice-to-have dashboard tweak, even if the dashboard is highly visible.

I’d measure success across adoption, business impact, system health, and support trends, then compare those to the original goals and baseline.

• User adoption, login rates, daily active users, feature usage, record creation, report/dashboard usage.
• Data quality, completeness, duplicate rate, validation error trends, required field compliance.
• Process efficiency, reduced manual steps, faster case resolution, shorter sales cycle, improved SLA attainment.
• Business outcomes, pipeline growth, conversion rate, forecast accuracy, CSAT, retention, revenue impact.
• System health, page load times, failed automations, integration error rates, Apex/job failures.
• Support signals, ticket volume, recurring issues, training gaps, enhancement requests.

I usually set KPIs before launch, review at 30, 60, and 90 days, and pair the numbers with stakeholder feedback to see if the solution is actually helping users.

I’ve done a lot of Lightning Experience customization focused on making pages faster, cleaner, and role-specific. My approach is usually, start with the user’s workflow, then simplify the page so they only see what matters when they need it.

• Built Lightning record pages with App Builder using tabs, highlights, related lists, and custom components.
• Used Dynamic Forms and Dynamic Actions to show fields and actions by profile, stage, or record status.
• Customized pages differently for sales, service, and operations teams to reduce clicks and improve adoption.
• Added path, conditional visibility, and quick actions to guide users through key business processes.
• Partnered with stakeholders, tested with end users, then iterated based on feedback and usage patterns.

One example, I redesigned an Opportunity page so reps saw fewer fields up front and stage-specific sections appeared dynamically. That improved usability and data quality at the same time.

I’d treat it like discovery first, then stabilization, then modernization. The goal is to understand business-critical processes fast, reduce risk, and avoid breaking hidden dependencies.

• Start with stakeholder interviews, admins, sales, service, ops, to map key workflows, pain points, and what absolutely cannot fail.
• Run an org assessment, objects, fields, automation, Apex, integrations, profiles, permission sets, reports, technical debt, and adoption metrics.
• Trace dependencies carefully, especially Flow, triggers, validation rules, managed packages, and external integrations.
• Review data quality, duplicates, storage, field usage, and record ownership to find cleanup opportunities.
• Set up a sandbox strategy, version control, and documentation baseline if missing.
• Prioritize fixes by business impact and risk, quick wins first, then larger refactors.
• Build a phased roadmap, stabilize production issues, simplify automation, improve security, and retire unused customizations.
• Put governance in place, release process, design standards, documentation, and regular architecture reviews.