Advanced Administrator Interview Questions

Shield Platform Encryption encrypts data at rest using AES-256 encryption, protecting data even from Salesforce employees with infrastructure access. It uses a tenant secret combined with a master secret (held by Salesforce) to derive an org-specific data encryption key. BYOK (Bring Your Own Key) allows the customer to supply the tenant secret, giving them key control. Limitations: encrypted fields cannot be used in certain filter conditions, SOQL WHERE clauses, duplicate rules, or formula fields. Classic Encryption is an older feature that only masks field values on screen — it does not encrypt data at the database level and has far weaker security guarantees. Shield also supports Cache-Only Keys for highest security (keys never persist in Salesforce infrastructure).

Standard Field History Tracking retains up to 18 months of field change history (who changed what, when, and the old/new value) in the FieldHistory related list. It is limited to 20 fields per object. Field Audit Trail (a Shield feature) extends retention up to 10 years and supports up to 60 fields per object. It stores data in a separate BigObjects infrastructure (FieldHistoryArchive), enabling long-term compliance with regulations like GDPR or HIPAA audit requirements. Field Audit Trail also captures changes from API integrations and automated processes. Data can be queried via SOQL against the FieldHistoryArchive object but with certain restrictions on filtering.

Transaction Security (part of Salesforce Shield) monitors real-time events in the org and takes automated actions when specified conditions are met. Components: (1) Event: What to monitor — API query events, data export, login events, entity changes (CUD on specific objects). (2) Condition: The filter criteria (e.g., "a user queries more than 2000 records in one transaction"). (3) Actions: Block the action and/or notify the admin/user. Policies are defined using either a point-and-click interface or Apex Policy classes (for complex logic). Common use cases: blocking bulk exports of sensitive data, detecting logins from unusual locations, enforcing MFA for specific operations.

Invocable Actions: Apex methods annotated with @InvocableMethod that can be called from Flows. They extend Flow capabilities beyond declarative limits (e.g., calling external APIs, complex calculations). Subflows: Allow one Flow to call another as a reusable module, passing variables in and out. This promotes reusability and maintainability. Fault Paths: In Flow, actions and DML operations can fail at runtime. Fault connectors route execution to a fault path where you can log the error, send a notification, or display a user-friendly message. Without a fault path, an unhandled error terminates the flow and shows a generic error. Debugging: Use the Flow Debug tool in Flow Builder or enable debug logs (Automated Flow Process user) to trace flow execution.

Apex Managed Sharing is used when sharing requirements are too complex for declarative sharing rules. Each custom object has a corresponding Share object (e.g., MyObject__Share). An Apex class (typically a trigger or batch job) creates records in this Share object to grant specific users or groups access to specific records. Key fields on the Share object: ParentId (the record being shared), UserOrGroupId (who receives access), AccessLevel (Read or Edit), RowCause (must be a custom sharing reason created in Setup — this differentiates Apex Managed Sharing from manual sharing and prevents deletion during sharing recalculation). Apex Managed Sharing rows with custom row causes persist through sharing recalculations.

Change Sets: Manual, point-and-click metadata migration between connected orgs. No version control, no CI/CD integration, cannot delete metadata, limited metadata type support. Good for simple, infrequent deployments. Unlocked Packages: Part of Salesforce DX and second-generation packaging (2GP). Metadata is version-controlled in source code. Packages are versioned artifacts installed independently in any org. Supports deletion of metadata, dependency management, and CI/CD pipelines. Packages can be updated incrementally. Unlocked Packages are the modern standard for scalable, team-based development. They offer traceability (you know exactly what version is installed in each org) and repeatability that change sets cannot provide.

When refreshing a Partial Copy sandbox, a Sandbox Template defines which objects and how many records (percentage or number) are copied from production. This allows you to control data volume and what data is included, for example including all Accounts but only 10% of Cases. Configuration: Setup > Sandboxes > select template before refresh. For Full sandboxes, all data is copied — templates do not apply. Developer and Developer Pro sandboxes copy metadata only (no template needed). Key considerations: always anonymise/mask sensitive PII in test environments using a data masking tool or pre-refresh automation. Sandbox refresh intervals: Developer/Developer Pro = 1 day, Partial = 5 days, Full = 29 days.

Salesforce Connect allows Salesforce to display and query data from external systems in real time without copying it into Salesforce. Data appears as External Objects (suffixed with __x). Supported adapter types: (1) OData 2.0 / 4.0: Connect to any OData-compliant REST API (SAP, SharePoint, etc.). (2) Cross-Org Adapter: Access data from another Salesforce org via the Salesforce REST API. (3) Custom Adapter (Apex): Build a custom data source connector using Apex DataSource classes. External Objects support relationships (External Lookup, Indirect Lookup) to standard/custom objects and SOQL queries, but with limitations — they do not support triggers, roll-up summaries, or all SOQL operators.

Joined Reports: A report type that combines up to five report blocks (each can be a different object or have different filters) side by side in one view. Common block grouping fields allow cross-block sorting and comparison. Useful for showing "Open Opportunities vs Closed Opportunities vs Cases" for an Account in one report. Historical Trending Reports: Available for Opportunities, Cases, Forecasts, and custom objects. They allow you to report on how field values changed over time by comparing snapshots (up to 3 historical date comparisons). For example: "What was the Opportunity close date and amount 30 days ago vs today?" Requires enabling Historical Trending in Setup and selecting up to 8 fields per object to track historically.

Custom Summary Formulas (CSFs) are formula-based calculated columns/rows added to Summary and Matrix reports. They operate on summary (aggregate) values rather than record-level values. Use cases: calculating gross margin percentage (Sum of Profit / Sum of Revenue), showing conversion rate (Closed Won Count / Total Opportunities Count). CSFs use functions like RowCount, SUM(), PARENTGROUPVAL() (reference a parent group's aggregate), and PREVGROUPVAL() (reference the previous group's aggregate). PARENTGROUPVAL is especially powerful — it allows percentages relative to a parent row total. CSFs only display when groupings are present (Summary or Matrix reports) and cannot be used in Tabular or Joined reports as filters.

Standard Report Types: Pre-built by Salesforce for standard objects and common relationships (e.g., Accounts with Contacts, Opportunities with Products). You cannot modify which objects or relationships they include. Custom Report Types (CRT): Created by admins to define which primary object, related objects (up to 4 levels), and fields are available in the report builder. You control whether related records must exist ("A must have B") or may exist ("A may or may not have B") — affecting how records are filtered. CRTs also allow adding fields from multiple related objects in one report layout, and pre-defining which fields appear by default. CRTs are the only way to report on certain relationships or include fields not available in standard report types.

ISNEW(): Returns true only when a record is being created (not on updates). Used to enforce required fields only on creation. ISCHANGED(field): Returns true if the field value changed from its previous value. Useful for preventing edits to locked fields after a certain stage. PRIORVALUE(field): Returns the field's value before the current edit. Used to compare before/after values in rules. ISPICKVAL(field, "value"): Returns true if a picklist field equals the specified value. Combined example: AND(ISCHANGED(StageName__c), ISPICKVAL(PRIORVALUE(StageName), "Closed Won")) — prevents re-opening a closed opportunity. These functions are only valid in validation rules and formula fields, not in custom formula fields that reference them outside that context.

Permission Set Groups: Bundle multiple related permission sets into a single assignable group. Instead of assigning 10 individual permission sets to a user, assign one group. Changes to the group automatically apply to all assigned users. Useful for role-based access bundles (e.g., "Sales Rep Access" group containing CRM, CPQ, and Email permissions). Muting Permission Sets: A special type of permission set added to a group to selectively remove specific permissions that would otherwise be granted by member permission sets. For example, a group grants "Delete Accounts" permission from one set, but a muting permission set removes that specific permission. Muting permission sets can only remove permissions — they cannot grant new ones. This enables fine-grained group customisation without creating entirely new permission sets.

Advanced Chatter features include: (1) Chatter Groups: Public, private, or unlisted groups for collaboration. Admins can archive inactive groups and manage membership. (2) Publisher Actions: Custom actions added to the Chatter publisher bar — Create Record, Log a Call, or custom Lightning actions. Global actions appear everywhere; object-specific actions appear on record pages. (3) Feed Tracking: Configure which objects and fields generate Chatter feed posts when changed. Admins control this per object under Setup > Feed Tracking. (4) Chatter Email Digest: Configure frequency of email notifications. (5) Moderation: Flag/remove posts, set rules for auto-flagging keywords. (6) External Users in Chatter via Experience Cloud.

Advanced mobile customisation includes: (1) Navigation Menu: Customise which items appear (objects, apps, utilities, Visualforce pages, Lightning components) under Setup > Salesforce Mobile App Navigation. (2) Compact Layouts: Define the 4–5 most important fields shown in the record header card and highlight panel on mobile. Assigned via record types. (3) Mobile Quick Actions: Custom quick actions (Create, Update, Log a Call, custom Flow) added to the action bar. Actions can be pre-filled with default field values. (4) Mobile-Only Page Layouts: In Lightning App Builder, create phone-specific record pages with only the most relevant components. (5) Offline access: Enable briefcase for offline record access in field service scenarios.

Complex Duplicate Rules combine multiple Matching Rules with different algorithms: (1) Exact Match: Records must have identical values (case-insensitive). Good for email addresses, phone numbers. (2) Fuzzy Match: Uses phonetic algorithms (First Name fuzzy, Last Name fuzzy) to catch "John Smith" vs "Jon Smyth". Good for name-based matching. (3) Acronym: Matches abbreviated vs full company names. (4) Initials: Matches "J. Smith" to "John Smith". Matching rules use a match key (a transformed value) — two records are potential duplicates if their match keys are equal or meet the fuzzy threshold. Duplicate rules can apply different actions for leads vs contacts, block on insert but allow on edit, or only report duplicates without blocking.

Territory Management (Enterprise Territory Management - ETM) organises accounts and users into a flexible, hierarchical territory structure for sales assignment and forecasting. Key components: (1) Territory Types: Categorise territories (e.g., Geographic, Named Account). (2) Territory Model: A hierarchical tree of territories. Only one model can be active at a time. (3) Territory Rules: Filter-based assignment rules that automatically assign Accounts to territories based on field values (industry, region, revenue). (4) User Assignment: Users (salespeople) are assigned to territories. An Account can belong to multiple territories; a user can belong to multiple territories. (5) Forecasts: Territory-based forecasting rolls up from lower territories to higher ones in the hierarchy.

Collaborative Forecasting provides a structured view of expected sales revenue, aggregated up the role or territory hierarchy. Forecast Types: Define what data is rolled up (Revenue vs Quantity, by Opportunity product family, Schedule dates). Multiple forecast types can be enabled simultaneously. Forecast Categories: Opportunities are categorised (Pipeline, Best Case, Commit, Closed) based on their stage, and each category rolls up separately. Adjustments: Managers can adjust their own forecast or their subordinates' forecasts upward or downward, with the original number preserved. Adjustment history is tracked. Manager Judgement: Managers can add judgement on top of the system-calculated rollup. Forecasting integrates with territory management, quotas, and Einstein forecasting for AI predictions.

Einstein Activity Capture (EAC) automatically syncs emails and calendar events between Salesforce and connected email/calendar systems (Gmail, Outlook) and logs them as activities on related records. Key considerations: (1) Data Sharing: By default, captured activities are visible only to the owner and admins — configure sharing settings to control visibility. (2) Activity Matching: EAC matches emails/events to Contacts, Leads, Accounts, and Opportunities based on email address. (3) Excluded Addresses: Configure internal domain email addresses to exclude from capture. (4) Data Retention: EAC-synced activities are stored in a separate data store (not Salesforce standard Activities) — they do not appear in standard reports without Einstein Analytics. (5) Licence requirement: Requires Sales Cloud Einstein or Inbox licences.

MFA enforcement options: (1) Auto-Enable MFA: Salesforce has auto-enabled MFA for all production orgs as of 2023. This requires all users to register a verification method (Salesforce Authenticator app, TOTP authenticator, security keys, or built-in authenticators). (2) Profile-level enforcement: Enable the "Multi-Factor Authentication for User Interface Logins" permission in a profile or permission set for selective enforcement. (3) SSO: If using SSO, MFA should be enforced at the identity provider level — Salesforce's MFA requirement then delegates to the IdP. (4) High-Assurance Sessions: Require MFA re-verification for specific sensitive actions (custom permissions, login flows). Admins can monitor MFA adoption via identity verification history reports.

Enhanced Domains is Salesforce's updated URL format that includes the My Domain name in all Salesforce URLs (Experience Cloud sites, Visualforce pages, content files). Format: orgname.sandbox.my.salesforce.com instead of the older c.na1.visual.force.com. Benefits: (1) Improves security by ensuring all content is served from the org's domain, blocking cross-org cookie access. (2) Enables stricter browser security policies. (3) Required for Salesforce to meet evolving browser security standards. (4) Simplifies CSP (Content Security Policy) configuration. Enhanced Domains became mandatory as of Spring '23. Admins must update any hardcoded URLs in integrations, email templates, or external systems that reference old domain formats after enabling Enhanced Domains.

The Health Check tool (Setup > Health Check) gives an org a security score (0–100) by comparing security settings against Salesforce's Baseline Standard or a custom security baseline. It evaluates: password policies (complexity, expiry, history), session settings (timeout duration, HTTPS enforcement, clickjack protection), login access policies, My Domain settings, and remote site settings. Each setting is rated as Meeting Standard, Failing, or a Risk Level. To improve the score: (1) Increase minimum password length and complexity requirements. (2) Reduce session timeout to shorter periods. (3) Enable HTTPS for Visualforce pages. (4) Enable clickjack protection. (5) Review and restrict remote site settings. (6) Enable certificate-based authentication where applicable. Health Check does not capture all security risks — use it alongside Shield and regular security reviews.

Password policies (Setup > Password Policies) control: (1) Minimum password length: Salesforce recommends at least 12 characters. (2) Complexity requirements: Must include uppercase, lowercase, numbers, and special characters. (3) Password expiry: Force password reset after 30/60/90 days or never. (4) Password history: Prevent reuse of last N passwords (up to 24). (5) Maximum invalid login attempts: Lock the account after N failed attempts. (6) Lockout period: Duration before the account automatically unlocks. (7) Obscure secret answer: Mask the security question answer. Best practices: longer passwords with complexity, 90-day expiry, lock after 3–5 attempts, enforce MFA alongside password policy. Password policies are set at the org level but can be overridden per profile.

The Salesforce Recycle Bin stores deleted records for 15 days before permanent deletion. Records can be restored individually or in bulk, or permanently deleted by an admin. Capacity: 25 times the org's MB of storage (minimum 5,000 records). Limitations: (1) Child records in a master-detail relationship are cascade-deleted with the master — they appear in the Recycle Bin too and must be restored together. (2) Lookup relationship children are not cascade-deleted. (3) After 15 days, records are permanently deleted and unrecoverable (unless using a data backup solution). (4) The Recycle Bin is per-org, not per-user — admins see all deleted records. (5) Hard Delete (via Data Loader) bypasses the Recycle Bin entirely. Salesforce offers a Data Recovery Service as a paid option for data deleted beyond the 15-day window.

Session settings (Setup > Session Settings) control how user sessions behave. Key security settings: (1) Session Timeout: Time of inactivity before automatic logout (15 min to 24 hours — shorter is more secure). (2) Lock sessions to the IP address: Prevents session hijacking by binding the session to the originating IP. (3) Lock sessions to the domain: Prevents cross-domain session reuse. (4) Force re-login after Login-As-User: Requires admins to re-authenticate after using Login-As. (5) Require secure connections (HTTPS): Ensures all traffic is encrypted. (6) Clickjack Protection: Prevents Salesforce pages from being embedded in iframes on external sites. (7) Enable HSTS: HTTP Strict Transport Security header to force HTTPS. Most of these settings contribute to the Health Check score.