Salesforce Admin Interview Questions

Preparing for a Salesforce Admin interview requires mastery of platform fundamentals, automation capabilities, data governance, and the soft skills that define effective administration in enterprise environments. This guide covers the technical questions you’ll encounter, behavioral scenarios that test your decision-making, and strategic preparation for both 501 certification pursuit and real-world role success.

The Salesforce Administrator role has evolved beyond basic user management. Modern admins architect multi-cloud solutions, design scalable automation frameworks, and serve as critical bridges between business stakeholders and technical teams. Interviewers test not just knowledge recall but your ability to diagnose complex org issues, recommend solutions aligned with business strategy, and guide teams through change management.

Whether you’re pursuing your first admin role or interviewing at enterprise organizations, the questions here reflect what hiring managers actually ask. They progress from foundational platform concepts through advanced scenarios that mirror real org challenges. This is your roadmap to demonstrating both depth and maturity in Salesforce administration.

Core Salesforce Concepts

The foundation of Salesforce administration rests on understanding how the platform models business data and controls who can see it. These core concepts appear in nearly every admin interview because they determine whether you can effectively manage an org’s data model, security posture, and user experience.

1. Walk us through the differences between master-detail, lookup, and junction relationships. When would you recommend each?

Master-detail relationships create a strict parent-child dependency where deleting the parent cascades deletion to all children. They’re appropriate when child records have no business meaning without the parent. If you have a Quote with line items, that’s master-detail because quote lines cannot exist independently. Lookup relationships are looser associations. A related list appears on the parent but there’s no cascade delete. Contacts link to Accounts via lookup relationships because a contact might need to transfer between accounts. Junction relationships solve many-to-many scenarios through an object that acts as the bridge. If you need to track which Opportunities use which Products with specific quantities and pricing, that’s a junction object with master-detail to both parents. The performance consideration matters too. Master-detail creates stricter data integrity but burns through your relationship limit faster. Lookups are more flexible but require additional sharing rules if you need to control access based on the related parent. I generally recommend master-detail only when cascade deletion is truly required by business rules.

2. Explain the difference between Profiles and Permission Sets. How would you choose between them for managing user access?

Profiles are mandatory. Every user must have exactly one profile. They define baseline access: object CRUD, field-level security, page layouts, record types available, and login hours. Permission Sets are optional layers that grant additional permissions on top of the profile. The permission set model works because it’s purely additive. A user’s effective permissions are profile plus all assigned permission sets. This creates flexibility. If you have five departments with slightly different needs, you could create five profiles. Or you could create one standard profile and five permission sets, one per department. The permission set approach scales better because adding a sixth department variant doesn’t create a sixth profile. Permission Set Groups extend this further by bundling multiple permission sets into one assignable unit. Choose profiles for baseline, department-level, or role-driven access. Use permission sets for temporary access elevations, feature pilot programs, or cross-cutting permissions that multiple departments need. Permission set groups are valuable when you have complex permission combinations that multiple users share. In practice, I keep profiles minimal and lean heavily on permission sets for management flexibility.

3. What is Record Type and what scenarios justify creating multiple Record Types for the same object?

Record Type segments an object so different business processes can have different picklist values, page layouts, and validation rules. If you sell both products and services, Opportunities might have Record Type of “Product Sale” and “Services Engagement” with different picklist values for Stage. Product sales might have stages like Prospecting, Qualification, Proposal, Negotiation, Closed Won. Services engagements might have Discovery, Proposal, Signed, Implementation, Closed Won. Creating one record type per business process allows each to have the right field set and workflow. Multiple record types also let you apply different page layouts to the same underlying object. Maybe your Sales team sees a detailed layout while your Finance team sees a summary layout. Record Types enable that without creating duplicate objects. The caveat is that Record Types consume your picklist value limit. If you’re already pushing limits, junction objects might solve your problem more cleanly than Record Types. I’d create multiple Record Types when the business process is fundamentally different, when different user groups need different views, or when validation and automation rules truly diverge. If the difference is just one or two fields, it’s probably not worth the Record Type complexity.

4. Describe the Organization-Wide Default (OWD) and its role in Salesforce security architecture.

OWD is the foundation of Salesforce’s record access model. It answers the question: if I don’t explicitly share a record with someone, can they see it? OWD settings on each object range from Public Read Only (anyone can see but not edit), Public Read Write (full access unless you restrict with sharing rules), to Private (only the owner and those above in the role hierarchy can see it). Private is the most restrictive and most commonly used in complex orgs because it forces explicit sharing decisions. Once you set an object to Private, you then use sharing rules to grant access. A sharing rule can be criteria-based (all Opportunities in California where the Account industry is Healthcare) or owner-based (if the Opportunity owner is in the Enterprise Sales department). OWD cannot be made more restrictive than the profile allows. If the profile blocks read access, OWD doesn’t matter. OWD is the default for everyone. Role hierarchy is orthogonal. A user always has access to records owned by people below them in the role hierarchy, regardless of OWD. The key insight is that OWD is the outer boundary. Everything else (sharing rules, manual sharing, role hierarchy) expands access from there. Getting OWD right is crucial because changing it from Public to Private can suddenly restrict access for thousands of users and may break existing processes.

5. How do sharing rules work and when would you use criteria-based vs owner-based sharing?

Sharing rules grant access to records to users or groups who otherwise wouldn’t have it under OWD and role hierarchy. Owner-based sharing says “give this record to everyone whose record is owned by people in this role or queue.” If you set Account OWD to Private and create an owner-based sharing rule that shares all Accounts owned by the “West Region” role to the “Finance” role, then anyone in Finance can see all Accounts owned by anyone in West Region. Criteria-based sharing is more surgical. It says “give access to records matching these criteria.” Example: share all Opportunities with Amount greater than $1 million to the Executive Team. You’d set up a criteria-based rule with the filter Opportunity Amount > $1,000,000 and share to the Executive Team group. This is powerful because it makes access responsive to the data itself. If an Opportunity grows from 500K to 1.2M, it automatically becomes accessible to the Executive Team without needing a manual sharing action. The tradeoff is computation. Criteria-based sharing rules run on object update, which can slow down save operations if you have many rules with complex criteria. I use owner-based sharing for role-based access patterns and criteria-based sharing for threshold-based, risk-based, or strategic-tier access. Many admins underestimate how powerful criteria-based sharing is. It’s dynamic and self-maintaining once configured.

6. Explain Page Layouts and how they enable different user experiences on the same object.

Page layouts define what fields appear on a record detail page, their order, read-only status, required status, and which related lists are visible. By assigning different page layouts to different profiles or record types, you tailor the user experience without touching the data model. A Sales Rep sees a page layout focused on next steps, competitor intelligence, and deal size. The Finance user sees the same Account but with payment history, credit terms, and billing address prominent. Both use the same Account object. Different layouts. Page layouts also control whether a field appears. If you want to deprecate a field without deleting it, remove it from all layouts. If you want a field visible only to admins, create a custom layout and assign it only to the admin profile. You can also use layouts to make fields required in one context but optional in another. Maybe Revenue is required for accounts in North America but optional for prospects. Create two Account record types, assign different layouts to each. The required setting on the layout makes that happen. Lightning App Builder has expanded page layout flexibility with dynamic forms, which adjust field display based on conditions. Lightning Flows can also substitute for some layout logic. Still, page layouts remain the primary tool for field-level UX customization without code.

7. What is the role hierarchy and how does it interact with sharing rules and OWD?

The role hierarchy is a tree structure where each user has a role and roles have parent roles above them. A critical rule: a user always has read access to all records owned by people below them in the hierarchy, regardless of OWD or sharing rules. This is automatic and cannot be turned off. If you’re VP of Sales, you see all opportunities owned by your Sales Managers and their Reps. The power is in setting it up correctly because hierarchy violations create security holes. If a Sales Rep reports to a Sales Manager, and that Manager is not on a clear reporting line to a VP, then people can slip outside the hierarchy and have security gaps. The hierarchy feeds into role-based sharing rules. When you create a sharing rule “share to the Sales Management role,” you’re often thinking hierarchically. Everyone in that role gets access. The hierarchy matters for read visibility but not for record ownership. If I have access to a record, I don’t necessarily own it, and I cannot transfer ownership of records I don’t own. Many orgs use the hierarchy as their primary access control mechanism, keeping OWD more open and relying on the hierarchy to push data down to managers. Others use Private OWD and explicit sharing rules. Both work if designed consistently. The trap is mixing models inconsistently, creating confusion about who can see what.

8. Describe manual sharing. When should admins allow users to manually share records versus restricting it?

Manual sharing, also called “sharing” in Salesforce UI, lets record owners (and admins) grant access to specific users or groups for specific records outside the normal sharing rules. On an Opportunity, the owner can click “Share” and add the VP of Sales or Finance team to that one deal. It’s flexible and responsive to exceptions. The downside is that it’s not auditable at scale. You can’t easily run a report on “which users have manually shared this record and to whom.” Manual sharing creates exceptions to your intended security model and is easy to forget about when people leave the company. For sensitive data, I restrict manual sharing. Set the object’s sharing settings to “Only allow access via sharing rules and role hierarchy.” For more open objects where collaborative sharing is normal, I allow it. It reduces the burden on admins to create sharing rules for every exception. The middle ground is to allow manual sharing but train users and periodically audit it. The trade-off is between flexibility and control. Highly regulated industries tend toward restricting manual sharing to maintain audit trails. Less regulated, collaborative organizations embrace it for speed.

9. What are Queues and how do they fit into your access control strategy?

A Queue is a holding area for records. You can assign records to a queue instead of a specific user. Then multiple people can claim items from the queue. If you have a support org, you might have a “New Support Cases” queue. Cases arrive there and any support agent can claim them. It distributes workload fairly if you set up queue membership correctly. Queues are also useful in sharing rules. You can share records to a queue, and everyone in that queue automatically has access. Queues are often more maintainable than creating groups because queue membership can be dynamic if you use role-based membership. Add a new person to the Sales role and they’re automatically in any queue defined as “Sales role members.” The limitation is that records can only be assigned to a queue if the queue is defined as the assignee for that object type. Not all objects support queue assignment. Leads, Cases, and some custom objects do. Opportunities do not, which surprises many people. Queues are most valuable in high-volume, distributed workload scenarios. If you have a small team where everyone sees everything, queues add complexity without benefit. If you have hundreds of new leads arriving daily and you need to distribute them fairly, queues are essential.

10. Explain List Views and their role in user adoption and day-to-day usability.

List Views are saved filtered views of object records. A List View for Opportunities might show “Open Deals in California, probability higher than 50 percent.” Every time you open that list view, it refreshes the filter. List Views are the primary way users stay focused on their work. Good list views dramatically improve adoption because users see the data that matters to them immediately. You can set a list view as the default list to display when a user opens the Opportunities tab, creating a personalized entry point. List Views also support automation. A flow can read from a list view to find records matching criteria. You can make list views visible to specific profiles, so the Sales team doesn’t see the Finance team’s list views. From an admin perspective, good list view hygiene matters. Orgs with hundreds of unused list views become confusing. I recommend standardizing naming and documenting purpose. List views are also your first debugging tool when a user says “I can’t find my records.” Check the list view filters. Often the issue is user error (applying too restrictive a filter) rather than a security configuration problem. List Views can also drive adoption because they’re intuitive. New users understand filters immediately. Flows and reports are more powerful but also more intimidating.

11. What is the difference between Territories and how do they affect sharing and reporting?

Territories are an optional layer that overlays on top of your normal access model. They let you define geographic, customer, or industry-based sales regions, and you can assign records to territories independently of record owner. A user can own a record but be outside the territory. A Salesperson can be in multiple territories. Territories create independent access overlays. You might have one territory for Enterprise customers and another for Midmarket customers. Territory members automatically get access to all records assigned to their territory. The Territory model is valuable when your natural access hierarchy doesn’t align with your selling territories. If your org chart is US East, US West, and US Central but your selling territories are Healthcare, Finance, and Manufacturing, and those don’t align geographically, Territories let you model the selling side without restructuring the org chart. The complexity is that Territory setup requires careful planning. Enabling Territories changes how record access works. The pitfall is creating Territories as a temporary solution and then discovering that managing Territory assignments and Territory hierarchy becomes a parallel org chart. I’ve seen Territories create more admin work than they solve when they’re not truly necessary. If your role hierarchy aligns with your access needs, Territories may be unnecessary overhead. If your access model is fundamentally different from your org chart, Territories are invaluable.

12. Describe best practices for testing and troubleshooting access issues before they affect production users.

Access issues are the most common admin support requests. Testing before changes is crucial. Always test in a sandbox or test org first. Create a test user with the target profile, assign the permission sets or record types you plan to roll out, and verify they can see and edit the expected records. Use the “Login As” feature in Setup to test as a specific user. This logs you in as that user from the backend without needing their password. Check sharing settings for the objects they need to access. Pull the sharing report to see what access is actually granted. The sharing report shows every sharing rule, manual share, and role hierarchy connection. If a user can’t see a record they think they should see, the sharing report usually reveals the issue. Also test negative cases. Verify that a user cannot see records they shouldn’t. If a user in the East region has a list view that shows their own deals plus their manager’s deals but not the West region’s deals, verify that filter is working. Use the debug log if access rules are complex. Enable the Apex debug log for the user and perform the action that’s failing. The log will show you exactly what security checks fired and why. For data access troubleshooting, the “Sharing” button on a record is your best friend. Click it and you see exactly who has access to that specific record and why. That instantly answers most access questions.

Flow and Automation

Automation is where Salesforce Admins deliver value beyond data management. The platform offers multiple automation tools with overlapping capabilities. Knowing when to use Flow versus formula fields versus Process Builder is critical for building scalable, maintainable solutions.

1. Explain the six types of Flow and when you would use each.

Cloud Flows include Screen Flow, which is a user-facing automation where users enter data and see results. If you’re building a self-service wizard to create a record or request something, that’s a Screen Flow. Record-Triggered Flow automates on record create or update. This replaced Process Builder for most use cases. If you want to create a child record every time a parent is updated, or send an email when a record matches certain criteria, you’d use a Record-Triggered Flow. Scheduled-Triggered Flow runs on a schedule. Every night at midnight, find all overdue opportunities and email the owners. That’s a Scheduled-Triggered Flow. There are also Platform-Triggered and External-Triggered flows for advanced integration scenarios. The sixth traditional type is Autolaunched Flow, which is invoked by another process like a Process Builder, another Flow, or Apex code. For most admin needs, you’ll work with Screen Flow for interactive processes, Record-Triggered Flow for automation on save, and Scheduled-Triggered Flow for batch operations. Screen Flows are powerful for guiding users through complex processes with branching logic. Record-Triggered Flows are the modern Salesforce automation standard. Scheduled-Triggered Flows are your batch processing tool. Master these three and you can automate almost anything without writing code.

2. Describe when you’d use Flow versus legacy automation tools like Process Builder and Workflow Rules.

Workflow Rules and Process Builder are deprecated. Salesforce is sunsetting them. Any new automation should use Flow. Workflow Rules were simple rule engines for field updates and email alerts. Process Builder was more powerful, supporting decision logic and multi-step processes. Both have limitations that Flow eliminates. Flow handles complex logic with loops, subflows, and variable manipulation. Flow supports synchronous and asynchronous execution. Flow can make API callouts to external systems. Flow is visual and code-free. If you inherit an org with Workflow Rules and Process Builder, plan migrations to Flow. The migration isn’t difficult but it does take time. For new development, never use Workflow Rules or Process Builder. Sell your stakeholders on Flow. It’s the future and it’s more powerful. Some admins hesitate to migrate legacy automation because “it’s working.” That’s true, but the cost of maintaining legacy tool is growing as Salesforce deemphasizes them. Every Salesforce release adds Flow capabilities. Eventually those tools will be removed. Migrating proactively is always better than being forced to migrate later.

3. What are Flow best practices and how do you structure complex automation for maintainability?

Modular design is essential. Create small Flows that do one thing well, then call them as subflows from a parent Flow. If you need to send an email and create a record and update a related parent, that’s three separate Flows called from a main orchestration Flow. This makes each Flow testable and reusable. Name Flows clearly. “Account_UpdateRelatedContactCount” tells you the object, the action, and the purpose. Use descriptive variable names. If you see a variable called “var1” inside a complex Flow, that’s a maintenance headache. Comments inside Flows are your friend. If a logic branch does something non-obvious, add a comment explaining why. Version your Flows. Salesforce stores Flow versions but not all orgs maintain naming discipline. Before modifying a Flow, create a new version. Keep the old version accessible for rollback if needed. Test Flows thoroughly before deploying. Use test data that exercises all branches. If your Flow has a decision that branches on record type, test all record types. Flows can get expensive from a governor limit perspective. A Scheduled Flow that loops through 100,000 records and makes an API callout for each one will hit your daily callout limit. Design accordingly. Async-triggered Flows can be more expensive than synchronous because they run in the background. Monitor your Org Limits page and set up alerts if you’re approaching callout limits. Large batch operations should often be handled by Scheduled Flows that process smaller chunks repeatedly rather than one massive Flow that tries to do everything at once.

4. How do Approval Processes work and what approval patterns should admins consider?

Approval Processes route records through multiple approval steps based on criteria you define. A Purchase Request might require Manager approval for under 5K, Director approval for 5K to 50K, and VP approval for over 50K. You’d create one Approval Process with three approval steps. When a request is submitted, Salesforce evaluates it against the approval criteria and routes it to the correct approver. Each approver sees a task in their task list. They approve or reject. If approved, the next step approves or rejects. If any step rejects, the record returns to the submitter. Approval Processes can trigger actions on approval or rejection. Update a field, send an email, create a record. This is powerful for complex approval chains. The limitation is that Approval Processes are harder to maintain than Flows. Moving beyond three approval steps becomes complex. If you need conditional routing (sometimes approve goes to Manager, sometimes to Director), that’s still possible but the setup is intricate. Approval Processes vs Flows is an ongoing debate. Approval Processes have cleaner UI for pure approval scenarios. Flows are more flexible for anything beyond standard approval chains. I typically recommend Flows for new approvals because they’re more maintainable long-term.

5. Explain formula fields with examples. What are the performance implications of complex formulas?

Formula fields are read-only fields that calculate values based on other fields. A common example is Full Name combining First Name and Last Name. The formula would be FirstName & ” ” & LastName. Formula fields display anywhere the field appears, including reports. They’re powerful because they’re dynamic. If a First Name changes, the Full Name updates instantly without any automation. Complex formulas can do date math, conditional logic, and text manipulation. Example: IF(DAYS_BETWEEN(TODAY(), DueDate) < 0, "Overdue", "On Track"). This shows "Overdue" if the due date is in the past. Formula fields don't consume API calls or actions. They're computed on retrieval. The cost is that every time you fetch a record with a complex formula field, Salesforce evaluates the formula. In large queries or reports with complex formulas, that computation adds up. I've seen orgs slow down reporting because someone created a formula field that calls VLOOKUPs across multiple objects in a complex nested IF structure. Best practice is to keep formula fields relatively simple. If you find yourself writing deeply nested IF statements, consider whether that logic belongs in automation instead. For cross-object calculations, use rollup summary fields instead. They're designed for that use case and are more efficient.

6. Describe validation rules and provide examples of common use cases.

Validation Rules prevent saves if conditions are met. They fire before the record is saved, allowing you to enforce business rules. A simple example: IF(ISNULL(BudgetAmount), true, BudgetAmount > 0). This requires BudgetAmount to be greater than zero if it’s filled in. The error message would be “Budget must be greater than zero.” Complex validation rules can enforce cross-field logic. IF(Status = “Closed Won” AND ISNULL(ClosedDate), true). This says if status is Closed Won, Closed Date must be filled. This prevents status changes that leave the record incomplete. Validation rules fire synchronously, so they prevent bad data immediately. The challenge is that overly strict validation rules frustrate users. If your rule prevents a sales rep from saving a deal with an empty next step, and sometimes that data isn’t available yet, your rule is too strict. It’s better to have fewer, well-thought-out validation rules that enforce true business requirements than many rules that prevent normal work. Validation rules also don’t apply to batch operations. If you use Data Loader to import 10,000 records, validation rules don’t run. That’s by design because validation rules would block the import. Batch imports need their own validation strategy. In automation Flows, validation rules don’t prevent the action. Only the UI respects them. So if your Flow creates records programmatically, validation rules won’t stop it. This is sometimes a feature (you bypass validation intentionally) and sometimes a bug (you expected validation and it didn’t run). Know the context.

7. Explain rollup summary fields, their limitations, and when to use them.

Rollup summary fields aggregate related records. On an Account, you might have a rollup summary that counts all child Opportunities. The formula would COUNT. Every time an Opportunity is created under that Account, the count updates. Common aggregation functions are COUNT, SUM, MIN, MAX, and AVG. If you want total expected revenue from all Opportunities on an Account, you’d create a SUM formula on the Opportunity Amount field. Rollup summary fields are efficient because they’re database-computed. You get better performance than writing a Flow that loops through child records. Limitations are significant though. Rollup summary fields only work on master-detail relationships, not lookups. If your Opportunity has a lookup to Account instead of master-detail, you cannot create a rollup summary on the Account. You’d need to use a formula field or Flow instead. Rollup summary fields also count against your field limit. Each one takes a slot. If you’re near your limit, be strategic about which rollups are truly needed. The other limitation is that rollup summary fields can slow down saves on the parent. Creating an Opportunity on an Account with five rollup summary fields means Salesforce recomputes all five rollups. For high-volume objects, that’s a consideration. Still, for most cases, rollup summary fields are the right choice for aggregation. They’re reliable, they’re standard, and they’re performant.

8. What are cross-object formulas and when would you use them instead of rolls-up summary fields?

Cross-object formulas read fields from related records. On a Contact, you can create a formula that displays the parent Account’s Industry. The formula would be Account.Industry. This is read-only but it’s useful for reporting and UI context. Unlike rollup summaries that aggregate multiple child records, cross-object formulas read a single related field. The power is that you can reference related records through multiple levels of relationships. On a Contact, you could display Account.ParentAccount.Industry if your Account has a self-lookup to a parent account. Cross-object formulas are lighter-weight than rollup summaries. They don’t require a master-detail relationship. They work with lookups. Use cross-object formulas when you need to display a single related field. Use rollup summaries when you need to aggregate. The distinction matters because rollups are more “expensive” from an org-limit perspective but are the right tool for their use case. If I see someone trying to build a complex rollup summary when they really just need to display a single field, I’d recommend a cross-object formula instead.

9. Describe custom metadata types and how they enable flexible, maintainable configuration.

Custom metadata types are custom settings on steroids. They’re configuration data that travels with your Flows, Apex code, and org as you deploy changes. If you have a custom configuration table that lists credit ratings with credit limits, instead of creating a custom object, you’d use a custom metadata type. Custom metadata types are deployed as metadata, not as data. This means they’re part of your org backup and migrate with your code. Regular objects are data. If you back up an object, then restore to a different org, the data comes too. With custom metadata, the configuration is part of the deployment package. Queries against custom metadata types are different from object queries. You use “Type.Name” syntax. Example: SELECT Label, CreditLimit FROM CreditRating__mdt WHERE Name = ‘AAA’. The “__mdt” suffix indicates it’s a custom metadata type. Custom metadata types are powerful in managed packages because they provide configuration without exposing data. If you’re building a reusable solution, custom metadata types let customers configure it without direct data access. The limitation is that you can’t easily edit custom metadata types outside of Setup. There’s no separate UI for data entry like there is for regular objects. You either edit via Setup or use the Metadata API. For heavily edited configuration, a regular custom object might be more practical. Custom metadata types are best when the configuration is set once and rarely changes, or when you’re building a managed package.

10. How do scheduled jobs and batching work in Salesforce? When would you choose different approaches?

Scheduled Jobs are Apex batch jobs that run on a schedule. You might have a nightly job that recalculates all opportunity forecasts. From an admin perspective, you can monitor scheduled job execution via Setup. Most admins won’t write the Apex batch code themselves but will understand that scheduled jobs exist and request them from developers for complex business logic. Salesforce Flows can handle many scheduling needs without Apex. A Scheduled-Triggered Flow can run every night and update records. For simple logic, Flow is sufficient. For complex logic that pushes governors, batch Apex is more efficient. Batch Apex can process larger dataset with less resource usage per iteration. If you need to process 100,000 records, batch Apex is the right tool. A Flow processing 100,000 records would consume more transactions and be less efficient. From an admin perspective, understanding the tradeoff helps you spec requirements correctly to developers. Don’t request an Apex batch job for a simple nightly update that Flow can handle. Do request it when you need to process millions of records efficiently. Queued Apex is a third option for asynchronous work. It’s simpler than batch and useful for jobs that need to process thousands, not millions. The admin role typically doesn’t build any of these but needs to understand their existence and purpose to architect solutions correctly.

Data Management

Data is the foundation of Salesforce value. Poor data management undermines every other capability. The questions here test your understanding of how data moves in and out of Salesforce, how you prevent duplicates, and how you maintain data quality.

1. Explain the differences between Import Wizard and Data Loader. When would you use each?

Import Wizard is a point-and-click tool in Setup for importing a small batch of records, typically under 5,000. You upload a CSV, match columns to fields, and click Import. Validation rules run. Duplicate matching rules can prevent duplicates. It’s user-friendly but limited. Data Loader is a desktop client or command-line tool for high-volume imports, typically 5,000 to hundreds of thousands of records. Data Loader bypasses validation rules by default, making imports faster. You can toggle validation on if you need it. Data Loader can also export data, making it useful for extracting records for analysis. Data Loader is an API client under the hood, so it respects record-level security and field-level security. If an import user doesn’t have access to a field, the field won’t be imported even via Data Loader. From an admin perspective, use Import Wizard for small, infrequent imports where you want validation and user-friendly feedback. Use Data Loader for regular imports, large batch sizes, or integration scenarios where you need command-line automation. Data Loader integrates with scripts. You can create a scheduled import via a shell script that runs Data Loader regularly. Many data synchronization tools use Data Loader under the hood for this reason.

2. What are external IDs and how do upserts work?

An external ID is a field you mark as a unique identifier for matching. If your Contacts have an Employee ID field that’s guaranteed unique, you’d mark it as an external ID. Then you can upsert based on that field. A CSV with Contact records includes an EmployeeID column. Data Loader upsets the file, matching by EmployeeID. If the EmployeeID already exists, the record is updated. If it’s new, the record is created. This is powerful for data synchronization. If your HR system exports employee data every morning, you can upsert against Salesforce using Employee ID as the external ID. External IDs bypass the record ID requirement. Normal updates require the record ID (Salesforce’s unique identifier). Upserts let you use a business identifier instead. You can have up to 3 external IDs per object (if you mark a field as external ID). Upserts can match on up to 3 fields at once. You could upsert on a combination of Company and Email if both together are unique. External IDs enable a key pattern where your source system is the source of truth and Salesforce syncs from it. Many integration architects rely heavily on external IDs for data sync implementations.

3. Describe Duplicate Rules and Matching. How would you set up a duplicate prevention strategy?

Duplicate Rules define what counts as a duplicate. A Matching Rule defines the criteria. You might create a Matching Rule that compares first name, last name, and email. Two records with the same name and email match. Then you create a Duplicate Rule that uses that Matching Rule and defines the action on duplicate: alert the user or block the save. If you set the rule to alert, a user creating a Contact that matches an existing Contact sees a warning but can proceed. If you set it to block, the save fails. Most orgs allow alerts but block creates of exact matches. Duplicate Rules are powerful if designed thoughtfully. An over-broad rule that alerts on name alone creates false positives and frustrates users. An under-broad rule that requires name, email, and phone misses duplicates. Finding the right criteria takes iteration. I recommend testing duplicate rules thoroughly before enabling them. Create test data that’s clearly duplicate and verify the rule catches it. Create test data that’s similar but not duplicate and verify the rule allows it. Duplicate Rules fire during record create and update, not on import by default. You need to enable “Check for Duplicates During Import” in Data Loader settings to enforce duplicates during bulk operations. Many orgs have old data with duplicates. Duplicate Rules prevent future duplicates but don’t clean up existing ones. That’s a separate project.

4. What are best practices for managing mass data operations and avoiding disruption?

Mass data operations like large updates, deletes, or imports can consume significant database resources and lock records, disrupting users. Plan these during maintenance windows when users aren’t active. If you must run during business hours, notify users and coordinate with teams that might be affected. Use batch processing for large operations. Don’t try to update 500,000 records in one operation. Run the update in chunks of 10,000 or 50,000. This reduces locking time and makes the operation more resilient. If one chunk fails, you restart from there instead of restarting the entire operation. Test in a sandbox first. If you’re updating a field that drives automation, test that automation fires correctly with your bulk data. Test in a sandbox that’s a refresh of production. Sometimes the data distribution in sandboxes differs from production, and logic that works in a test sandbox fails at production scale. For deletions, be especially careful. Deletes are permanent and can cascade if you’re deleting parent records with master-detail children. Create a backup or export before bulk deletions. Some orgs maintain a deletion log in a separate object where deleted record details are stored before removal. This allows for auditing and recovery if needed. Also consider your Recycle Bin. Deleted records live there for 15 days, giving you a safety net if the deletion was wrong.

5. How do you approach data archiving? What are options for managing historical data without impacting performance?

Archiving is removing old data from your live org to improve performance and reduce data storage costs. Salesforce charges based on storage, so archiving can reduce costs. The challenge is that once data is archived, it’s not immediately queryable in Salesforce. Options include exporting to a data warehouse like Tableau CRM or Snowflake, moving to a cold storage system, or simply deleting with a backup. Most enterprise orgs maintain a data warehouse for historical analysis, so they export old data there and delete from Salesforce. This keeps Salesforce lean for operational use while preserving historical data for reporting. Another approach is moving to a separate Salesforce org for historical data. This is expensive but maintains Salesforce queryability. For smaller orgs, archiving might simply be exporting to a data lake and deleting from Salesforce. The first step is defining your retention policy. Which records are archived after how long? A Contact that hasn’t been touched in three years is probably archivable. A Closed Won Opportunity should probably be kept longer because finance and legal might need it for reporting and audits. A retention policy balances compliance, reporting needs, and performance. Once you have the policy, implement it. You can use a scheduled Flow to identify records matching your archival criteria, export them, and delete. This can be automated. The risk of archiving is that someone queries old data and doesn’t find it in Salesforce. They assume it was deleted or lost rather than archived. Good documentation and communication about archival policies prevent confusion.

6. What are Salesforce backup options? How would you design a backup and recovery strategy?

Salesforce provides automated daily backups stored for 29 days. If data is deleted or corrupted, you can restore from a backup, but restoration is time-consuming and requires a support ticket. For better control, many orgs use third-party backup tools that snapshot the entire org, including metadata and data, and allow point-in-time recovery. Third-party tools are more expensive but provide faster recovery and better granularity. You might recover just one object rather than the entire org. From a continuity perspective, understand that Salesforce itself is highly redundant. Single-record deletion or corruption is rare due to their engineering. The bigger risk is human error or a bad batch automation that updates the wrong records. For that, backup and recovery is essential. The strategy depends on the org’s criticality. A production org for a large company should have third-party backup. A small org might rely on Salesforce’s automated backup with disciplined change control to prevent bad changes in the first place. Also maintain code version control. Your Flows, page layouts, and other config should be in a source control system like GitHub. This lets you recover code without requiring a data restore. Separating data recovery and code recovery is a good practice.

7. How does GDPR affect your Salesforce administration? What processes should you have in place?

GDPR gives individuals the right to request their data be deleted. If a Contact from the EU requests deletion, you must delete their record and all related records. This has direct implications for Salesforce admins. First, you need processes to identify individuals and find all their data. If someone requests deletion, you need a way to query “all records related to this person.” Many orgs build custom solutions for this because Salesforce doesn’t have a built-in GDPR handler. You’d create a Flow that finds the Contact, deletes it, and cascades through related records. You also need a way to document that the deletion was requested and processed, for audit purposes. Second, you need to understand data residency. Some regulations require personal data to stay within a geographic region. GDPR allows data in the EU or UK data centers but not the US. If you have EU users, you might need an EU data center instance. This affects where you create your Salesforce org. Third, you need to think about data minimization. Don’t collect fields you don’t need. If you don’t need a Contact’s phone number, don’t ask for it. Less data is easier to comply with if a deletion is requested. Finally, maintain documentation of what data you collect, where it’s stored, and how long you keep it. This satisfies the transparency requirements of GDPR. Many admins underestimate the GDPR impact. It requires cross-functional coordination with legal and privacy teams. If you’re in a regulated industry or serve EU customers, GDPR should inform your data architecture.

8. How would you design a data quality strategy for your Salesforce org?

Data quality is continuous. Start by assessing current state. Audit your objects and fields. Which fields have high null rates? Which have inconsistent formats? A Contact list with phone numbers in forty different formats is a quality problem. Run reports on your critical objects. How many Leads have no email? How many Opportunities have no close date? These diagnostics drive your improvement plan. Common improvements include: standardizing picklist values (don’t allow “Open” and “open” as separate values), enforcing required fields at the point of entry (via page layout or validation rule), and regularly cleaning existing data. For cleaning, use Data Loader to standardize formats. Apex code can clean programmatically. A batch job could capitalize all city names or trim extra spaces from phone numbers. Training is critical. If your Sales team enters data inconsistently, automation and validation are band-aids. You need to train users on the importance of consistent data. Incentivize quality. Some orgs tie sales commission eligibility to data completeness. If you can’t get a deal closed because the Opportunity is missing required fields, Sales gets focused on data entry. Governance is important too. Appoint a data steward or data quality owner. This person is responsible for monitoring quality, recommending improvements, and owning the strategy. Without an owner, data quality degrades because nobody is responsible for it. Finally, measure and report. Create a dashboard showing key quality metrics. How many Leads are missing email? How many Accounts are missing industry? Visibility drives improvement.

Reports and Dashboards

Reporting is how Salesforce delivers business intelligence. Admins don’t always build reports, but they need to understand reporting architecture and help users find the data they need.

1. Explain the four report types and when you would use each.

Tabular reports show records in rows and columns, like a spreadsheet. They’re simple and fast. If you want a list of all Opportunities with amounts and close dates, tabular is appropriate. Summary reports add grouping and subtotals. The same Opportunity data grouped by sales stage with subtotals by amount shows pipeline health. Summary reports take more processing but provide analytics in one view. Matrix reports have two dimensions. Rows might be sales rep and columns might be sales stage. The intersection shows count of opportunities. This is powerful for comparative analysis. Finally, Joined reports combine multiple report types. You might join an Opportunity report with an Account report to show Account name, Industry, and Opportunity stage in one report. Joined reports are flexible but more complex to build. From an admin perspective, understand which report type suits the use case. If users just need a list, tabular is fine. If they need analysis, summary or matrix is better. Joined reports are usually built by power users or admins because they require more setup.

2. What are bucket fields and how do they enhance reporting?

Bucket fields categorize values into buckets. If you’re reporting on Opportunities by Amount, you might bucket them: Small (0-100K), Medium (100K-500K), Large (500K+). Instead of seeing hundreds of unique amounts, you see three buckets. This simplifies analysis. Bucket fields are created in the report UI and exist only in that report, not in the underlying data. You can also create formula fields in reports that perform calculations. If you want to show each Opportunity’s discount percentage (discount divided by list price), you’d create a formula field in the report. Report formula fields are read-only and exist only in the report. They don’t modify the underlying object.

3. What are cross filters in reports and how do you use them?

Cross filters let you filter based on the existence of related records. Example: show all Accounts that have at least one closed won Opportunity. The Account report has a cross filter that checks for related Opportunities with Status = Closed Won. Cross filters are powerful for finding records with or without related data. You can also invert the filter: show all Accounts that have no Opportunities. This finds orphaned accounts. Cross filters work with any related object, making reports flexible for multi-object analysis.

4. What are dashboard types and how do they differ?

The traditional dashboard type is the analytical dashboard, which displays multiple report results as tiles. Each tile is a report embedded in the dashboard. If you have five reports and want to see them all on one page, you’d create a dashboard with five tiles. Dynamic dashboards execute the dashboard filters as the logged-in user, providing personalized views. If a sales manager views a dynamic dashboard, the tiles show their own team’s data. Regular dashboards show the same data to everyone. Finally, Einstein Analytics (formerly Tableau CRM) dashboards are more advanced, with interactive filters and dynamic calculations. They’re less commonly used by pure admins but are becoming more popular as Salesforce pushes analytics. Traditional dashboards are the starting point for most orgs.

5. How do you create effective dashboards that drive user adoption and decision-making?

Good dashboards are focused. Don’t try to show everything on one dashboard. Create targeted dashboards for different roles. A Sales Executive dashboard shows pipeline health and forecast. A Customer Success dashboard shows customer health and expansion opportunities. Focused dashboards are more useful than kitchen-sink dashboards. Use visualizations wisely. KPI tiles for metrics, charts for trends, tables for details. The visualization should match the data story you’re telling. Also consider drilldown. If a chart shows pipeline by stage, let users click a stage to see the underlying opportunities. This drives exploration and adoption. Make dashboards real-time or refresh frequently enough that users trust the data. If a dashboard is stale, users ignore it. Finally, make dashboards accessible. Pin them to the home page or make them the first thing users see when they open Salesforce. The more visible, the more used.

6. What is CRM Analytics (Einstein Analytics) and how does it differ from traditional reporting?

CRM Analytics is a separate analytics platform within Salesforce that provides more advanced analysis, machine learning, and predictive capabilities. Traditional reporting is query and display. CRM Analytics can recommend next steps, predict outcomes, and identify patterns. It requires data preparation (building data flows) and is more complex to set up than traditional reporting. For most admins, CRM Analytics is a specialist tool. You’d recommend it for advanced analytics needs. Many orgs don’t need CRM Analytics because traditional reporting covers their needs. It’s more valuable in large organizations with data science teams and complex analytics requirements.

7. How do scheduled reports work and what’s a good use case?

Scheduled reports run on a schedule and email results to recipients. This is automation for reporting. You’d schedule a report on “New Leads This Week” to email the sales team every Friday morning. When the team arrives, they have the report in their inbox. This drives action without the team needing to remember to run the report. Scheduled reports use the report creator’s security context, so they see all data the creator has access to. If an admin creates a report and schedules it to the team, the team sees data the admin can see, which is usually everything. This is useful when building reports that show org-wide data but you want them delivered regularly to specific users. The limitation is that scheduled reports send at the same time to everyone, showing the same data. If you need dynamic reports that show each user their own data, dynamic dashboards are better.

8. Describe best practices for creating reports that are performant and easy to maintain.

Large reports can slow down the system. A report on 1 million Opportunities with many summary buckets and formulas takes time to run. Build reports with filters to limit scope. Instead of reporting on all Opportunities in the system, report on this fiscal year’s opportunities. Avoid complex cross-object relationships. Joining three or four objects is fine. Joining seven objects in a joined report is slow. Use the report builder to preview row counts. If a report returns 100,000 rows, that’s a sign it needs more filtering. Name reports clearly. “Revenue by Sales Rep” is better than “Report 1”. Document report purpose if it’s not obvious from the name. Delete unused reports periodically. Orgs accumulate reports that nobody uses. Removing them reduces clutter and improves the user experience when browsing available reports. Finally, audit who has access to create reports. In small orgs, everyone can create reports. In large orgs, you might restrict report creation to analysts and require admins to review reports before distribution. This prevents report sprawl.

Security Model

Security is foundational to Salesforce administration. A single misconfigured security setting can expose sensitive data to unintended users. Interviewers will explore your mental model of Salesforce security architecture.

1. Walk through the hierarchy of Profile versus Permission Set to Permission Set Group. How does each layer work and what’s your deployment strategy?

Profile is the base layer. Every user must have exactly one profile. The profile defines baseline permissions. Permission Sets are optional layers added on top of the profile. A user can have unlimited permission sets. Permission Set Groups bundle multiple permission sets into one assignable unit. The hierarchy is cumulative. A user’s actual permissions are profile permissions plus all assigned permission sets plus all permission set groups they’re assigned to. The enforcement is: profile sets the ceiling for an object (can the user CRUD this object?) and field (can the user see this field?). Permission sets and PSGs can only increase permission from there, never restrict. If the profile blocks read access to a field, no permission set can grant it. This is important because it means the profile is the gate and everything else refines within that gate. Strategy: Keep profiles minimal and role-based. Marketing profile, Sales profile, Support profile, Admin profile. Then use permission sets for feature access. A permission set for Salesforce CPQ, one for Einstein, one for a custom app. Then use permission set groups to bundle related permission sets. This scales better than creating profiles for every combination. As your org evolves and you need a new capability, add a permission set, not a new profile.

2. Explain how OWD settings affect security and walk through implications of changing OWD after launch.

OWD is the default access level. If you set an object’s OWD to Public Read Only, every user can see every record of that object, but they can’t edit. This is permissive. If you set it to Private, only the owner and their managers in the role hierarchy can see records. This is restrictive and requires explicit sharing. The implication of going from Public to Private is that you suddenly restrict access for many users. Reports and queries that worked might stop working. If you change an Account OWD from Public Read Write to Private, and you have a sharing rule that grants access to the Finance team, Finance suddenly can’t see any accounts except those explicitly shared. This can break processes. Before changing OWD in production, plan the change. Create a sharing strategy that compensates for the new restriction. Test in a sandbox. Identify which reports and processes will be affected. Communicate the change to users. Changing OWD is not something to do casually. Many admins set up OWD incorrectly at launch and are afraid to change it because of the disruption. If you inherit an org with permissive OWD and need to secure it, plan for multiple months. You’ll need to create sharing rules, update processes, test thoroughly, and manage user expectations. The lesson is to think about OWD early. If you’re building a new org, start with Private OWD and use sharing rules to grant appropriate access. It’s easier to open up access than to restrict it later.

3. How does role hierarchy behavior affect security architecture?

Role hierarchy automatically grants read access downward. A user always sees records owned by people below them. The role hierarchy cannot be circular. You cannot have User A manages User B and User B manages User A. Users at the top of the hierarchy see records from everyone below them. This is powerful for management visibility but also a security consideration. If you want to prevent a user from seeing a peer’s records, you cannot use role hierarchy. Role hierarchy is independent of OWD. Even if OWD is Private, the role hierarchy still grants access. You cannot override the role hierarchy with sharing rules to restrict a manager’s view of their team. The role hierarchy is inviolable in that direction. This is why role design matters. If your role hierarchy doesn’t match your actual organizational structure, you end up with access that doesn’t make sense. I’ve seen orgs where someone is in a role that reports to multiple people, and they have to choose one as their manager in Salesforce. This creates mismatches. Design your role hierarchy to mirror the actual org structure as much as possible.

4. Describe the mechanics of sharing rules and how to troubleshoot them when they don’t work as expected.

Sharing rules grant access beyond OWD and role hierarchy. They’re the fine-tuning mechanism. If a sharing rule doesn’t work, first verify the OWD allows it. If OWD is Private, sharing rules can grant access. If OWD is Public Read Write, sharing rules are mostly unnecessary because everyone already has access. Second, check the rule is active. A deactivated sharing rule doesn’t grant access. Third, verify the criteria. If your criteria-based sharing rule says “grant access where Amount > 1 million” and the record has Amount of 500K, the rule doesn’t apply. Check the data. Fourth, verify the target is correct. If you’re sharing to a role, verify the recipient is in that role. Trace membership. If you’re sharing to a queue, verify the queue has members. Fifth, check for conflicting rules. If you have rule A granting read access and rule B granting no access, the more permissive wins. Salesforce grants read if either rule says read. But if you have rule A saying read and rule B saying read-write, the result is read-write. Access is cumulative. Finally, clear cache. Sharing rule changes can have delayed visibility. Run the Recalculate Sharing Rules job if you suspect caching. From the Setup search, find “Recalculate Sharing Rules” and run it manually. It refreshes sharing calculations.

5. What is Field-Level Security and how does it interact with OWD and other access controls?

Field-Level Security (FLS) controls whether a user can see and edit individual fields, independent of object-level access. You might grant a user read access to the Contact object via profile but hide the SSN field from them via FLS. This is powerful for data privacy. Sensitive fields can be exposed only to specific roles. The mechanics are that FLS is evaluated at the field level. You assign field visibility per profile and permission set. If the profile hides a field, no permission set can reveal it (like object permissions, FLS is not additive across permission sets; the most restrictive is applied). FLS applies to all interfaces: Salesforce UI, APIs, reports. If a field is hidden by FLS, the user cannot see it via API either. This is important for integration security. If an external system authenticates as a Salesforce user, FLS still applies to what that system can access. FLS is foundational for compliance. If you handle payment card data, you might hide the card number field from most users. If you handle health information, you hide sensitive fields. FLS is your mechanism for that protection. Test FLS thoroughly. Create test users with target profiles and verify they cannot see hidden fields. Forgot to hide a field from the Sales profile and now Sales can see Finance’s cost basis. That’s a FLS mistake.

6. How do you troubleshoot access issues when a user claims they cannot see records they should be able to?

This is the most common admin support request. Start by confirming the user truly doesn’t have access. Have them show you. Next, check their profile and permission sets. Pull up the user record and see what they’re assigned. Check the target object’s OWD setting. If it’s Private, the user needs explicit sharing. Check if they’re in the role hierarchy above the record owner. If the record is owned by someone below them, they should have access. If they’re not, the sharing rules should grant it. Check the applicable sharing rules. Use the record’s “Sharing” button to see exactly who has access to that specific record and why. This directly answers the question. If a user is not listed, trace why. Are they in the target group of a sharing rule? Is the sharing rule active? Are the criteria met? Is the sharing rule type correct (owner-based vs criteria-based)? Are they in the role hierarchy? Once you identify the gap, the fix is usually adding the user to a sharing rule, adding them to a queue, or adjusting their profile permissions. Also consider FLS. If a user says they can’t see a record, they might mean they can see it but not the important fields. Check if FLS is hiding fields. If the record is there but the key fields are hidden, the experience is “I can’t see this record’s info” even though technically the record is visible.

7. Describe login policies and how they enhance security.

Login Policies control where and when users can log in. You can restrict login by IP address, time of day, and device type. If your org is sensitive, you might require logins only during business hours from office IP ranges. This prevents external access. You can also require multi-factor authentication (MFA) for all users or specific profiles. Many enterprises now mandate MFA for compliance. Login policies are assigned per profile. Different profiles can have different login restrictions. The admin profile might allow anytime anywhere while the sales profile allows only during business hours. Login policies add friction but improve security. If you’re a tech-forward team and expect users to be flexible, login policies are minimal. If you’re regulated and need tight control, login policies are part of your security posture.

8. Explain connected apps and OAuth flows. How do you securely enable third-party integrations?

Connected apps allow third-party systems to access Salesforce on behalf of users via OAuth. Instead of users sharing their passwords, OAuth provides a token that grants specific permissions. The flow is: user authorizes the app, Salesforce grants a token, the app uses that token to access the user’s Salesforce data. This is more secure than password-based access because the app never sees the password. As an admin, you create connected apps in Setup. You define what permissions the app needs and users authorize those permissions when they first use the app. You can revoke permissions anytime. Connected apps are powerful for integrations. If you’re building a mobile app that needs Salesforce data, OAuth is the right approach. You create a connected app, embed the OAuth flow in your app, and users authorize. The token grants access. Never embed Salesforce credentials (username/password) in code or apps. Use OAuth instead. For system integrations where you need a service account, you’d use the OAuth Client Credentials flow, which is designed for server-to-server authentication. You create a service account user in Salesforce, create a connected app, and the external system authenticates as that service account. The benefit over static credentials is that tokens expire and rotate, improving security.

AppExchange and Integrations

The Salesforce AppExchange is an ecosystem of third-party solutions. Admins need to evaluate and integrate apps. This section tests your judgment about when to build versus buy and how to safely integrate external code.

1. How do you evaluate an AppExchange package before installing?

Start with reviews. AppExchange packages have user ratings and reviews. If a package has 100 five-star reviews and ten one-star reviews, read the one-star reviews. They often reveal issues. Check the publisher. Is it a known company? Salesforce partners are typically more reliable. Check when it was last updated. A package that hasn’t been updated in five years is risky. Check the installation count. Higher installations suggest it’s vetted. Read the description carefully. What does it do? Does it solve your problem? Check the documentation and support. Is there a knowledge base? Can you contact support? Check if it requires customization. Some apps work out of the box. Some require configuration by a developer. Understand the cost. Is it free, freemium, or paid? If paid, is it per user, per org, or perpetual license? Check dependencies. Does it require Lightning? Does it integrate with a specific tool you also use? Finally, test in a sandbox first. Most packages allow a 30-day trial. Install in a sandbox, test thoroughly, ensure it doesn’t conflict with your existing customizations. Only after sandbox testing should you install in production.

2. What are the different sandbox types and when would you use each?

Developer sandboxes are free, limited to 200MB of storage, and don’t copy production data. They’re good for development and testing configuration. Developer Pro sandboxes cost money but offer more storage and are still for development. Partial Sandboxes copy a subset of production data and configuration. Full Sandboxes copy everything including data. Full Sandboxes are most realistic but take hours to refresh. Most orgs have multiple developer sandboxes for different initiatives and one or two full sandboxes for final testing before production deployment. The cost and refresh time of full sandboxes is why many teams use partial sandboxes for UAT (user acceptance testing). You get real data without copying everything.

3. Describe the basics of REST APIs and when you’d recommend API integration versus point-and-click solutions.

The REST API allows external systems to create, read, update, and delete Salesforce records. An external system can authenticate to Salesforce and make HTTP calls to manipulate data. This is foundational for modern integrations. Point-and-click solutions like Zapier or Flow actions handle common integrations without code. If you need to sync Salesforce Leads to an email service, Zapier might handle that without code. If you need custom business logic or tight data transformation, you need an API or custom middleware. As an admin, you might not build API integrations yourself but you need to understand their existence and recommend them to developers when needed. You also need to understand authentication. Salesforce APIs use OAuth. A third party gets a token and makes API calls. The token permissions are scoped based on the connected app. You control what external systems can access via the connected app definition.

4. What are common integration patterns and when would you recommend each?

Real-time synchronization syncs data immediately when records change. If an Opportunity updates in Salesforce, the ERP system updates immediately. This is complex but provides up-to-date data everywhere. Batch synchronization syncs in batches at scheduled times. Every night at 2 AM, pull new records from the ERP and load into Salesforce. Batch is simpler but data is delayed. Event-driven integration triggers on specific events. When a record reaches a certain status, trigger an integration. This is responsive without syncing everything. Webhook integrations use webhooks where external systems post data to Salesforce when something happens. Choose real-time when you need data constantly in sync. Choose batch when daily sync is acceptable and you want to reduce API load. Choose event-driven when you want to respond to specific conditions. Choose webhooks for external systems pushing data to Salesforce.

5. How do you monitor and secure integrations to prevent data breaches and system disruption?

Create a registry of all integrations pointing to Salesforce. Know what’s connected and why. Regularly audit the list. If an integration hasn’t been used in six months, consider deactivating it. Use OAuth with proper scopes. An external system should request the minimum permissions it needs. Rotate tokens periodically. Don’t use permanent credentials. Use connected apps with token expiration. Monitor API usage via Salesforce logs. If an integration starts making unusual API calls, you want to detect it. Set rate limits. If an external system suddenly starts making thousands of API calls per minute, limit the rate to prevent disruption. Test integrations thoroughly in sandbox before production. Ensure they fail gracefully. If the external system is down, the integration shouldn’t break Salesforce. Finally, document integrations. Who owns each integration? What data does it access? How does it communicate? Good documentation enables quick response if something goes wrong.

Behavioral STAR Questions

Technical knowledge is necessary but not sufficient. Behavioral questions reveal how you handle real-world situations: ambiguous requirements, difficult stakeholders, and competing priorities.

1. Tell us about the largest Salesforce project you’ve managed. What was the scope and what challenges did you face?

Use the STAR method: Situation, Task, Action, Result. Describe the business context and scale. Was it an implementation from scratch or a major migration? What were the timeline and team size? What was the budget? Describe the challenges you faced. Was the business unclear on requirements? Were there multiple stakeholders with conflicting needs? Did you hit performance issues? Describe your actions. Did you align stakeholders? Did you break the project into phases? Did you adjust the timeline? Describe the result. Did you deliver on time and budget? Did you exceed expectations? What feedback did you get from the business? The answer reveals your judgment under pressure, your communication skills, and your ability to manage complex work.

2. Describe a situation where users resisted a Salesforce change you implemented. How did you handle it?

Resistance is common. Users are comfortable with the old way. Change is disruptive. Describe the change and why it was necessary. Maybe the old reporting approach was slow and you migrated to dashboards. Describe the resistance. Did users not understand the benefit? Did they find it harder to use? Describe your actions. Did you train them? Did you adjust the solution based on feedback? Did you loop in user champions? Did you create guides or videos? Describe the result. Did adoption improve? Did the new solution deliver the promised benefit? This answer reveals your empathy for users, your ability to communicate technical change, and your resilience in the face of pushback.

3. Walk us through a complex Salesforce problem you debugged. What was your approach?

Choose a real problem where your diagnosis skills made a difference. Maybe users couldn’t see records they should, or a Flow was failing silently. Describe the symptom. What was the user complaint? Describe your diagnostic approach. Did you check logs? Did you run queries? Did you use the Sharing button? Did you check FLS? Describe the root cause. Was it a misconfigured sharing rule? Was it a formula field error? Describe your fix. Describe the result. Was the user satisfied? Did you prevent recurrence? This answer reveals your troubleshooting skills, your methodical approach, and your ability to think through complex systems.

4. Tell us about a time when you had to manage competing requests from multiple stakeholders with limited resources. How did you prioritize?

Every admin faces this. Sales wants new reports. Finance wants data validation. Support wants automation. Resources are finite. Describe the requests. Describe the constraint. Were you the only admin? Did you have a limited developer budget? Describe your prioritization approach. Did you align with leadership on business impact? Did you group similar requests to be more efficient? Did you defer nice-to-have requests? Did you propose phased approach? Describe the result. Were stakeholders satisfied? Did you deliver the high-impact items first? This answer reveals your judgment about what matters, your communication with leadership, and your ability to say no tactfully.

5. Describe your approach to communicating technical information to non-technical stakeholders.

Admins bridge business and technology. You need to explain technical concepts simply. Describe an example. Maybe you explained why data quality matters to the Finance team. Maybe you explained a sharing rule to a Sales Director. Describe your approach. Did you use analogies? Did you avoid jargon? Did you show examples? Did you let them ask questions? Describe the result. Did they understand? Did they get bought in? This answer reveals your communication skills and your ability to bridge the business-tech gap.

6. Tell us about a stakeholder you found difficult and how you built a relationship with them.

Choose a situation where you overcame a real challenge. Maybe someone was skeptical of Salesforce. Maybe they were demanding. Describe the situation and what made it challenging. Describe your approach. Did you listen to their concerns? Did you show them how Salesforce addressed their pain points? Did you involve them in solutions? Describe the result. Did they become a champion? Did they support your recommendations? This answer reveals your emotional intelligence and your ability to influence across the org.

Questions to Ask in the Interview

Interviewers expect you to ask questions. This shows you’re genuinely interested and thinking strategically. Good questions reveal what you value and how you approach the role.

What does success look like in the first 90 days? This reveals expectations and lets you assess whether you can meet them.

What is the current state of the Salesforce org? How mature is it? Are there known issues or debt? This lets you understand the challenge and the starting point.

How is the admin function structured? Are there other admins? Is there a developer? Who do you report to? This reveals the team and your support structure.

What is the organization’s approach to data governance and data quality? Do they have processes and ownership? This reveals how organized and mature they are.

What is the biggest pain point users experience with Salesforce today? What is the team trying to solve? This reveals the priorities and the real problems you’ll address.

How does the organization approach change management? Are there established processes for releasing changes? This reveals whether the org is disciplined or chaotic.

What is the budget for tools and third-party apps? Are there constraints? This lets you understand what you’ll have to work with.

What is your learning philosophy? Do you support certifications? Do you send admins to events? This reveals whether the org values professional development.

Certification Preparation

The Salesforce Administrator Certification (501) is a standard credential. It covers all the topics in this guide and more. Studying for the exam forces you to fill knowledge gaps. The exam is 60 questions, 90 minutes, and 65 percent is passing. Most admins can pass with 4-6 weeks of focused study. Use Trailhead, the official Salesforce learning platform, for guided learning. Review the exam guide which lists all topics covered. Take practice exams. Salesforce provides a practice exam. Take it multiple times to identify weak areas. Study those topics harder. Join an admin study group. Learning with others keeps you accountable. Read the official Salesforce admin guide. It’s comprehensive. Understand the exam weight. Some topics like sharing and security are heavily tested. Master those. On exam day, read questions carefully. Salesforce exams have nuance. A question might ask “which is the best practice” and there are multiple correct answers technically but one is “best.” Time management matters. Don’t spend 10 minutes on one question. Skip hard questions and come back. The exam is a good goal and a good motivator for learning the platform deeply.