Question 1

What does a Salesforce Administrator actually do day-to-day?

Accepted Answer

A Salesforce Administrator is the person who configures the platform so that the business can run on it without writing code. The day-to-day work clusters around four areas: user management, data, automation, and governance. User management means provisioning users, assigning licences, managing profiles and permission sets, and resetting passwords. Data work means importing and exporting records, fixing duplicates, building reports and dashboards, and looking after data quality. Automation means building flows, validation rules, approval processes, and email alerts so manual steps disappear. Governance means managing change sets or deployments between sandbox and production, monitoring storage, watching the setup audit trail, and reviewing release updates. Most admins also act as the first line of support for users — if a sales rep can't see a record, the admin checks the sharing model; if a screen looks wrong, the admin checks the page layout or Lightning App Builder. On a typical day an admin will field a few support tickets, ship a small enhancement (a new field, a tweak to a flow), and spend the rest of the time on a longer project like a migration or a new app rollout.

Question 2

What is the difference between a Profile and a Permission Set?

Accepted Answer

Both grant permissions, but they serve different purposes. A Profile is mandatory — every user has exactly one. It defines the baseline: which login hours and IP ranges are allowed, what the default record type and page layout assignments are, and a starter set of object, field, and system permissions. Historically Salesforce used profiles for almost everything, which created profile sprawl — dozens of slightly different profiles, hard to maintain. A Permission Set is additive — a user can have many. It is used to grant extra access on top of the profile. If five users in different profiles all need access to a custom Contracts object, you don't create five profile variants; you create one Contracts permission set and assign it to those five users. Permission Set Groups then bundle multiple permission sets into a single assignable unit, which is how Salesforce now recommends modelling job functions. Salesforce's current direction is to keep profiles minimal — typically just login settings and record-type defaults — and put everything else in permission sets and permission set groups. Profiles are no longer being enhanced, and the long-term plan is to migrate most permissions out of

Question 3

What is an Object in Salesforce, and what kinds are there?

Accepted Answer

An Object is a database table — it defines the structure for a kind of record. Each Object has fields (columns), records (rows), a page layout, and security settings. Salesforce ships standard Objects like Account, Contact, Opportunity, Lead, Case, and User. These come pre-built with a fixed name and a set of standard fields. You can add custom fields to them, but you can't rename or remove the standard fields without translation tricks. You can also create custom Objects for anything the standard schema doesn't cover — for example a custom Project object if you're building a delivery-tracking app. Custom objects always end with , like . They get the same platform features as standard objects: validation rules, page layouts, sharing rules, reports, the API, and so on. Two more flavours exist: External Objects ( ), which proxy data from an external system in real time without copying it, and Big Objects ( ), which store billions of rows for archival use cases but trade off some standard features like reports and triggers.

Question 4

What is the difference between a Standard Field and a Custom Field?

Accepted Answer

A Standard Field ships with the object — Account Name, Industry, Owner, Created Date, and so on. You can't delete a standard field. You can usually edit its label, help text, and picklist values, and on most you can change field-level security and page-layout placement, but the API name is fixed. A Custom Field is one you create. Its API name always ends with (for example ). You choose the data type — Text, Number, Currency, Date, Picklist, Formula, Roll-Up Summary, Lookup, Master-Detail, Geolocation, Encrypted Text, and so on. You can edit, delete, change field-level security, and reference custom fields in formulas, validation rules, flows, reports, and Apex. Two practical differences matter in interviews. First, deleting a custom field doesn't fully remove it for 15 days — it sits in a deletion queue and can be restored. Second, field limits are real: each object has a cap on the number of custom fields (typically around 800), and certain field types like Roll-Up Summary, Master-Detail, and Long Text have their own sub-limits. If you keep adding custom fields casually, you can hit those limits and have to refactor.

Question 5

What is a Record Type and when would you use one?

Accepted Answer

A Record Type lets a single object support multiple business processes by varying picklist values, page layouts, and processes per record. The object schema stays the same — same fields, same API names — but different users see different versions of it. Classic example: you have one Opportunity object but two sales motions — New Business and Renewal. They use the same Stages picklist, but New Business should only show stages like Prospecting, Qualification, Proposal, Closed Won, while Renewal should show Engaged, Negotiating, Renewed, Churned. You create two record types, configure each one's picklist values via the master picklist, and assign different page layouts so each shows the right fields. Record Types also drive sales paths, approval routing, and even validation logic ( ). They're assigned per profile or permission set, and a user with access to multiple record types is prompted to choose when creating a record. A common mistake is overusing them — every business unit asks for "their own record type" and you end up with ten variants that mostly duplicate each other. Rule of thumb: use Record Types when picklist values, page layouts, or processes meaningfully differ. If onl

Question 6

What is a Sandbox and what types are available?

Accepted Answer

A Sandbox is a copy of your production org used for development, testing, training, or staging. It's isolated — changes you make there never affect production until you deploy them. Every Salesforce org gets at least one sandbox; bigger editions get more. There are four types, ordered by what they include: - Developer Sandbox — metadata only, no production data. 200 MB storage. Refreshable once a day. Best for solo development. - Developer Pro Sandbox — same as Developer but 1 GB of storage. Daily refresh. Useful when you need a bit more headroom for sample data. - Partial Copy Sandbox — metadata plus a configurable subset of production data, defined by a Sandbox Template. 5 GB. Refreshable every 5 days. Used for UAT with realistic data. - Full Sandbox — exact replica of production: all data, all metadata. Same storage limit as production. Refreshable every 29 days. Used for performance testing, full regression, and staging. You access the sandbox at (or the org's My Domain test URL) and append to your username. Refreshing a sandbox replaces it with a fresh production copy and discards any unmerged changes — common cause of lost work if not coordinated.

Question 7

What is a Page Layout and how does it differ from a Lightning Record Page?

Accepted Answer

A Page Layout controls the field arrangement, related lists, and buttons on a record's classic detail page. It's an object- and record-type-scoped configuration: per object you can have many page layouts, and you assign them to users by profile (and optionally per record type). In Lightning Experience, much of what users actually see is driven by a Lightning Record Page built in the Lightning App Builder, not the page layout. The Lightning Record Page controls the overall page composition: which components appear, where the highlights panel sits, what the activity timeline shows, what tabs are present. The Page Layout is still in play — it controls the contents of the Details tab inside that Lightning page — but everything around it is the Lightning Record Page's job. So if a user complains "I can't see this field", the answer depends on which page they mean. If they're on the Details tab, fix the page layout. If they're missing a related list or a custom component, fix the Lightning Record Page. Both have their own assignment model: page layouts assign by profile/record type; Lightning Record Pages assign by app, record type, and profile.

Question 8

What is the difference between a Lookup and a Master-Detail relationship?

Accepted Answer

Both link records on two objects. The difference is how tightly the child is bound to the parent. A Lookup Relationship is a loose link — the child can exist without a parent (the field is optional by default), the child has its own Owner, and deleting the parent doesn't delete the child. Sharing on the two objects is independent. Use lookups when the child has standalone meaning, like Contact - Account: a contact lives whether or not the account does. A Master-Detail Relationship is a tight link — the child must have a parent, the child has no Owner field (it inherits sharing and ownership from the master), and deleting the master cascades to delete all detail records. The child also can't have its own org-wide default; security flows from the parent. Use master-detail when the child is meaningless without the parent — for example Opportunity Line Item - Opportunity, or any junction object representing a many-to-many link. A Junction Object is the canonical use case for master-detail: it has two master-detail fields, one to each side of the many-to-many. The two parents own and share the junction record jointly. You can convert lookup - master-detail (only if every child record al

Question 9

Walk me through the Salesforce sharing model from most to least restrictive.

Accepted Answer

Salesforce evaluates record access in layers. Each layer can only open up access — the model is additive once you set the floor. 1. Org-Wide Defaults (OWD) — set the floor. Per object you choose Public Read/Write, Public Read Only, Private, or Controlled by Parent. Private locks records to the owner; everyone else needs a higher layer to see them. 2. Role Hierarchy — managers automatically see and edit records owned by users beneath them in the hierarchy, if the object has Grant Access Using Hierarchies enabled (the default for most standard objects, optional for custom). 3. Sharing Rules — declarative criteria-based or owner-based rules that grant Read or Read/Write to a Public Group, Role, or Role-and-Subordinates. Usually the workhorse for cross-team access. 4. Manual Sharing — a record owner or anyone with Modify All can click Share and grant access to one specific user or group. Used for one-offs. 5. Apex Managed Sharing — programmatic sharing via the SharingRule and Share objects. Use when business rules can't be expressed declaratively. 6. Implicit Sharing — invisible Salesforce-managed sharing, most often between Account and its child Contacts/Opportunities/Cases — if you c

Question 10

What is the difference between a Profile and a Role?

Accepted Answer

They sound similar but they answer different questions. A Profile answers "what can this user do ?" — what objects, fields, apps, and system permissions they have. It controls things like Create/Read/Edit/Delete on objects, Field-Level Security, login hours, and IP restrictions. Every user has exactly one profile. A Role answers "what records can this user see ?" — its only job is to plug the user into the Role Hierarchy , which is what enables managers to see records owned by their reports. A user can exist without a role, in which case they sit at the very top of the hierarchy and don't gain hierarchical access. Roles do not grant any object-level or field-level permission. So in a typical org you might have one profile called Sales User and use roles to model the org chart — VP Sales Director Manager Rep. Every Sales User has the same profile (same permissions) but different roles (different visibility into reports' opportunities). A useful diagnostic: if a user can't do something (create a record, edit a field), check the profile and any permission sets. If a user can't see a record they should be able to, check the role hierarchy, sharing rules, and OWD — not the profile.

Question 11

When would you use a Validation Rule instead of marking a field as Required?

Accepted Answer

Required at the field level means the user must enter something every time they save the record — non-null, non-empty. It applies to every record-creation and edit path: page layout, API, mobile, mass-update, Data Loader. It's a single boolean. A Validation Rule is more flexible. It's a Boolean formula evaluated on save; if it returns TRUE the save is rejected with a custom error message. Validation rules can express conditional logic that field-required can't: - "Close Date is required only if Stage = Closed Won" — required-when, not always required. - "Discount cannot exceed 30% unless Approved By Manager is checked" — cross-field constraints. - "Industry must be set when Annual Revenue is over a threshold" — dependent validation. - "Email must match a regex pattern" — format validation that field-required can't check. You'd pick required at the field level when the field truly must always have a value. You'd pick a validation rule when the requirement is conditional, depends on other fields, validates format, or you want a tailored error message for the user. Validation rules also fire after Field-Level Security; a hidden required field can still block a save because the engine

Question 12

Workflow Rules, Process Builder, Flow — which one would you use today and why?

Accepted Answer

Flow — full stop. Salesforce has put Workflow Rules and Process Builder on the retirement path. New automation should be built in Flow Builder. The history matters in interviews: - Workflow Rules were the original tool. They could update fields, send emails, create tasks, and send outbound messages — that's it. Simple, fast, but extremely limited. - Process Builder came later. It could do more (call Apex, create records, branching) but had performance issues, was hard to debug, and is now end-of-life. - Flow does everything both of those did plus much more: screens, loops, calls to Apex, HTTP callouts, before-save record-triggered flows for fast field updates, scheduled paths, error paths, decision elements, sub-flows. So in a brand-new build, you reach for Flow. For existing orgs the conversation shifts: there's a Migrate to Flow tool that converts workflow rules and process builder processes to flows automatically, with manual cleanup needed afterwards. Salesforce has announced a hard retirement timeline, and orgs that haven't migrated yet are running on borrowed time. A nuance: for record-triggered flows, prefer before-save flows to update fields on the same record — they run an

Question 13

How do Field-Level Security and Page Layouts each control field visibility, and which wins?

Accepted Answer

Field-Level Security (FLS) is set per profile or permission set. For each field on each object you set Read, Edit, or Hidden. FLS controls API-level access too — even if a hidden field is on a page layout, the user simply doesn't see it. FLS also affects what's visible in reports, list views, search results, and to integrations using that user's credentials. Page Layout is set per object and (optionally) per record type. The layout controls whether a field appears on the detail page and how it's grouped — but only for users with FLS access to that field. If FLS hides a field, no page layout will show it. So FLS is the gate; the page layout is the placement. FLS wins when the two conflict. Practical implication: if you want a field to be invisible to a group of users and not exposed via the API, set its FLS to Hidden for those profiles/permission sets. If you only want it off the screen but accessible programmatically (rare but it happens), remove it from the page layout but keep FLS Read or Edit. Lightning Record Pages with Dynamic Forms add a wrinkle: with Dynamic Forms, the page layout's field section is replaced by component-level field placement, but FLS still gates everything.

Question 14

When would you use a Permission Set Group instead of individual Permission Sets?

Accepted Answer

Permission Sets are atomic. You build one per capability — "Can Export Reports", "Can Approve Discounts", "Can Edit Closed Opportunities" — and assign them to users. A Permission Set Group bundles multiple permission sets into a single assignable unit, intended to model a job function . Instead of assigning a Sales Manager user 8 separate permission sets, you create a Sales Manager permission set group containing those 8, and assign just the group. Two features make groups more than a list: - Calculated permissions — Salesforce computes the union of all included permission sets and the group itself, so user permission checks stay fast at runtime. - Muting permission sets — within a group you can attach a muting permission set that removes specific permissions otherwise granted by the included sets. This lets you start from a broad bundle and selectively narrow it down — useful when one role needs almost everything in another role's group except for one or two sensitive permissions. Use a permission set group when you have a recognisable job function (Sales Rep, Sales Manager, Service Agent) and you want one assignment instead of many. Use individual permission sets when permissions

Question 15

When would you use a Public Group versus a Queue?

Accepted Answer

Both group users for sharing and assignment, but they serve different purposes. A Public Group is a logical group of users (and other groups, roles, and roles-and-subordinates) used in sharing rules , list view filters, report sharing, and folder access. A public group doesn't own records — it's just a way to refer to a set of users for "who can see this". A Queue is more like a shared mailbox for ownership. A queue can own records — typically Cases, Leads, or custom objects with the Allow Queues option enabled. Records sit in the queue until someone in it takes ownership. Queues are the foundation of routing models like assignment rules and Omni-Channel skills-based routing. Choose by the question: - "These five users should all be able to see records X" - Public Group, used in a sharing rule. - "These five users should all be able to work on records X — anyone can pick the next one up" - Queue. A queue can be referenced in sharing rules too (because membership confers visibility), but a public group cannot own records. Some objects (like Opportunity) don't support queues, so for those a public group plus sharing rule is your only option.

Question 16

How does Field History Tracking work, and what are its limits?

Accepted Answer

Field History Tracking records old/new value changes for selected fields on an object into the related History object (e.g., AccountHistory, OpportunityHistory, MyCustom History). For each tracked field, when a value changes, Salesforce writes a row with the user, timestamp, old value, and new value. You enable it per object in Object Manager, then check the boxes for the fields you want tracked. Standard objects let you track up to 20 fields each; custom objects also have a 20-field cap. It's free for standard fields and most custom field types, but encrypted text fields, formula fields, roll-up summaries, and long text areas are not trackable. Two important practical limits: - Retention — by default field history rows are retained for 18-24 months in the History object. Older rows are purged unless you've licenced Field Audit Trail (part of Salesforce Shield), which extends retention to up to 10 years and stores history in a separate set of tables. - It's eventually consistent — history rows can lag behind the record save by seconds, which matters if you're building a real-time audit feature on top of history. For higher-volume audit needs (every login, every API call, every expo

Question 17

How would you mass-update 50,000 records — and what would you check first?

Accepted Answer

A few options, ordered by typical fit: - Data Loader (or Dataloader.io ) — the workhorse for 50k records. Export the records you need, edit the CSV, run an Update operation. Use the Bulk API for large jobs (recommended above 5,000 rows). Failures land in a per-batch error CSV you can iterate on. - Data Import Wizard — only goes up to 50,000 rows, supports a small set of objects, and is more guided. Fine for a one-off where the user's not comfortable with Data Loader. - Mass Update Records / Mass Transfer — declarative, but limited to specific actions (transfer ownership, mass-update addresses). Useful for the narrow cases they support. - Flow — record-triggered flow for ongoing updates, or a scheduled flow / scheduled-trigger flow with batches for one-off backfills. Good for "future" updates; not ideal for a one-time 50k operation. - SOQL Update via Workbench — fine for small fixes, painful at 50k. Before clicking Run on any of those, four checks are non-negotiable: 1. Sandbox first — never run a 50k update straight against production. Refresh a sandbox or use a Partial Copy and dry-run there. 2. Validation rules and required fields — they fire on Data Loader updates. A rule that d

Question 18

Walk me through the trade-offs of Public Read/Write vs Public Read Only vs Private Org-Wide Defaults.

Accepted Answer

OWD is the security floor — the lowest level of access any user has to records they don't own. The trade-offs are between simplicity, performance, and the cost of opening access back up. Public Read/Write — anyone with object access can read and edit any record. Simple, fast, no sharing recalculation cost. Use it when records are intrinsically shared — e.g., an Account in a small B2B company where every rep can edit every account by design. The cost is no record-level privacy; you're trusting profile permissions and audit instead. Public Read Only — everyone reads, owner edits, others need a higher layer (sharing rule, manual sharing) for edit. Useful for reference data: every rep can see all Products, but only Product Managers can edit. Sharing recalculation is slightly more expensive than Public R/W but still cheap. Private — only the owner sees and edits, plus anything granted by Role Hierarchy, Sharing Rules, Manual Sharing, Teams, Implicit Sharing, or Apex Managed Sharing. This is where things get expensive: every user-record visibility check has to walk those layers, and any change to a sharing rule kicks off a sharing recalculation that can take hours on large orgs. You also

Question 19

How does the Role Hierarchy affect record visibility, and where can it surprise you?

Accepted Answer

The Role Hierarchy gives users implicit access to records owned by users below them in the hierarchy, on objects where Grant Access Using Hierarchies is enabled. For most standard objects this is on by default. For custom objects you can turn it off. Three important nuances: 1. It's about ownership, not membership — if a user owns a record, every user above them in the hierarchy gets visibility. This is independent of who works on the record. So if a rep transfers ownership to a service queue, hierarchical access for the rep's manager to that record is gone — even though the manager is technically still over the rep. 2. It only opens access; it never restricts — putting someone below another in the hierarchy doesn't hide records from them; it just gives the upper user access to the lower's. To hide records you need OWD (Private) plus a deliberately constructed sharing model. 3. It bypasses Sharing Rules but not OWD — hierarchy-driven access is its own grant; if Grant Access Using Hierarchies is unchecked on a custom object, the role hierarchy contributes nothing to access for that object. Sharing Rules and Manual Sharing are still needed to grant cross-team access. Where it surpris

Question 20

Walk me through deploying changes from a sandbox to production. What options are there, and when do you pick which?

Accepted Answer

Three main paths, plus a few specialised tools. Change Sets — the classic point-and-click. You build an Outbound Change Set in the source org, add metadata components, upload it, and a matching Inbound Change Set appears in the target. You validate, then deploy. Pros: fully GUI, no extra tooling. Cons: slow, error-prone for missing dependencies, no real version control (you can't diff a change set), limited to deployment connections between linked orgs. Salesforce DX with metadata API / SF CLI — script from a Git-tracked source folder. You can review diffs in PRs, run validations against any sandbox, and deploy with a tested metadata set. This is the modern professional baseline. Pros: version control, automation, scriptable. Cons: requires team buy-in and a CI/CD setup. Managed/Unmanaged Packages — for distributing reusable components, especially across unrelated orgs. Less common for internal deploys but the right answer for ISVs and internal libraries. DevOps platforms — Gearset, Copado, Salto, AutoRABIT, Flosum. They wrap the metadata API with diffing, conflict detection, scheduled releases, rollback, and analytics. Worth using once team size and release cadence outgrow plain D

Question 21

Walk me through the anatomy of an Approval Process — entry criteria, initial submitters, steps, and final actions.

Accepted Answer

An Approval Process routes a record through one or more approval steps before something happens (typically a status change). It has a precise structure: Entry Criteria — a filter or formula evaluated when the process starts. If the record doesn't match, you can choose to reject the submission or fall through to a default. Without entry criteria, every submitted record runs through. Initial Submitters — the users, profiles, public groups, or roles allowed to submit a record into the process. By default this is the record owner. Initial Submission Actions — actions that fire when the record is first submitted. Typical: lock the record, set a status field to "Pending Approval", send a notification. Approval Steps — the actual approval ladder. Each step has: - Step Criteria — when does this step apply (formula or filter). Skips can be conditional. - Approver(s) — a specific user, the submitter's manager, a queue (yes, queues can approve), a public group, or auto-approve. Multiple approvers can be combined as approve unanimously (every one must approve) or first response (any one approves). - Step Approval/Rejection Actions — actions when this specific step approves or rejects. - Reject

Question 22

A flow is failing silently in production. How do you debug it?

Accepted Answer

"Silently" usually means one of three things: the flow logs an error to the admin email but no user-facing message, an error path swallows the exception, or the flow is succeeding but doing the wrong thing. Diagnostic steps in roughly this order: 1. Check the Flow's Run History / Paused and Failed Flow Interviews — Setup - Process Automation - Paused and Failed Flow Interviews. Failed instances appear here with the input variables and the element that failed. This is the fastest path to the actual error. 2. Check the admin error email — by default failed flow interviews email the user who last modified the flow with the stack trace and variable values. If that email is going to a personal inbox no one checks, fix that first (Setup - Process Automation Settings - Default Workflow User - point to a monitored alias). 3. Reproduce in a sandbox with debug log — turn on a debug log for the running user, run the same input. The flow's element-by-element execution shows up in the debug log under FLOW category lines. You see exactly which element ran with what inputs and outputs. 4. Use Flow Builder's Debug Run — if reproducible, run Debug from Flow Builder. You can step element by element

Question 23

When would you choose Sharing Rules over Manual Sharing, and vice versa?

Accepted Answer

Sharing Rules are declarative, criteria-based or owner-based grants that apply to every matching record, automatically. They re-evaluate when records change (or when you click Recalculate). You configure them in Setup once and they keep working forever. Manual Sharing is a per-record grant added by clicking Share on the record (or via Apex / API). It applies only to the record on which it was added, doesn't cascade to similar records, and is removed if the record's owner changes (unless granted by Apex managed sharing with other than Manual). You pick by cardinality and rule : - "Every opportunity in the West Region should be visible to the Marketing team." - Sharing Rule. The rule encodes the policy; it scales. - "This one prospect requires NDA-level secrecy and only three named users should see it." - Manual Sharing. The grant is bespoke to that record. Use sharing rules when: - The grant criteria can be expressed as object filters or owner-based rules. - The volume justifies the sharing recalculation cost (sharing rules increase recalc time, especially as you add many). - You want zero-touch maintenance: new matching records pick up the rule automatically. Use manual sharing whe

Question 24

How would you enforce data classification and audit access using Shield, Event Monitoring, and related tools?

Accepted Answer

Data classification and audit aren't a single feature — they're a layered set of platform controls. Data Classification (the metadata) lives on every field in Object Manager. You assign each field a Compliance Categorization (PCI, PII, HIPAA, GLBA, etc.), a Data Sensitivity Level (Public, Internal, Confidential, Restricted, Mission Critical), and a Data Owner. This metadata is reportable but doesn't enforce anything by itself — its purpose is to give you (and tools downstream) the information to enforce policy. Salesforce Shield is a paid suite that adds three things: - Platform Encryption — encrypts data at rest using tenant-managed keys. Lets you encrypt selected standard fields (Account.Name, Contact.Email), all custom field types that support it, and files. Critical caveat: encrypted fields can break some declarative features (formulas referencing them, certain SOQL filters), so you don't blanket-encrypt — you encrypt the fields the classification metadata flagged as Restricted/Mission Critical. - Field Audit Trail — extends field history retention from 18-24 months to 10 years, and stores it in a separate, queryable archive. - Event Monitoring — produces detailed event log fil

Question 25

When would you reach for Apex Managed Sharing instead of declarative sharing?

Accepted Answer

Declarative sharing — OWD, Role Hierarchy, Sharing Rules, Manual Sharing — covers most cases. Apex Managed Sharing is the escape hatch when business rules can't be expressed declaratively. You write to the object's table (e.g., , ) using Apex. Each share row has , , (Read or Edit), and a that you assign via an Apex Sharing Reason — a metadata-defined label that tells you and Salesforce why this share exists. Reach for it when: 1. Sharing logic depends on data in another object. "A user gets access to an Account if they're on the Account Team for any of its child Opportunities." Sharing Rules can't traverse parent-child for this; Apex can. 2. Sharing must reflect a calculation, not a fixed criteria. "Grant access to the user listed in the custom Lookup field Deal Lawyer on this Opportunity." That's an inherited reference, not a rule the engine can express. 3. You need temporary access with a deterministic expiry. Sharing Rules don't expire; you can put them in but you have to remove them. Apex Managed Sharing with a scheduled job that deletes share rows after N days gives you genuine TTL. 4. You need access to survive owner changes. Manual Sharing is wiped on owner change. Apex shar

Question 26

What is a Custom App in Salesforce, and how is it different from a Connected App?

Accepted Answer

A Custom App is a Lightning navigation grouping — the dropdown at the top-left that organises a set of tabs into a coherent workspace. You create one in Setup - App Manager - New Lightning App, choose Standard or Console navigation, assign tabs, and grant access via profiles or permission sets. Apps don't grant data access — they just present a curated set of tabs. Same Account record looks different inside a Sales App vs a Service App because the surrounding context (related tabs, layout, utility bar) differs. A Connected App is something else entirely: it's an OAuth integration registration. When an external system (Mulesoft, a mobile app, a script) needs to authenticate to Salesforce via OAuth, it does so as a Connected App — a record that defines the consumer key/secret, callback URL, scopes, and IP relaxation rules. Connected Apps live in Setup - App Manager too, which is where the naming confusion comes from. Rule of thumb: if it has tabs, it's a Custom App. If it has a consumer key, it's a Connected App.

Question 27

What is a List View and what are the visibility scopes?

Accepted Answer

A List View is a saved filtered list on an object — Accounts I Own, Open High-Value Opportunities, This Week's Cases. It applies a filter, sorts the results, and picks which fields show up as columns. Three visibility scopes: - Visible only to me — personal list view, just for the user who created it. - Visible to all users — public list view, available to everyone with access to the object. - Visible to certain groups of users — shared with specific public groups, roles, or roles-and-subordinates. Whether a user can create a public list view is gated by the "Manage Public List Views" permission on the object. List views drive Lightning Kanban, list view charts, mass actions, and even mass quick actions — many features layer on top of them. Important: list views always respect the underlying sharing model. A user filtered "All Accounts" still only sees the records they have OWD/role/sharing-rule access to. You can't use a list view to bypass sharing — it's a presentation layer, not an access grant.

Question 28

What is the difference between a Quick Action and a Global Action?

Accepted Answer

Both are buttons that let users do something in one click, but they live at different levels. A Quick Action is bound to a specific object — an "Update Status" action on Case, a "Log a Call" action on Opportunity. It can be a Create-a-Record, Update-a-Record, Log-a-Call, Send-Email, or Custom (Visualforce/LWC) action. It appears on that object's record pages and respects that object's record types and field-level security. A Global Action isn't tied to one object. It appears in the global header (the "+" button in the utility bar) and lets a user create a record from anywhere — typically a quick "New Task", "New Event", or "Log a Call" without navigating to the parent record first. Global actions can pre-populate fields via URL parameters or via the Action's predefined values. In Lightning Experience, Global Actions appear in the Global Publisher Layout , while Object-Specific Actions appear in either the page layout's Mobile and Lightning Actions section or via the Highlights Panel. Both types are configured in Setup - Object Manager (object-specific) or Setup - Global Actions (global).

Question 29

What is the difference between Deactivating and Freezing a user, and when would you use each?

Accepted Answer

Salesforce gives you three states for getting a user out of the org: Freeze , Deactivate , and (for Customer 360 / Identity-licenced contexts) Disable . Freezing stops the user from logging in immediately but does not free up their licence. Use it as a fast first response — someone left unexpectedly, or you suspect a compromised account. They keep ownership of all their records, sharing remains intact, and you can unfreeze instantly. Find it on the user record under Freeze. Deactivating is the proper offboarding step. It frees the licence so it can be reassigned, blocks login, and stops automation that runs as that user. The catch: deactivation is blocked while the user owns records or is referenced in certain places (account team membership, default workflow user, recurring scheduled jobs, queue membership). You either reassign ownership first or — for fast removal — freeze first, then clean up ownership over time. You can't delete a user in Salesforce. Once a user record exists, it's there forever; you can only deactivate. That's because audit trails reference the user ID and need to remain interpretable indefinitely. Order of operations for offboarding: Freeze immediately - reas

Question 30

What is MFA in Salesforce, is it required, and how do you implement it?

Accepted Answer

Multi-Factor Authentication (MFA) requires users to verify identity with a second factor beyond username/password. Salesforce mandated MFA for all production org logins as of 2022, and now auto-enables it on every new org. It is no longer optional for direct Salesforce logins. Supported second factors include the Salesforce Authenticator mobile app (push approval, the recommended option), TOTP authenticator apps like Google Authenticator or Authy, U2F security keys (YubiKey), and built-in platform authenticators like Touch ID / Face ID / Windows Hello. Two implementation paths: - Direct Salesforce logins — MFA is enforced automatically. Users register a verification method on first login or you can pre-enrol them. - SSO logins via an external IdP — Salesforce accepts the IdP's MFA assertion. So if Okta/Azure AD/Ping enforces MFA before issuing the SAML assertion, Salesforce trusts that. You don't double-MFA — but the IdP must actually be enforcing it, which is your responsibility to verify. Exceptions exist for partner and customer community users (they fall under different requirements) and for service accounts using OAuth — the underlying mandate is on interactive human logins.

Question 31

What is a Permission Set License and how does it differ from a Permission Set?

Accepted Answer

A Permission Set is a bundle of permissions you assign to users. A Permission Set License (PSL) is a prerequisite licence that some advanced features require before a permission set can grant them. Concrete example: to give a user the "Sales Console" feature you need both (a) a Sales Console permission included in a permission set, and (b) the Sales Console PSL assigned to the user. Without the PSL, even if the permission set is assigned, the feature stays dark. You see PSLs in the Setup - Company Information - Permission Set Licenses table — Salesforce lists how many of each you've purchased and how many are assigned. Examples: CRM Analytics Plus PSL, Identity Connect PSL, Sales Engagement PSL, Field Service Mobile PSL. A common admin headache: someone gets a permission set, but the feature still doesn't work. Check whether the permission set requires a PSL the user doesn't have. Salesforce shows a warning in the permission set UI when a permission requires a PSL the org hasn't purchased, but for assigned PSLs the issue silently surfaces as "feature missing for some users".

Question 32

What is My Domain in Salesforce and why does it matter?

Accepted Answer

My Domain is a custom subdomain for your Salesforce org — instead of the generic . As of recent releases, My Domain is required for every production org — Salesforce no longer lets you turn it off. Why it matters: 1. SSO and Identity — SAML and OAuth flows require a stable URL to redirect to. My Domain provides that. 2. Security — the URL pattern (which My Domain enables) is a key part of how Salesforce isolates Lightning component sessions and applies CSP policies. 3. Branding — login pages can be branded with the company logo, colours, custom domain. 4. Permission features — features like Login Hours, IP Restrictions, and certain MFA flows require the My Domain URL. 5. Deployment — sandbox URLs, Connected App callbacks, and integrations all reference My Domain consistently. Setting it up: Setup - My Domain - register a name - deploy to users - optionally redirect old URLs. Once deployed, you can also set policies like "prevent login from non-My-Domain URLs" which closes off legacy access patterns. Admins inheriting older orgs sometimes find My Domain not yet deployed or in a half-rolled-out state — surfacing that and finishing the migration is often a quick win.

Question 33

What is the AppExchange and what should an admin know before installing a package?

Accepted Answer

The AppExchange is Salesforce's marketplace for third-party apps, components, and consulting services. Admins encounter it primarily as the source of installable managed packages — Conga, DocuSign, Geopointe, Apsona, the various data quality tools, and so on. Before installing any package, an admin should: 1. Read the AppExchange listing's security review status. Salesforce-reviewed packages have passed a security audit; unreviewed listings are riskier. 2. Install in a sandbox first. Always. Never click Install Now against production from a marketing email. 3. Choose the right install audience — Install for Admins Only, Install for All Users, or Install for Specific Profiles. Most managed packages should start as Admins Only. 4. Inventory what the package adds : custom objects, custom fields, Apex classes, triggers, flows, profiles, permission sets. Salesforce shows a preview but you should also pull a metadata diff after install. 5. Check field/object/code limits. Each managed package counts against your limits (custom objects, custom fields per object, Apex code lines, etc.). A bloated package can push you near caps. 6. Plan for upgrades and uninstalls. Read the package's upgrade

Question 34

What is the difference between a Standard and Custom Profile?

Accepted Answer

Standard Profiles ship with Salesforce — System Administrator, Standard User, Read Only, Marketing User, Solution Manager, and so on. They cannot be deleted, and most of their core permissions cannot be edited. You can still adjust some settings (login IP ranges, default record types, page layout assignments) but the underlying object/system permissions are locked. Custom Profiles are ones you create, typically by cloning a standard profile and modifying it. They can be edited freely — you can grant or revoke any object permission, system permission, FLS, or app assignment. Practical guidance: - Use a Standard Profile only for the System Administrator (who needs all permissions and is the one role you can't reasonably trim) and possibly the temporary "Read Only" profile for guest visibility audits. - For every other persona, clone a standard profile to a custom profile and tune it. The standard profiles' inflexibility almost always bites you eventually. - Modern best practice is to keep custom profiles minimal (login settings + maybe default record types) and push every other permission into permission sets. This keeps your profile inventory shallow and the assignment model maintai

Question 35

How do Duplicate Rules and Matching Rules work together?

Accepted Answer

Salesforce's duplicate management has two cooperating parts: A Matching Rule defines how two records are considered duplicates — which fields are compared and how (exact match, fuzzy match, blank-ignore). For example, a Contact matching rule might say: same Email OR (same First Name fuzzy AND same Last Name exact AND same Company exact). Matching rules don't take action; they're just the comparison logic. A Duplicate Rule defines what to do when a matching rule fires. Per object, you wire a matching rule into a duplicate rule and configure the action: Allow with alert, Block the save, Report only, or both Block and Report. You also choose when it runs (on Create, on Edit), which record types or profiles it applies to, and which conditions exempt records from being checked. So the flow on every save is: Salesforce evaluates the duplicate rule's conditions - if applicable, it runs the matching rule against existing records - if matches are found, the duplicate rule's action is taken (alert/block/report). Standard matching rules ship for Account, Contact, and Lead. You can build custom matching rules for any object including custom ones. Up to 5 active matching rules per object. Dupli

Question 36

How do you organise email templates for multiple teams and brands?

Accepted Answer

Salesforce has multiple template systems and they overlap awkwardly: - Lightning Email Templates (the modern default) — created and edited in the Email Templates app, stored as Enhanced Letterheads or HTML/Text. Folder-based organisation. Used by Email integration, Email Composer, and most flow/send-email actions. - Classic Email Templates — legacy. Visualforce, Custom HTML, and Text variants. Some legacy automations still reference them. - Email Alert Templates (used by Workflow/Flow email alerts) — bound to a specific template at design time. Folder strategy is where most orgs go wrong. Recommended structure: 1. Folder per team/brand — Sales Templates, Service Templates, Marketing Templates, Brand-A, Brand-B. 2. Folder permissions — share each folder only with the public group or role for that team. Marketing's templates shouldn't accidentally end up in Sales' picker. 3. Subfolders for sequences — within a team, group by use case: Welcome, Follow-up, Renewal, Escalation. 4. Naming convention with prefix — is clearer than once you have hundreds of templates across teams. 5. Letterhead per brand — multi-brand orgs benefit from one Enhanced Letterhead per brand so headers/footers st

Question 37

What is the difference between a Picklist, a Multi-Select Picklist, and a Picklist Value Set?

Accepted Answer

All three are about constrained-choice fields, but they sit at different levels. A Picklist is a single-value dropdown — a field where the user picks one option. Standard fields like Industry, Lead Source, Stage are picklists. A Multi-Select Picklist lets the user pick multiple values. Stored internally as a semicolon-delimited string ( ). Multi-selects look convenient but cause real pain: you can't filter or report by individual values cleanly, formula support is limited, and it's a known gotcha for integrations because the order of values isn't deterministic. A Picklist Value Set is a reusable list of values defined once at the org level (Setup - Picklist Value Sets) and referenced by multiple picklist fields. Edit the value set once, and all referencing picklists update — vs maintaining the same list of countries on three different fields and watching them drift apart. A Global Picklist Value Set is the modern term for the same concept — one source of truth for a list of values, used by many fields on many objects. Practical guidance: - Use single-select picklists wherever possible. Multi-selects are "I'll regret this later" land. - For lists used in more than one place (countri

Question 38

What is a Login Flow and when would you use one?

Accepted Answer

A Login Flow is a Flow (built in Flow Builder) that runs after authentication but before the user lands in Salesforce. Think of it as a post-login interception point. Common uses: - Acceptable use prompt — display a one-time terms-and-conditions screen the user must accept. - Step-up MFA — re-verify identity for users connecting from a high-risk geo or with elevated permissions, beyond standard MFA. - Force a password change — push users to update credentials when a policy demands it. - Profile completion — require the user to fill in missing fields (mobile number, time zone, manager) on first login. - Conditional warnings — show a banner if the user is in a sensitive role accessing the org from an unrecognised device. You build the Flow as a Flow Type = Login Flow in Flow Builder, then in Setup - Login Flows assign it to specific profiles. Optionally include conditions. Key constraint: a Login Flow runs every login by default. If the prompt is one-time (e.g., terms acceptance), the flow needs to record that acceptance on the User record (or in a custom Login Acknowledgements c table) and short-circuit on subsequent logins. Login Flows do not run for users authenticating via SAML S

Question 39

When would you use Custom Settings vs Custom Metadata Types?

Accepted Answer

Both store configuration data instead of business records, but they have very different lifecycles. Custom Settings are like lightweight tables specifically for app configuration. Two flavours: - List Custom Settings — singleton records keyed by name (e.g., with one record per region). - Hierarchy Custom Settings — values that override per profile or per user (e.g., default settings for the org, with overrides for specific users). Their key feature: Apex reads them straight from the application cache — extremely fast, no SOQL governor cost. The catch: Custom Settings data is not deployable . The metadata (the table definition) deploys; the rows inside do not. You re-enter values in production manually. They also can't be packaged with managed apps in the same way as metadata. Custom Metadata Types are the modern alternative. They look like Custom Settings (named records, key-value style) but the records themselves are deployable metadata — you build them in a sandbox, deploy via change sets or Salesforce DX, and they land in production with the same values. They're also packageable, queryable from formulas (without SOQL governor cost), and queryable from validation rules. Use Custo

Question 40

What is an Auto-Number field and what should an admin watch out for?

Accepted Answer

An Auto-Number field generates a unique sequential number on record creation, formatted by a display mask: produces , , etc. The next number is stored on the field metadata and increments per insert. What admins watch for: 1. You can't roll back the counter in production. If you mass-import 50,000 test records and then delete them, the counter has still incremented — your next real record will be . Reset is a one-way street. 2. Sandbox refresh copies the counter from production, so test imports in sandbox don't pollute production numbers — but failed sandbox loads still consume sandbox numbers, which can confuse UAT. 3. Format changes — when you change the mask (e.g., to ), Salesforce re-applies the new format only to new records. Existing records keep their old format. So and could coexist. To re-format historical records you need a one-off Data Loader update. 4. Auto-Number is not a primary key. It's just a display value. Salesforce's field is the actual unique identifier. Don't use Auto-Number for joins or lookups — use Id or an External ID custom field. 5. You can manually reset the counter via Setup or a developer action — but it's destructive and rare. Use only after a clean-

Question 41

How does the Salesforce Mobile App differ from Lightning Experience on desktop?

Accepted Answer

The Salesforce Mobile App runs the same metadata as desktop Lightning Experience but with a different rendering layer and a different set of available components. Key differences: - Layout : mobile uses Compact Layouts to control which fields show in highlight views (the top of a record on a phone). Compact Layouts are smaller and prioritise the most-needed fields. - Page composition : Lightning Record Pages can be built specifically for Phone form factor in Lightning App Builder. You can hide entire components, swap layouts, and reorder tabs for phone vs desktop. - Action buttons : the Mobile and Lightning Actions section of the page layout (or the Actions component on a Lightning Record Page) determines which Quick Actions appear in the mobile UI. Some standard buttons (e.g., complex workflows) are desktop-only. - Custom UI : most Lightning Web Components work on mobile, but some features and certain third-party components don't render properly. You always test custom UI on actual mobile devices. - Offline : mobile has limited offline support via the Briefcase feature and Mobile Configurations, but the offline experience is much narrower than desktop. - Notifications : push notif

Question 42

Can you build a Roll-Up Summary on a Lookup relationship? If not, what are the alternatives?

Accepted Answer

Roll-Up Summary fields are only available on Master-Detail relationships. Salesforce limits them to master-detail because rollups depend on the parent owning sharing and lifecycle of the child — semantics that lookup doesn't guarantee. If you have a lookup and need a rollup, you have several options: 1. Convert lookup to master-detail. Possible only if every child record has a non-null parent (otherwise the conversion fails). You also accept the master-detail constraints — child loses owner, sharing inherits, cascade delete. 2. Declarative Lookup Rollup Summaries (DLRS) — an open-source unmanaged package that builds rollups on lookup relationships using scheduled jobs and triggers under the hood. Reliable for most use cases, well-known, but adds a dependency. 3. Apex trigger — write a trigger that recalculates the parent's summary field when child records change. Most flexible, but it's code; needs tests and bulk safety. Don't write a trigger in a loop with SOQL inside. 4. Record-Triggered Flow on the child object — recalculate the parent's summary in a Flow when child records change. Easier to maintain than Apex but be cautious with scale (governor limits, recursion). 5. Reports —

Question 43

Walk me through Salesforce's Order of Execution when a record is saved.

Accepted Answer

When a record is inserted or updated, Salesforce runs a fixed pipeline. Knowing this order is what lets you predict why automations fire (or don't) when they should. The simplified order — there are about 20 steps but the ones that matter to admins are: 1. System Validation — required fields, max field length, foreign key validity. 2. Apex triggers — run code that needs to mutate the record before save. 3. Custom Validation Rules — your declarative rules. If any returns FALSE, save is rejected here. 4. Before-save record-triggered Flows (Fast Field Updates) — modern, fastest place to update fields on the same record. 5. Database save (commit-1) — the record is persisted, but the transaction is not yet committed. 6. Apex triggers — code that needs the record's Id (assigned at step 5). 7. Assignment Rules — Lead/Case assignment rules execute. 8. Auto-Response Rules — Lead/Case auto-response. 9. After-save Record-Triggered Flows — declarative automation that runs after the save. 10. Workflow Rules — legacy, fire field updates and outbound messages. 11. Processes — Process Builder logic (legacy). 12. If a workflow field update happened , before/after triggers and validation rules fire

Question 44

What is a Sharing Recalculation and when does it run?

Accepted Answer

A Sharing Recalculation is the process Salesforce runs to re-evaluate every record's effective access for every user, given the current sharing model. It rewrites the table rows on affected objects. When it runs: 1. You change OWD (e.g., flip Account from Public Read to Private). This triggers a full recalculation on that object — every Account record is re-evaluated for every user. On large orgs this can take hours . 2. You add, edit, or delete a Sharing Rule . A targeted recalc runs over records matching the rule's criteria. 3. Group membership changes — adding a user to a public group, role, or queue. Salesforce recalculates anything granting access to that group. 4. Role hierarchy changes — moving a user under a different manager triggers recalculation of records owned by users below the moved user. 5. You manually click Recalculate in Setup - Sharing Settings - Recalculate, on a per-object or per-rule basis. 6. Apex Managed Sharing changes — no automatic recalc; you trigger it yourself in code. Why it's expensive: for each affected record × each potential user, the engine walks the OWD - Hierarchy - Sharing Rules - Manual - Apex layers, computes effective access, and writes/up

Question 45

How do Org-Wide Defaults differ for Internal vs External (Community / Experience Cloud) users?

Accepted Answer

Salesforce has two separate OWD columns per object once Communities/Experience Cloud is enabled: - Internal Default Access — applies to standard internal users in the org. - External Default Access — applies to community/experience cloud users (Customer Community, Partner Community, etc.). The external default is always equal to or more restrictive than the internal default . You cannot make external access more open than internal — Salesforce enforces this rule to prevent accidental data exposure. Common patterns: - Internal: Public Read/Write. External: Private. (Internal users see everything; partners see only what they own or what's been deliberately shared.) - Internal: Private. External: Private. (Both restricted, e.g., for HR or sensitive case data.) How external users gain access beyond their OWD floor: 1. Sharing Sets — for High-Volume Portal Users. A sharing set says "give external users access to records where the external user's Account matches the record's Account/Contact field". Replaces sharing rules for HVPU since they don't appear in the role hierarchy. 2. Share Groups — extension of Sharing Sets that lets internal users access records that have been shared via a S

Question 46

Walk me through configuring Single Sign-On (SAML) with an external IdP.

Accepted Answer

Pure-admin SAML SSO setup, with Okta/Azure AD/Ping/Auth0/etc. as the IdP. Salesforce is the Service Provider (SP). Steps: 1. Pick the relationship . Salesforce-initiated (user goes to the My Domain login page first) vs IdP-initiated (user starts at the IdP). Most enterprises use IdP-initiated through their portal. 2. Get the IdP metadata — typically an XML file from the IdP exposing certificates, single sign-on URL, entity ID, and signing details. 3. In Salesforce: Setup - Single Sign-On Settings . Create a new SAML SSO Settings record. Either upload the IdP's metadata XML or paste fields manually. 4. Configure the Federation ID — pick which User field on Salesforce (typically the Federation ID field, less commonly Username) the IdP will use to identify the user. The IdP must include the same value in its assertions. 5. In the IdP : configure Salesforce as a service provider. Set the ACS URL ( ), entity ID, and which user attribute maps to the Federation ID. 6. Test from a single test user . Use the SAML Validator in Salesforce to inspect assertions if it fails. Common errors: clock drift between IdP and SP (assertions valid for too short a window), wrong Federation ID, expired cer

Question 47

How do you architect a multi-currency Salesforce org?

Accepted Answer

Multi-currency lets a single org transact in many currencies. Once enabled, you cannot turn it off — so the decision is one-way. Setup: 1. Enable Multi-Currency (Setup - Company Information - Activate Multiple Currencies). This is the irreversible step. 2. Configure your corporate currency — the base currency all reports roll up to. Commonly USD or EUR. 3. Add active currencies — each currency you transact in. ISO codes: USD, EUR, GBP, JPY, INR, etc. 4. Set conversion rates — manual rates updated periodically, or Advanced Currency Management (ACM) for dated exchange rates that respect the rate that was effective when a record was created. ACM is essential for accurate historical reporting on multi-period deals. 5. Decide who edits rates — typically Finance owns this. Admin sets up the permission and process. Implications: - Every currency field on every object now carries the record's currency context. Each Opportunity, Account, etc., has a field and Salesforce stores both the local amount and the converted-to-corporate value. - Reports display in the user's personal currency, the record's currency, or the corporate currency depending on the report's Currency setting. Always set th

Question 48

What are Salesforce's Governor Limits and which ones should an admin worry about?

Accepted Answer

Governor Limits are Salesforce's per-transaction caps that prevent any one user or job from monopolising the multi-tenant infrastructure. They apply uniformly to every transaction — flow, trigger, batch, anonymous Apex, integration call. The ones admins encounter most: - SOQL queries per transaction — 100. A flow with a Get Records inside a loop is the most common way to blow this. - DML statements per transaction — 150. Each Update/Create/Delete element in a flow counts. - Records processed per transaction — 10,000 for synchronous DML. Flows updating 10k+ rows in one go fail. - CPU time per transaction — 10,000 ms (10 seconds). Long flows with many decisions, complex formulas, or recursive subflows hit this. Heavy validation rules contribute too. - Heap size — 6 MB sync, 12 MB async. Loading 100,000 records into a flow collection variable can exceed this. - Email invocations per transaction — 10 single-recipient or 1 mass email. Send-Email actions in flows that loop over results blow it. - Async jobs queued per 24 hours — 250,000 by default. Heavy schedule-driven orgs near this limit. Beyond per-transaction: - Storage limits — data storage and file storage caps per edition. Not a

Question 49

How would you design "deal team" access where different roles get different permissions on the same record?

Accepted Answer

Concrete scenario: an Opportunity has a Deal Lead (full edit), a Deal Lawyer (read only — they need context but shouldn't change financials), and a Deal Sponsor (read/write on selected fields). All three should see the record; their write access should differ. Approach combines several Salesforce features: 1. Opportunity Team Members — the standard team mechanism on Opportunity. You add members with Opportunity Access of Read or Read/Write. This handles the simple Read vs Read/Write split for Deal Lead and Deal Sponsor. 2. Field-Level Security via Permission Set — to give the Lawyer read-only on the record but block edit on financial fields specifically, you'd put the Lawyer on a permission set with Read-only FLS on Amount, Discount, Close Date. The Opportunity Team grants record access; the FLS gates which fields they can edit. 3. Field-Level Security tightened on the Sponsor's profile/permission set — same principle but with edit access only on the fields the Sponsor should change. 4. Apex Managed Sharing or Sharing Set for non-team-supported objects. If the scenario was on a custom object that doesn't support Salesforce Teams, you'd use Apex Managed Sharing with a per role (Deal

Question 50

Walk me through migrating an org from Process Builder to Flow at scale.

Accepted Answer

Process Builder is being retired. Migrating to Flow is mandatory for any org with active processes. The approach: 1. Inventory. Run a full audit. Setup - Process Builder lists all processes per object. Export the list (object, name, status, last modified). For an enterprise org you may have hundreds. 2. Categorise. For each process: simple (single update, no async), medium (multiple actions, branching), complex (calls Apex, async paths, custom UI). Treat each category differently. 3. Use Migrate to Flow — Salesforce's built-in tool. From Setup - Process Builder, click Migrate to Flow on an individual process. It generates a Record-Triggered Flow equivalent. Output is a draft flow you review and clean up. The tool handles the simple cases well; complex ones need manual rework. 4. Decide on before-save vs after-save for each migrated flow. Field updates on the same record should be before-save (much faster). Anything that creates other records or calls Apex must be after-save . 5. Test in sandbox. Run the same trigger conditions through both the Process and the migrated Flow side-by-side. Compare outcomes. Common failure: subtle differences in null-handling between PB and Flow (PB tr

Question 51

What is a Report Type and why does it matter?

Accepted Answer

A Report Type defines which objects and fields are available when building a report. It's the schema lens — choose "Opportunities with Products" and you can report on those two related objects' fields together; choose "Opportunities" and Products' fields aren't accessible. Salesforce ships standard report types for every object and most relationships. Custom Report Types let you compose your own — pick a primary object, optionally add up to four related objects with A-with-B or A-with-or-without-B logic, choose which fields are available, and rename for clarity. The "with-or-without" join is what enables reports like "Accounts with or without Opportunities" — the equivalent of an outer join, which standard report types often can't express. Why it matters: - Report design starts here. If the right Report Type doesn't exist, your users can't build the report. - Performance — Custom Report Types let you remove unused fields from the picker, speeding up large reports. - Security — fields hidden via FLS still don't appear; report types layer on top of FLS, not under it. Common gotcha: changing field labels affects standard report types' display but not their underlying field reference,

Question 52

What is a Dashboard in Salesforce and what are its key components?

Accepted Answer

A Dashboard is a visual aggregation of one or more reports — charts, gauges, metrics, tables — assembled on a single canvas for at-a-glance consumption. Key components: - Source reports — every dashboard component is fed by a saved report. The dashboard caches the report's results and can refresh on a schedule or on demand. - Components — chart types include bar, column, line, donut, funnel, gauge, metric, and table. Each pulls from one source report. - Filters — dashboard filters let viewers slice all components together (by region, by stage, by date range). - Running User — the dashboard runs as a specific user's permissions. The default is "Run as logged-in user" (each viewer sees their own data) or "Run as me" (everyone sees the dashboard creator's data — useful for execs who need consolidated views). - Dynamic Dashboards — a paid feature where the running user can be the logged-in user, removing the need for one dashboard per role. Standard dashboards limit Dynamic ones to 5 per org (Enterprise). Dashboards live in folders with their own sharing, so dashboard access doesn't follow report access automatically — both must be granted.

Question 53

What is the difference between a Custom Button and a Custom Link?

Accepted Answer

Both let you add a clickable element to a record's UI but they perform different actions. A Custom Link opens a URL — that's it. The URL can include merge fields (e.g., ) so it's record-aware. Common uses: opening a third-party app prefilled with the record's data, jumping to a related document repository, opening Google Maps for an Address. A Custom Button does more. It can open a URL too, but also: - Execute JavaScript (in Salesforce Classic only — JavaScript Buttons are not supported in Lightning Experience). - Call a Visualforce page that performs server-side logic. - Be a list-view button — bulk action across selected records. - Open in a sidebar / new tab / replace current page . In Lightning Experience, Quick Actions have largely replaced Custom Buttons for declarative UI extensions — Quick Actions can launch flows, create records, send email, log calls, all without code. A team migrating from Classic to Lightning will need to convert most JavaScript Buttons to Flows or LWC actions. Custom Links and the URL-only flavour of Custom Buttons still work fine in Lightning. JavaScript Custom Buttons do not.

Question 54

What is a Tab in Salesforce and how do you make a custom one?

Accepted Answer

A Tab is a navigation entry inside an App — clicking it takes you to a list view, a Visualforce page, a Lightning component, or a Web Tab (an external URL embedded inline). Each Object you want users to navigate to via the nav bar needs a Tab. Types of tabs: - Standard Object Tabs — auto-created for standard objects like Accounts, Contacts. - Custom Object Tabs — created for each custom object you want navigable. Setup - Tabs - New Custom Object Tab. - Web Tabs — embed an external website inside the Salesforce frame. - Visualforce Tabs — display a Visualforce page. - Lightning Component Tabs — display a Lightning Web Component. - Lightning Page Tabs — display a Lightning App Page (a custom dashboard-style page). Creating one: pick the type, give it a label and tab style (icon + colour), choose default profile visibility (Default On / Default Off / Tab Hidden), and finally pick which Custom Apps include it. Permission to actually see a tab is controlled by Tab Settings on profiles and permission sets. A tab can be hidden by default but permitted via permission set, which is the recommended pattern. In Lightning Experience, tabs appear in the nav bar at the top of the app; users can

Question 55

What is a List View Chart and how does it differ from a Report?

Accepted Answer

A List View Chart is a small inline chart shown next to a list view — bar, donut, or line chart of records currently filtered in that list view. It's a Lightning Experience feature. Key differences from a regular Report: - No report needed — driven by the list view's filter directly. - Limited chart types — three basic forms. - No subscriptions, no scheduled refresh, no export — it's a presentation overlay, not a saved analytical artefact. - Single-object — can only chart fields on the list view's primary object. Use it when sales reps want a quick "Pipeline by Stage" pie next to their open opportunities list, without leaving the list. For anything beyond a glance — sharing, trending, multi-object analysis, exporting — build a proper report and dashboard component instead.

Question 56

What is the difference between Owner and Created By, and why does it matter?

Accepted Answer

Two distinct fields on every record: - Created By is set once, at insert. It records the user (and timestamp) that created the record. Cannot be changed afterwards through normal UI/API; only via Salesforce-internal data load operations. - Owner is the user (or queue) who currently owns the record. It can be reassigned manually, by assignment rule, by Apex, by transfer, or via mass action. Why it matters: - Sharing — the Owner is the user who naturally has access (with OWD = Private), and the user above them in the role hierarchy gets access too. Created By doesn't drive sharing. - Reports — "My Records" filters use Owner, not Created By. A rep who created a record but no longer owns it will not see it under "My". - Automation — assignment rules, sharing rules, and many record-triggered flows look at Owner, not Created By. - Auditability — for proving "who first entered this record", use Created By. For "who is responsible for this record now", use Owner. A common confusion: a sales manager creates a deal on behalf of a rep, sets the Owner to the rep — Created By stays as the manager, Owner is the rep, and now ownership-driven automation runs as if the rep created it. The Created B

Question 57

What are Web-to-Lead and Web-to-Case, and how do you set them up?

Accepted Answer

Both are out-of-the-box features that let an external website submit a form which creates a Lead or Case in Salesforce — no code required. Setup is similar: 1. Setup - Web-to-Lead (or Web-to-Case) - Generate the form HTML. 2. Pick the fields you want on the form. Salesforce generates HTML you paste into your website. The form posts to a Salesforce endpoint with your org ID, and on receipt Salesforce creates the record. 3. Optionally configure default values, response email, and assignment rules. Constraints to know: - 500 leads/cases per day for Web-to-Lead. Beyond that, submissions are queued or dropped (Web-to-Case is similar but its limit is generally higher and edition-dependent). - No CAPTCHA — form is openly accessible. Spammers find these forms quickly. Mitigations: hidden honeypot fields, third-party CAPTCHA in front of the form, throttling on your web server. - Validation Rules and triggers still fire on the created record. A failed validation rule sends an admin error email but doesn't show on the public form — the user sees a successful submission while you see a failed creation. Test this carefully. - Email-to-Case is the email-channel equivalent — emails sent to a desi

Question 58

What is a Person Account and what are its trade-offs?

Accepted Answer

A Person Account is a Salesforce data-modelling option where a single record represents both an Account and a Contact, useful when you sell directly to consumers (B2C) rather than to companies. Once enabled, you choose per-record-type whether a record is a Business Account (with related Contacts) or a Person Account (a person with no separating Contact). Trade-offs: Pros: - Cleaner B2C data model — one record per individual, no fake "Acme - John Smith" account names. - Many features that originally only worked on Account or Contact still work via the unified Person Account. Cons: - Irreversible. Once Person Accounts are enabled, you cannot turn them off. - Some features don't fully support them. Certain managed packages, integrations, and platform features assume Account-and-separate-Contact and break or behave oddly with Person Accounts. - Complicates data integrations — every integration must be aware that an Account record might be the Contact, with conditional field mappings. - Reporting — reports on Person Accounts often need both Account and Contact-level fields, requiring custom report types. - Data volume — Person Accounts double-count against both Account and Contact stora

Question 59

How do Report Folders and Folder Sharing work?

Accepted Answer

Reports and Dashboards live in Folders . Folders are independently shareable artefacts — you choose who can see, edit, or manage each folder, separately from the records the reports are about. Folder access levels: - Viewer — can run the report. - Editor — can run, modify, and save the report inside the folder. - Manager — can do everything an Editor can, plus delete reports, manage folder sharing, and rename the folder. Shared with: - Public Group, Role, Role and Subordinates, Role and Internal Subordinates — the usual options. - Specific Users — case-by-case. - All internal users — implicit "share with everyone in the org". Important: folder sharing controls who can run / modify the report , not what data the report shows . A user can be a Manager of a folder but still only see records they have sharing access to — the report respects the underlying sharing model. Two practical patterns: - One folder per team — Sales Reports, Service Reports, Finance Reports — shared with each team's public group. - Working folders for personal drafts — a "Personal" folder per user, plus shared "Production" folders for ratified reports. Promotes a draft-then-publish workflow. Common mistake: leav

Question 60

What is a Joined Report and when would you use one?

Accepted Answer

A Joined Report is a report format that lets you display data from up to five related blocks side by side, where each block can have a different report type. It's how you build "Open Opportunities and Closed Cases for the same Account, side by side" without exporting to Excel. Structure: - Each block is essentially its own report — own filters, own grouping, own summary fields. - Common groupings can be applied across all blocks (e.g., group everything by Account so you see all blocks aligned per account). - Cross-block formulas can reference values from different blocks — useful for ratios like "Closed Won Amount / Pipeline Amount". Use cases: - "Open Cases and Open Opportunities by Account" — Service and Sales views in one report. - "Pipeline this quarter vs Pipeline same quarter last year" — same object, different filters. - "Activities by rep, alongside that rep's open opportunities" — performance review data. Limitations: - Charts don't work the same — you can chart, but only on the principal block or on cross-block formulas; you can't chart all five blocks together. - Export to Excel is messier — joined reports export with each block in its own section. - Performance — five b

Question 61

How does Email-to-Case work and what's the setup process?

Accepted Answer

Email-to-Case turns inbound emails into Case records automatically, preserving sender, subject, body, and attachments. Two flavours: - On-Demand Email-to-Case — fully cloud-managed. You forward emails from your support address (e.g., support@company.com) to a Salesforce-generated routing address. Salesforce parses and creates the Case. No infrastructure. - Email-to-Case (relay agent) — for organisations that need emails to stay on-premise initially (compliance, no cloud forwarding allowed). Requires a Java agent installed on a company server that polls a mail folder and pushes cases to Salesforce via API. Setup (On-Demand): 1. Setup - Email-to-Case - Enable. 2. Enable On-Demand Service. 3. Create a Routing Address — pick the email address users send to (support@), specify which case fields are pre-populated (Origin, Owner, Priority defaults), and enable "Insert thread ID in email subject" so reply-tracking works. 4. Configure your mail server to forward inbound emails to the Salesforce-generated routing address. 5. Test end-to-end with a sample email. Common configuration: - Threading — Salesforce inserts a hidden thread ID into the case-update notification email so when the custom

Question 62

What is a Salesforce Knowledge article and how does it differ from a regular file?

Accepted Answer

Salesforce Knowledge is a structured knowledge base built into the platform. Articles are first-class records (not files) with: - Article types — categories of content (FAQ, How-To, Known Issue, Product Doc) defined by the admin. Each article type has its own fields and layout. - Versioning — articles have a draft/published lifecycle and version history. Edits create new draft versions; publishing replaces the live version. - Translations — articles support multiple language versions, with workflows to manage translation status. - Data Categories — taxonomy for organising articles (Product Module Feature). Used for filtering and access control. - Attached as related list — articles can be linked to Cases (so an agent searching while on a Case sees suggested articles), surfaced in the Service Console, and exposed in Experience Cloud sites. Differences from regular files: - Files are unstructured — uploaded documents, no schema, no versioning beyond manual. - Knowledge articles are structured records with workflow, translations, and reporting. Common admin tasks: - Define article types with the right fields per content category. - Build the Data Categories tree. - Configure article-t

Question 63

How does Campaign Influence work and how do you configure it?

Accepted Answer

Campaign Influence is the feature that attributes Opportunity revenue to one or more Campaigns that touched the deal. Without it, you only know who the opportunity's "Primary Campaign Source" was; with it, you can attribute fractional or full credit to multiple campaigns based on customisable rules. Two models: - Campaign Influence 1.0 (the original) — automatic if you enable it. When a contact role is added to an opportunity, all of that contact's recent campaign memberships within a configured timeframe are auto-attributed. Limited to a single attribution model and primarily useful for the legacy "first touch" view. - Customizable Campaign Influence (CCI) — modern. You define multiple attribution models (First Touch, Last Touch, Even, Custom), each with its own logic. Each opportunity gets a Campaign Influence record per (campaign, model) pair, with a percentage and currency value. Reports can then show pipeline by campaign by model. Configuration: 1. Enable CCI in Setup. 2. Define your attribution models — Salesforce ships First Touch, Last Touch, Even; you can add custom ones via Apex (or via packaged solutions like Salesforce Marketing Cloud Account Engagement / Pardot). 3. Co

Question 64

What is the difference between Assignment Rules and Escalation Rules?

Accepted Answer

Both are declarative rule engines on Lead/Case but they trigger at different times. Assignment Rules fire on record create (and optionally on edit, if the user opts in via "Assign using active assignment rule"). They evaluate criteria top-down and route the record to the first matching entry. The action: change the Owner (to a user or queue), and optionally send an email notification. Use Assignment Rules for: "When a Case is created with Severity = Critical, assign it to the Tier-3 queue and email the manager." Or "Lead from EMEA region routes to the EMEA queue, lead from APAC routes to the APAC queue, otherwise default queue." Escalation Rules fire based on time elapsed without resolution . You define entry criteria (e.g., Status = Open AND Priority = High) and time triggers (e.g., 30 minutes after creation, 2 hours, 4 hours). At each trigger, you can change the Owner, change the Priority, or notify users. Escalation rules implement SLA workflows. Use Escalation Rules for: "If a High-Priority Case is open for more than 30 minutes during business hours, reassign to a manager and email an alert. If still open at 2 hours, escalate to the executive team." Key differences: - Trigger :

Salesforce Administrator interview questions

Top 10 must-know

All 100 questions

Easy

Medium

Hard

Top 10 must-know

1What is the difference between a Profile and a Permission Set?easy

2What is the difference between a Lookup and a Master-Detail relationship?easy

3Walk me through the Salesforce sharing model from most to least restrictive.medium

4What is the difference between a Profile and a Role?medium

5When would you use a Validation Rule instead of marking a field as Required?medium

6Workflow Rules, Process Builder, Flow — which one would you use today and why?medium

7How do Field-Level Security and Page Layouts each control field visibility, and which wins?medium

8Walk me through the trade-offs of Public Read/Write vs Public Read Only vs Private Org-Wide Defaults.hard

9Walk me through Salesforce's Order of Execution when a record is saved.hard

10What are Salesforce's Governor Limits and which ones should an admin worry about?hard

All 100 questions

Easy

What does a Salesforce Administrator actually do day-to-day?easy

What is the difference between a Profile and a Permission Set?easy

What is an Object in Salesforce, and what kinds are there?easy

What is the difference between a Standard Field and a Custom Field?easy

What is a Record Type and when would you use one?easy

What is a Sandbox and what types are available?easy

What is a Page Layout and how does it differ from a Lightning Record Page?easy

What is the difference between a Lookup and a Master-Detail relationship?easy

What is a Custom App in Salesforce, and how is it different from a Connected App?easy

What is a List View and what are the visibility scopes?easy

What is the difference between a Quick Action and a Global Action?easy

What is the difference between Deactivating and Freezing a user, and when would you use each?easy

What is MFA in Salesforce, is it required, and how do you implement it?easy

What is a Permission Set License and how does it differ from a Permission Set?easy

What is My Domain in Salesforce and why does it matter?easy

What is the AppExchange and what should an admin know before installing a package?easy

What is a Report Type and why does it matter?easy

What is a Dashboard in Salesforce and what are its key components?easy

What is the difference between a Custom Button and a Custom Link?easy

What is a Tab in Salesforce and how do you make a custom one?easy

What is a List View Chart and how does it differ from a Report?easy

What is the difference between Owner and Created By, and why does it matter?easy

What are Web-to-Lead and Web-to-Case, and how do you set them up?easy

What is a Person Account and what are its trade-offs?easy

What is the Setup Audit Trail and what does it capture?easy

What is Login History and what does it tell you?easy

What is the difference between a Task and an Event in Salesforce?easy

What is the difference between Files, Attachments, and Content?easy

What is the Translation Workbench and when do you use it?easy

What is Health Check and how should an admin use it?easy

What is a Named Credential and why use it instead of a Remote Site Setting?easy

Medium

Walk me through the Salesforce sharing model from most to least restrictive.medium

What is the difference between a Profile and a Role?medium

When would you use a Validation Rule instead of marking a field as Required?medium

Workflow Rules, Process Builder, Flow — which one would you use today and why?medium

How do Field-Level Security and Page Layouts each control field visibility, and which wins?medium

When would you use a Permission Set Group instead of individual Permission Sets?medium

When would you use a Public Group versus a Queue?medium

How does Field History Tracking work, and what are its limits?medium

How would you mass-update 50,000 records — and what would you check first?medium

What is the difference between a Standard and Custom Profile?medium

How do Duplicate Rules and Matching Rules work together?medium

How do you organise email templates for multiple teams and brands?medium

What is the difference between a Picklist, a Multi-Select Picklist, and a Picklist Value Set?medium

What is a Login Flow and when would you use one?medium

When would you use Custom Settings vs Custom Metadata Types?medium

What is an Auto-Number field and what should an admin watch out for?medium

How does the Salesforce Mobile App differ from Lightning Experience on desktop?medium

Can you build a Roll-Up Summary on a Lookup relationship? If not, what are the alternatives?medium

How do Report Folders and Folder Sharing work?medium

What is a Joined Report and when would you use one?medium

How does Email-to-Case work and what's the setup process?medium

What is a Salesforce Knowledge article and how does it differ from a regular file?medium

How does Campaign Influence work and how do you configure it?medium

What is the difference between Assignment Rules and Escalation Rules?medium

What is the difference between View All Data, View All on Object, Modify All Data, and Modify All on Object?medium

What is Dynamic Forms and how does it differ from a Page Layout?medium

How would you architect Reports access for sensitive data like financial or HR fields?medium

How do Opportunity Stage, Forecast Category, and Probability relate?medium

What is Sales Path and how do you configure it?medium

What is a Reporting Snapshot and when would you use one?medium

How does Salesforce track API call usage and what are the limits?medium

What is Sales Engagement (formerly High-Velocity Sales) and what's a Cadence?medium

What is Einstein Activity Capture and what are its trade-offs?medium

What is a Big Object and when would you use one?medium

How does Salesforce Files actually work under the hood?medium