Q1: What is the difference between a Role and a Profile in Salesforce?

Why they ask: This is the most fundamental security question. Getting this wrong signals you do not understand the Salesforce security model, which is the foundation of every implementation.

Profile: Controls object-level and field-level permissions — what a user can do. CRUD (Create, Read, Update, Delete) access on objects, field-level security (which fields a user can see/edit), page layout assignments, and app access. Every user must have exactly one profile.

Role: Controls record-level access through the role hierarchy — which records a user can see. A manager in the hierarchy can see all records owned by users below them. Roles are optional — not every user needs one.

The key distinction: Profile answers “what can you do?” Role answers “what can you see?” A sales rep and a marketing manager might have the same profile (same CRUD permissions) but different roles (different record visibility based on their position in the hierarchy).

Q2: Explain the different types of relationships in Salesforce

Why they ask: Data modeling is core to every Salesforce implementation. Understanding relationships determines how you structure data, roll up summaries, and control access.

Lookup Relationship: A loose relationship between two objects. The child record can exist without a parent. Deleting the parent does not delete children. No roll-up summary fields. Each object maintains its own sharing settings independently.

Master-Detail Relationship: A tight relationship. The child cannot exist without a parent. Deleting the parent cascades to children. Roll-up summary fields are available on the master. The child inherits the parent's sharing settings (OWD of child is controlled by parent).

Many-to-Many: Implemented using a junction object with two master-detail relationships. Example: a Student can enroll in many Courses, and a Course can have many Students. The Enrollment object is the junction with master-detail to both Student and Course.

Q3: What are Validation Rules and when would you use them?

Why they ask: Validation rules are the first line of data quality defense. This tests whether you can translate business requirements into declarative logic.

What they are: Formula-based rules that prevent users from saving a record if the data does not meet specified criteria. They run before the record is saved and display an error message if the condition evaluates to TRUE.

/* Example: Ensure phone number is 10 digits */
AND(
  NOT(ISBLANK(Phone)),
  NOT(REGEX(Phone, "^[0-9]{10}$"))
)
/* Error message: "Phone number must be exactly 10 digits" */

/* Example: Prevent closing a case without resolution notes */
AND(
  ISPICKVAL(Status, "Closed"),
  ISBLANK(Resolution_Notes__c)
)
/* Error message: "Resolution notes are required when closing a case" */

When to use: Data quality enforcement, business rule compliance, preventing invalid state transitions. Validation rules are declarative (no code) and should always be preferred over Apex triggers for simple data validation.

Q1: What are Governor Limits and why do they exist?

Why they ask: Governor limits are the single most important concept in Salesforce development. Every line of Apex you write must respect these limits. Not understanding them means your code will fail in production.

Why they exist: Salesforce is a multi-tenant platform — thousands of organizations share the same infrastructure. Governor limits prevent any single org from consuming too many shared resources (CPU, memory, database queries). Without limits, one bad trigger could slow down every customer on the same server.

// Key Governor Limits (per transaction):
// SOQL queries:        100 (synchronous) / 200 (asynchronous)
// DML statements:      150
// CPU time:            10,000 ms (sync) / 60,000 ms (async)
// Heap size:           6 MB (sync) / 12 MB (async)
// Callouts:            100

// BAD: SOQL inside a loop (will hit 100 query limit)
for (Account acc : accounts) {
    List<Contact> contacts = [SELECT Id FROM Contact WHERE AccountId = :acc.Id];
}

// GOOD: Bulkified — single query outside the loop
Map<Id, List<Contact>> contactsByAccount = new Map<Id, List<Contact>>();
for (Contact c : [SELECT Id, AccountId FROM Contact WHERE AccountId IN :accountIds]) {
    if (!contactsByAccount.containsKey(c.AccountId)) {
        contactsByAccount.put(c.AccountId, new List<Contact>());
    }
    contactsByAccount.get(c.AccountId).add(c);
}

Q2: Explain the difference between a Trigger and a Flow

Why they ask: Salesforce strongly promotes declarative development (Flows) over programmatic development (Triggers). Knowing when to use each — and the order of execution — is critical.

Flow (Declarative): Point-and-click automation. No code required. Easier to maintain, can be built by admins. Use for: field updates, record creation, email alerts, approval processes, and most business logic. Salesforce recommends Flows as the default choice.

Trigger (Programmatic): Apex code that executes before or after DML operations. Use when: you need complex logic that Flows cannot handle, you need to interact with external systems synchronously, or you need fine-grained control over the order of execution.

Order of execution: Before triggers → validation rules → after triggers → assignment rules → auto-response rules → workflow rules → record-triggered flows → escalation rules. Understanding this order is essential for debugging unexpected behavior.

Q3: Write an Apex trigger that prevents duplicate contacts based on email

Why they ask: This tests bulkification, trigger context variables, and practical Apex coding skills. Most candidates write a non-bulkified version that fails with data loads.

trigger PreventDuplicateContacts on Contact (before insert, before update) {
    // Step 1: Collect all emails from incoming records
    Set<String> newEmails = new Set<String>();
    for (Contact c : Trigger.new) {
        if (c.Email != null) {
            newEmails.add(c.Email.toLowerCase());
        }
    }

    // Step 2: Query existing contacts with those emails (single query)
    Set<String> existingEmails = new Set<String>();
    for (Contact existing : [
        SELECT Email FROM Contact
        WHERE Email IN :newEmails
        AND Id NOT IN :Trigger.new
    ]) {
        existingEmails.add(existing.Email.toLowerCase());
    }

    // Step 3: Add error to duplicate records
    for (Contact c : Trigger.new) {
        if (c.Email != null && existingEmails.contains(c.Email.toLowerCase())) {
            c.Email.addError('A contact with this email already exists.');
        }
    }
}

Key points: The trigger is bulkified (handles 200+ records), uses a single SOQL query (respects governor limits), handles both insert and update contexts, and uses addError() on the specific field for a clean user experience.

Q1: What are the different ways to integrate Salesforce with external systems?

Why they ask: Integration is where Salesforce meets the real world. Every enterprise has multiple systems that need to talk to each other. This tests whether you understand the full spectrum of integration options.

REST API: The most common integration method. Supports JSON, works with any language. Use for: real-time data sync, mobile apps, custom web applications. Limits: 100,000 API calls per 24 hours (Enterprise Edition).

SOAP API: XML-based, strongly typed. Use for: enterprise integrations that require WSDL contracts, legacy systems that only support SOAP. More verbose than REST but provides better type safety.

Platform Events: Event-driven architecture. Publish events from Salesforce, subscribe from external systems (or vice versa). Use for: real-time notifications, decoupled integrations, event sourcing patterns.

Outbound Messages: Declarative (no code). Sends a SOAP message to an external endpoint when a workflow rule fires. Simple but limited — only supports SOAP and specific fields.

Middleware (MuleSoft): For complex, multi-system integrations. MuleSoft (owned by Salesforce) provides pre-built connectors, data transformation, and orchestration. Use when: you have 5+ systems to integrate, need complex data mapping, or require guaranteed delivery.

Q2: What is a Connected App and when do you use OAuth?

Why they ask: Authentication is the first step in any integration. Getting this wrong means security vulnerabilities or broken integrations.

Connected App: A framework that enables an external application to integrate with Salesforce using APIs and standard protocols (OAuth 2.0, SAML). You create a Connected App in Salesforce Setup, which gives you a Consumer Key and Consumer Secret — the credentials your external app uses to authenticate.

OAuth 2.0 Flows: Web Server Flow (authorization code) for web apps where a user logs in. JWT Bearer Flow for server-to-server integrations (no user interaction). Device Flow for IoT devices. Username-Password Flow for testing only (never in production — credentials are sent in plain text).

When to use OAuth: Always. Every API integration with Salesforce should use OAuth. Session IDs and hardcoded credentials are security risks. OAuth provides token-based access with scopes, refresh tokens, and revocation capabilities.

Q1: A sales team wants to automatically assign leads based on geography. How would you implement this?

Why they ask: This tests whether you know the declarative tools available and can design a solution without writing code.

Solution approach:

Lead Assignment Rules: The primary tool. Create assignment rules with criteria based on State/Country fields. Each rule entry specifies criteria (e.g., State = “Maharashtra”) and assigns to a user or queue. Rules are evaluated in order — first match wins.

Territory Management: For more complex scenarios. Define territories based on geography, industry, or revenue. Assign users to territories. Leads and accounts are automatically assigned based on territory rules. Better for large sales teams with overlapping coverage.

The answer the interviewer wants: Start with Lead Assignment Rules (simplest declarative solution). Mention Territory Management if the scenario is complex. Only suggest Apex if the business logic cannot be expressed declaratively. Always explain why you chose the approach — “I would use Assignment Rules because they are declarative, maintainable by admins, and sufficient for geography-based routing.”

Q2: The CEO wants a dashboard showing pipeline by stage, region, and rep. How do you build it?

Why they ask: This tests your knowledge of Salesforce reporting and analytics — a core admin skill that directly impacts business decisions.

Step 1 — Report Types: Use the standard “Opportunities” report type. If you need data from related objects (e.g., Account region), use “Opportunities with Account” report type or create a custom report type.

Step 2 — Reports: Create three source reports: Pipeline by Stage (grouped by Stage, summing Amount), Pipeline by Region (grouped by Account Region), Pipeline by Rep (grouped by Opportunity Owner). Add filters for current fiscal quarter and open opportunities only.

Step 3 — Dashboard: Create a dashboard with components: a funnel chart for pipeline by stage, a bar chart for pipeline by region, a table for pipeline by rep with Amount and Count columns. Add a date filter component so the CEO can change the time period.

Step 4 — Scheduled Refresh: Schedule the dashboard to refresh daily at 7 AM and email to the CEO. Set the “Running User” to someone with visibility into all opportunities (or use dynamic dashboards if available in the edition).