Salesforce Interview Questions: Sharing Rules, Apex Sharing Context, and Skinny Tables

In plain words: Salesforce technical interviews frequently test the core boundaries of the platform: how record-level security opens up access beyond Organization-Wide Defaults (OWD), how Apex sharing keywords behave when classes call one another, and how database-level skinny tables improve query performance for large data volumes.

Technical interviews for Salesforce Developer and Architect positions consistently probe your understanding of data security, programmatic execution contexts, and underlying database architecture. Below are three classic, high-frequency interview questions broken down with detailed technical explanations and best practices.

Question 1: Selectively Sharing Records Between Same-Role Users

Scenario:

Two users—User A and User B—share the exact same Profile (Profile A) and Role (Role A). The Organization-Wide Default (OWD) for the Opportunity object is set to Private. The business requirement states that User A must have full Read/Write access to all Opportunity records owned by User B, without granting User B reciprocal access to User A's opportunities. How do you implement this?

Step-by-Step Configuration Solution:

• Step 1 (Public Group): Create a Public Group (e.g., User_A_Group) and add User A as its sole member.
• Step 2 (Owner-Based Sharing Rule): Create an Owner-Based Sharing Rule on the Opportunity object.
  • Records to be shared: Owned by members of a Public Group containing only User B (or create a dedicated group for User B).
  • Share with: User_A_Group.
  • Access Level: Read/Write.
• Alternative Approach (Manual / Apex Sharing): If the requirement is dynamic or temporary, you can use Manual Sharing or programmatic Apex Managed Sharing (OpportunityShare records with RowCause = 'Manual' or a custom Apex Sharing Reason).

Warning Trap: Because both users share the same role, an owner-based sharing rule targeting "Role: Role A" would grant access bi-directionally or share all role records. To restrict access unidirectionally from User B to User A, always isolate the target user inside a dedicated Public Group.

Question 2: Apex "with sharing" vs. "without sharing" Execution Context

Scenario:

We have an Apex class declared with the with sharing keyword containing a method named method1(). An external caller invokes method1() from a class defined as without sharing. What sharing rules are enforced when method1() executes?

// Class A - Runs without enforcing sharing rules
public without sharing class ClassA {
    public void executeLogic() {
        ClassB b = new ClassB();
        b.method1(); // What context applies inside method1?
    }
}

// Class B - Explicitly enforces sharing rules
public with sharing class ClassB {
    public void method1() {
        // SOQL queries executed here ENFORCE the current user's sharing rules
        List<Opportunity> opps = [SELECT Id, Name FROM Opportunity];
    }
}

Answer: Sharing rules will be enforced inside method1(). In Apex, when a class explicitly declares with sharing, any queries or DML statements executed inside its methods strictly respect the current user's record-level sharing permissions, regardless of whether the calling class was declared as without sharing.

Warning Trap — The "inherited sharing" Distinction: If ClassB were omitted of keywords or declared as inherited sharing, it would adopt the caller's context (without sharing). Declaring with sharing guarantees strict enforcement at the callee level. Remember that sharing keywords only control record-level access, not Field-Level Security (FLS) or Object-Level Permissions (CRUD)—use WITH USER_MODE in SOQL to enforce CRUD and FLS.

Question 3: What is a Skinny Table in Salesforce?

Question:

What is a Skinny Table in Salesforce, why is it used, and how is it created?

Answer:

In the standard Salesforce multi-tenant database architecture, standard fields and custom fields for an object are stored in two separate database tables. When a SOQL query requests both standard and custom fields, Salesforce must perform an underlying database join between these tables, which can impact performance on large data volumes (LDV).

A Skinny Table is a custom, read-only table maintained by Salesforce that combines frequently used standard and custom fields into a single flat table, eliminating table joins to deliver significantly faster query and report execution.

360 Skinny Table Architecture Summary:

• Creation: Cannot be created manually by administrators. You must log a case with Salesforce Customer Support to enable and configure a skinny table for specific objects.
• Live Synchronization: Salesforce automatically synchronizes data between the main tables and the skinny table in real time—no batch rebuilds required.
• Supported Objects: Available for Account, Contact, Opportunity, Lead, Case, and Custom Objects.
• Key Limitation: Skinny tables do not include soft-deleted records (records in the Recycle Bin). Queries with ALL ROWS bypass the skinny table and query the underlying base tables directly.

Core Takeaway: Mastering record sharing exceptions via Public Groups, understanding callee-level Apex sharing enforcement, and leveraging skinny tables for large data volumes demonstrate strong end-to-end platform architecture expertise.