Salesforce Administrator Interview Questions

Setting up a new Salesforce org involves: (1) Configuring Company Information (fiscal year, currency, address). (2) Defining the org's data model — creating custom objects, fields, and relationships. (3) Configuring security: creating profiles, roles, permission sets, and OWD settings. (4) Setting up users and assigning profiles/roles. (5) Configuring automation (Flows, approval processes). (6) Building reports, dashboards, and list views. (7) Customising page layouts and record types. (8) Enabling and configuring features (Chatter, Email-to-Case, etc.). (9) Performing data migration using Data Import Wizard or Data Loader. (10) Testing in a sandbox before go-live.

Effective user management includes: (1) Creating user accounts with appropriate profiles and roles. (2) Using permission sets and permission set groups to extend access without changing profiles. (3) Configuring login hours and IP ranges per profile for security. (4) Freezing users (disabling login without deleting) when employees leave. (5) Monitoring login history and user activity via Setup > Login History. (6) Reassigning records from deactivated users using mass transfer or flows. (7) Using public groups and queues for record assignment and list view sharing. Salesforce recommends the principle of least privilege — start with the most restrictive access and open up as needed.

A Profile is the primary security baseline assigned to every user (one per user). It controls object permissions, field-level security, app visibility, login hours, and IP ranges. A Permission Set extends a user's access beyond their profile without changing it — a user can hold multiple permission sets. Permission Set Groups bundle related permission sets together. Salesforce's long-term direction is to shift all permissions away from profiles and into permission sets, making profiles contain only a minimum baseline.

OWD (Organisation-Wide Defaults) sets the baseline record-access level for all users on an object. Settings: (1) Private: Only the record owner and users above them in the role hierarchy can view/edit. (2) Public Read Only: All users can view but only the owner (and hierarchy) can edit. (3) Public Read/Write: All users can view and edit. (4) Controlled by Parent: The detail record inherits access from its master (used in master-detail relationships). OWD only restricts access — you then open up access using sharing rules, role hierarchy, or manual sharing. You cannot restrict below OWD using sharing.

Sharing Rules automatically extend record access to users beyond the OWD baseline. They are used when OWD is set to Private or Public Read Only, and you need a specific group of users to see records they don't own. Types: (1) Owner-Based: Share records owned by a specific group or role with another group or role. (2) Criteria-Based: Share records matching specific field criteria (e.g., all Accounts in the "Technology" industry shared with the Sales team). Sharing rules can grant Read Only or Read/Write access. They cannot be used to restrict access below OWD.

The Role Hierarchy is a tree structure mirroring the organisation's reporting structure. Users in a higher role automatically gain access to records owned by users in roles beneath them (when OWD is not Public Read/Write and "Grant Access Using Hierarchies" is enabled). This means a Sales Manager can view all records owned by their Sales Reps. The role hierarchy does not control object-level permissions (that is done by profiles/permission sets). Custom objects have a "Grant Access Using Hierarchies" toggle — disabling it means only sharing rules/OWD control access regardless of role position.

Field-Level Security (FLS) is the authoritative security control that determines whether a user can see (visible) or edit (editable) a specific field, regardless of the page layout. It is configured via profiles and permission sets. Page Layouts control how fields appear on a record detail/edit page (position, required on layout, read-only on layout) for a specific profile/record-type combination. A field hidden via FLS will not appear anywhere — API, reports, Apex queries (in enforced contexts), or layouts. A field removed from a layout is still accessible via API and reports if FLS permits. FLS is security; page layout is presentation.

Record Types allow you to offer different picklist values, page layouts, and business processes to different users based on their profile. Use cases: (1) A company sells to both B2B and B2C customers — two Account record types present different fields and industry picklists. (2) An HR team uses two Case record types: "Employee Inquiry" and "Benefits Request" — each with a different page layout. (3) Opportunity stages can differ for New Business vs Renewal record types. Users are assigned access to record types via their profile. When creating a record, if a user has access to multiple record types, they are prompted to choose one.

Validation Rules enforce data quality by checking that a record meets specific criteria before it is saved. They use formula expressions that return TRUE when the rule is violated — Salesforce then prevents the save and displays an error message. Key functions used: ISBLANK() for checking empty fields, ISPICKVAL() for picklist values, ISCHANGED() to detect field changes, ISNEW() for insert-only validation, PRIORVALUE() to compare current vs previous values. Tips: (1) Use ISNEW() to apply rules only on creation. (2) Use AND()/OR() for complex logic. (3) Test edge cases carefully as validation rules fire on all save operations including API integrations.

Workflow Rules are the legacy automation tool limited to field updates, email alerts, tasks, and outbound messages. They only trigger on record save and have limited cross-object capabilities. Salesforce has announced their retirement. Flow Builder is the modern replacement offering far greater capability: Record-Triggered Flows, Screen Flows, Scheduled Flows, and Auto-launched Flows. Flows can create/update/delete records on any object, call Apex, send custom notifications, post to Chatter, navigate subflows, and handle complex branching. Admins should migrate all Workflow Rules to Flows. Flow also replaces Process Builder, which is also being retired.

An Approval Process routes records through a defined approval chain. Configuration steps: (1) Define entry criteria (conditions a record must meet to be submitted). (2) Set up approval steps — each with an assigned approver (user, queue, related user field, or role). (3) Configure approval actions (field updates, emails, tasks) and rejection actions. (4) Set up recall actions for when the submitter withdraws the request. (5) Choose whether approvers can edit records during the process. Records in an approval process are locked from editing. Approvers can act via email (one-click approve/reject) or via the approval queue in Salesforce. Multiple steps can require unanimous or first-response approval.

(1) Tabular: Simple flat list of records with no subtotals. Good for exporting data. Cannot be used as a dashboard source. (2) Summary: Records grouped by one or more fields with subtotals per group. The most common report type. Can be used in dashboards. (3) Matrix: Rows and columns grouped simultaneously with totals at each intersection. Ideal for pivot-table style comparisons (e.g., revenue by product by region). (4) Joined: Multiple report blocks, each with different objects or filters, displayed side by side in one report. Useful for combining related but distinct data sets. Tabular, Summary, and Matrix share one data source; Joined can have up to five blocks from different report types.

A Report is a detailed data set with filtering and grouping. A Dashboard is a visual snapshot of report data displayed through charts, gauges, metrics, tables, and funnels. Key differences: (1) A dashboard component must be sourced from a report (Summary, Matrix, or Joined — not Tabular). (2) Dashboards have a "running user" — data is shown as if that user is viewing it. Dynamic dashboards show data based on the logged-in viewer's own access. (3) Dashboards can contain up to 20 components. (4) Dashboards refresh on demand or on a schedule. Use dashboards for executive-level KPIs; use reports for detailed data analysis.

List Views are filtered views of object records displayed in a tabular format on object home pages. They allow users to see a specific subset of records with chosen columns. Sharing options: (1) Only I can see this list view: Private to the creator. (2) All users can see this list view: Visible to all users with access to the object. (3) Share with groups of users: Visible to specific public groups or roles. List Views also support kanban view for pipeline management and can be used as dashboard sources via the List View Charts feature. Admins can pin a list view as the default for an object.

A Formula Field is a read-only field that calculates its value dynamically at runtime based on other fields, functions, and operators. It does not store data — it is recalculated every time it is displayed. Use cases: full name concatenation, age calculation from a date, commission amount based on revenue. Limitations: (1) Cannot directly reference fields from unrelated objects (only parent fields via relationship notation). (2) Cannot reference other formula fields in complex cross-object lookups beyond 5 levels. (3) Formula character limit is 3,900 characters (compiled). (4) They cannot be used in certain SOQL WHERE clauses for performance reasons. (5) They cannot write back to the record — use Flows or Apex for that.

A Roll-Up Summary field is a field on a master record that aggregates values from related detail records in a master-detail relationship. Aggregate functions: COUNT (count of detail records), SUM, MIN, MAX. Restrictions: (1) Only available on Master objects in a master-detail relationship (not lookup). (2) The detail field being rolled up must be a currency, number, or percent field (for SUM/MIN/MAX). (3) Cannot roll up formula fields that reference fields from other objects. (4) Limited to 25 roll-up summary fields per object. Use cases: total Opportunity value on Account, count of Cases, minimum contract start date. For lookup relationships, use Flows or Apex triggers to simulate roll-ups.

Data Import Wizard: A browser-based tool accessible from Setup. Supports up to 50,000 records. Works for standard objects (Accounts, Contacts, Leads, Solutions, Campaign Members) and custom objects. Handles duplicate matching. Easy to use but limited. Data Loader: A desktop application (Windows/Mac). Supports up to 5 million records per batch. Works on all objects including ones the Import Wizard doesn't support. Supports insert, update, upsert, delete, hard delete, and export. Requires CSV files and field mapping. Supports command-line automation for scheduled jobs. Use Data Import Wizard for simple, smaller imports; use Data Loader for large volumes, complex objects, or automated processes.

Duplicate Management consists of two components: (1) Matching Rules: Define how Salesforce identifies potential duplicates by comparing field values. Standard matching rules exist for Contacts, Leads, and Accounts. Custom matching rules can use exact match, fuzzy match (for names), or phone/email match algorithms. (2) Duplicate Rules: Define what happens when a match is found. Actions: Block (prevent saving) or Allow with an alert (warn the user but allow saving). Duplicate rules can apply to all users or specific profiles, and can vary behaviour when records are created via API. Reports on duplicates can be generated to review flagged records.

Admins have access to several Einstein features depending on the org's edition and licences: (1) Einstein Lead Scoring: Ranks leads by likelihood to convert based on historical conversion patterns. (2) Einstein Opportunity Scoring: Predicts the probability of winning an opportunity. (3) Einstein Activity Capture: Automatically logs emails and calendar events to related Salesforce records. (4) Einstein Analytics (CRM Analytics): Advanced analytics and AI-driven dashboards. (5) Einstein Next Best Action: Surface contextual recommendations on record pages. Admins enable these features in Setup, configure data sharing settings, and assign Einstein permission set licences to users.

Mobile configuration involves: (1) Mobile Navigation: Configuring the navigation menu items (objects, apps, utilities) visible in the Salesforce mobile app via Setup > Salesforce Mobile App Navigation. (2) Compact Layouts: Define the fields shown in the record header on mobile (and in list views). Configured per object and assigned via record types. (3) Quick Actions: Object-specific and global quick actions appear in the action bar on mobile — used for creating records, logging calls, or custom flows. (4) Mobile-enabled Page Layouts: Layouts should be kept concise for mobile usability. (5) Lightning App Builder: Create phone-specific record pages with relevant components.

Salesforce offers four sandbox types: (1) Developer: Metadata-only copy. 200 MB storage. Free with most editions. Refresh interval: 1 day. Used for development and unit testing. (2) Developer Pro: Metadata-only copy. 1 GB storage. Refresh interval: 1 day. For larger development projects. (3) Partial Copy: Metadata plus a sample of production data (configurable via sandbox template). 5 GB storage. Refresh interval: 5 days. Used for testing with realistic data volumes. (4) Full: Complete copy of production metadata and all data. Same storage as production. Refresh interval: 29 days. Used for final UAT, performance testing, and training.

Change Sets are a point-and-click deployment tool for moving metadata between connected Salesforce orgs. Key limitations: (1) Only works between orgs with an established Deployment Connection (e.g., sandbox to production). (2) Cannot delete metadata — only adds or updates. (3) Does not support all metadata types. (4) No version control integration. (5) Deployment can fail if dependencies (e.g., field referenced in a validation rule) are not included. Best practice: always validate a change set before deploying. For more robust, scalable deployments, use Salesforce CLI, Gearset, Copado, or unlocked packages with proper CI/CD pipelines.

AppExchange is Salesforce's marketplace for third-party apps, components, and consulting services. Before installing a package: (1) Check the Security Review status — Salesforce-reviewed packages have passed a security audit. (2) Review ratings, reviews, and the number of installs. (3) Check compatibility with your Salesforce edition and API version. (4) Read the documentation for required permissions and object/field impacts. (5) Test in a sandbox first before production. (6) Review what the package accesses (objects, fields, external sites) in the installation screen. (7) Choose whether to install for All Users, Admins Only, or specific profiles. Always review package release notes for updates.

Login IP Ranges: Restrict which IP addresses users on a given profile can log in from. If a user attempts to log in from an IP outside the range, they are blocked (and may receive a verification email if the setting allows). Set per profile under Profile > Login IP Ranges. Login Hours: Restrict the days and hours users on a profile can access Salesforce. If a user is logged in and their session falls outside login hours, they are logged out on the next page load. Both settings are profile-level controls used to prevent unauthorised access — for example, restricting call centre agents to business hours and office IP addresses.

The Setup Audit Trail records changes made to the Salesforce org's configuration (metadata) by administrators. It logs the date, time, the user who made the change, and what was changed (e.g., "Created custom field Opportunity.Discount__c"). Accessible from Setup > Audit Trail. It retains up to 180 days of history (downloadable as CSV for longer history). Use cases: (1) Investigating who made an unintended configuration change. (2) Compliance auditing. (3) Troubleshooting newly introduced bugs by correlating them with recent config changes. (4) Reviewing changes made by external consultants or other admins. It does not track data changes — for that, use Field History Tracking or Field Audit Trail.