Salesforce admin interview questions and answers

A queue holds records nobody has picked up yet, and it owns them — the OwnerId points at the queue rather than a person. Members can see what is in it and take a record, which sets them as the owner. It is the right shape for incoming work: leads, cases, anything where the team decides who takes what rather than an individual being assigned up front.

The important part is that a queue is an owner. That means anything keyed on ownership behaves differently while a record sits in one — the role hierarchy grants nothing, because a queue has no place in it, so visibility comes from queue membership instead. Members can be users, roles, public groups or partner users, and adding a role adds everyone in it, which is where a queue quietly becomes visible to more people than intended. Two practical notes: assignment rules are usually what puts records in a queue rather than a person doing it, and reports on ownership will show the queue's name in Owner.Name, which surprises whoever built the report on the assumption owners are people.

A profile says what you can do — which objects and fields you can read and edit, which apps and tabs you see. A role says whose records you can see, through the hierarchy: someone above me in the role hierarchy can see my records. So a user with a wide profile and no role can act on plenty of objects and still see almost no records, and that combination confuses people.

Two independent axes: the profile governs permissions, the role governs record visibility through the hierarchy. Keeping them separate is what makes a permission problem diagnosable — if two users with the same profile see different records, it is not the profile. Two details worth knowing. A role is optional, and a user without one sits outside the hierarchy entirely, so nobody inherits their records; that is occasionally deliberate and more often an oversight. And Grant Access Using Hierarchies is per object and off for some standard objects, so "my manager can see my records" is not automatically true — it depends which object you are talking about.

Login history first, because it records the attempt and the reason. Same profile working for a colleague in the office and failing for someone abroad points at login IP ranges on the profile, or login hours if the time difference is large. Those both show up as a restricted login in the history. I would only reset the password if the history actually says the credentials were wrong.

The report already contains the answer if you read it as a comparison: the profile works in the office and fails abroad, so it is something location-dependent rather than something about the user. Login IP ranges on the profile are the usual cause, with login hours second when the traveller is many hours off. Login history confirms which: LoginHistory records the attempt with a restricted-login status rather than a bad password. The fix depends on policy — widening the range for a whole profile to help one traveller is a security change, so the narrower options are a temporary permission set or getting them onto the corporate network. Worth checking whether the account is frozen rather than deactivated too, because those look identical to the user and are unwound differently.

The Import Wizard for small, supervised loads on the objects it supports — up to 50,000 records, with built-in duplicate matching, and no delete. Data Loader for everything else: all objects, up to 5,000,000 records, insert, update, upsert, delete and hard delete, and the Bulk API option for volume. The rule of thumb is that the wizard is for a person doing a one-off and Data Loader is for anything repeatable or large.

Both trigger the org's automation, and that is the part worth stating before the feature comparison. A 200,000 row Data Loader update fires every trigger, flow and validation rule on the object, so the load's real cost is the automation's cost multiplied by the row count, and the failure modes are limit errors and UNABLE_TO_LOCK_ROW rather than anything about the tool. That is why sorting the file by parent Id and choosing serial mode for skewed data are load decisions rather than tuning. Beyond that, the choices I actually make: upsert on an external id rather than insert, so a rerun does not duplicate; batch size dropped from the default when the object has heavy automation, because a smaller batch is slower and survives; and the success and error files kept, since the error file is the only record of what did not happen. Hard delete is the one I treat with real care — it bypasses the recycle bin, so there is no undo, and the reason to use it is storage rather than convenience.

All three symptoms follow from one deletion, which is the useful thing to establish first. A sharing rule that targeted the deleted role now targets nothing, so it grants nothing; the managers lost their team's records because the hierarchy path changed when their reports moved; and the dashboard is almost certainly running as a user whose visibility changed. So I would find every sharing rule, report and dashboard referencing the old UserRole, point them at the surviving one, and check the users landed in the right place in the hierarchy.

One cause, three symptoms, and I would say that out loud before fixing anything, because it changes the plan from three tickets to one review. The concrete work is an inventory: sharing rules referencing the deleted role, public groups that contained it, dashboards and reports with a running user or role filter, and any queue whose membership was defined by that role. Each of those holds a UserRoleId that no longer resolves, which is a broken reference rather than a broken feature. What I would not do is recreate the role — the new record has a new Id, so the old references stay broken while looking plausible, which is the worst of both outcomes. Beyond the fix, the finding is that a role deletion has no dependency check in front of it: the platform will happily remove something a dozen artefacts point at. So the process change is that role changes go through the same review as a schema change, with the inventory taken first, and ideally the sharing recalculation scheduled rather than dropped into a Friday afternoon.

A matching rule defines what counts as the same record — fuzzy on Company, exact on Email — and a duplicate rule decides what happens when one matches: warn and allow, or block. I start with warn, because blocking on a matching rule nobody has tuned generates false positives, and a false positive stops a salesperson entering a real customer. Once the rule has run in alert mode for a while and the matches look right, blocking becomes reasonable.

The decision is about which error is more expensive in this org, and it differs by object. A blocked lead that was genuinely new costs a conversation and possibly a deal; a duplicate account that gets through costs reporting accuracy and two people working the same customer. So I would rather tune the matching rule in alert mode first and read the real match volume than guess at a threshold. Two things people find out late. Duplicate rules apply on save, so a rule switched on today prevents new duplicates and does nothing about the 40,000 already there — cleaning those up is a separate exercise with merges rather than a rule. And a rule that blocks will block an integration too, which turns a data-quality control into a nightly job failure unless somebody decided that deliberately. The version I have seen work is blocking in the UI where a human can read the message and alerting for the API, with the API duplicates routed somewhere a person reviews.

Required at the field level holds everywhere — the UI, the API, Data Loader, a flow. Required on a page layout is a UI-only rule, so an integration or a data load walks straight past it, which is why it is the wrong place for anything that matters. A validation rule is the conditional option: it can say a field is required only when StageName is Closed Won, and it applies on every save path including the API. So field-level for always, validation rule for sometimes, and page layout for guiding a user rather than enforcing anything.

Where the enforcement lives decides whether an integration can violate it, and that is the question I ask first. Field-level required and validation rules both apply to the API; layout requirements do not. Beyond that, the save order matters more than people expect: custom validation rules run after before-save flows and before triggers, so a before trigger writing to Trigger.new has already had its chance to populate a field by the time the rule is evaluated — which is both a useful pattern and a trap, because a rule that looks like it should fail passes thanks to a flow the author had not read. The other thing I weigh is who gets the error. A validation rule's message lands in front of a user, or in an integration's error log where nobody reads it, so anything a system writes to needs its rule paired with a decision about what the integration does with the rejection. And a required field added to an object with existing data will block the next edit of every record that is missing it, which is a data project disguised as a checkbox.

Developer sandboxes for building, because they refresh daily and carry no data — 200 MB and configuration only. Developer Pro for the same job with more room at 1 GB, which matters when you need a working data set. Partial Copy for testing with a sample of real data, 5 GB and a 5 day refresh interval. Full for anything that has to behave like production — performance testing, a migration rehearsal, user acceptance testing — with production's data volume and a 29 day refresh interval.

The refresh interval is what actually constrains a plan, more than the storage. A Full sandbox at 29 days means you get roughly one clean production-shaped environment a month, so a release calendar has to be built around that rather than assuming a refresh is available on demand — and a Full sandbox that has not been refreshed for six months is drifting from production in exactly the ways that break a deployment. Developer sandboxes refreshing daily is what makes them the right place for experiments you expect to throw away. The judgement call is where performance and volume testing happens, because the honest answer is only Full, and orgs frequently discover a query is non-selective in production after testing it against a Partial Copy with a tenth of the rows. I would also plan the data seeding: a Partial Copy takes a sample, so referential integrity across objects is not guaranteed and the test data has to be checked rather than assumed.

Reassign before deactivating, not after. The 4,000 records go first — a mass transfer to whoever is covering, or to a queue if nobody is yet — then the dashboards get a new running user, the sharing rules get updated, and the flow error recipients get pointed at a distribution address rather than a person. Only then does the user get deactivated, and freezing them on Friday while the reassignment finishes is a safer intermediate step than deactivating.

The order matters more than any individual step, and freezing is the tool people forget: freezing blocks their access immediately without releasing the licence or orphaning anything, so Friday's security requirement and the reassignment work stop competing. Then the inventory, and this setup is a good example of how long it is — 4,000 records to transfer, two dashboards whose running user determines what everybody sees, three sharing rules naming them, and four flows whose failures will go to a mailbox nobody reads. Each of those breaks differently and none of them raises an alert. I would also check for anything scheduled or integrated under their credentials, because a scheduled job owned by a departed user is the classic quiet failure, and it will not surface for weeks. The reassignment itself is a business decision I would not make alone: 4,000 records to one person is a workload, and splitting by territory is usually what is actually wanted. Then deactivate, and keep the record of what was moved where, because somebody will ask in three months why an old opportunity has a new owner.

Version control first, before any tooling. Getting the metadata into a repository means changes are reviewable and a rollback is possible, and it does not require anybody to adopt a new deployment process on day one. After that, automated validation against production, which sf project deploy validate does without releasing anything — a validation-only deployment run on a schedule catches drift and failing tests before release day, which is where most change set pain actually shows up.

The pain from change sets is rarely the clicking; it is that nobody can say what is in the org or reverse a change. So the first move is source control, because it fixes the auditability and the rollback story without asking anybody to change how they deploy. The second is a scheduled validation deployment against production, which turns release-day surprises into Tuesday-morning findings — a failing test or a missing field shows up while there is time, typically 48 hours before anybody is waiting on it. Only then would I look at deployment tooling, and by that point the case makes itself with evidence rather than principle. The thing I would deliberately not do first is unlocked packages. They are the right long-term shape and the migration is substantial, and starting there in an org that has no version control means a large project with no early win, which is how these efforts get cancelled. And I would be honest that some metadata will still need manual steps whatever we build — a few types do not deploy cleanly, and pretending otherwise makes the pipeline look broken when it is behaving as documented.

Both are right, for their own access. A report shows the records the person running it can see, so with Opportunity private and the two users at different levels of the role hierarchy the director sees a superset. That is the model working, and the 1,940,000 gap is the size of the director's extra branch of the hierarchy. What I would check next is whether they mean to be comparing the same thing at all, because if the manager needs to see the whole pipeline then this is a sharing question, and if the director wants the manager's number then the report needs a role scope so both see the same subset.

Neither is broken, which is the first thing to say plainly, because "the report is wrong" sends people looking in the wrong place. A report is a view through the running user's record access, so a 1,940,000 difference between a manager and a director on a private object is the sharing model behaving exactly as designed. Then I would establish which number the business actually needs, because that determines the fix. If everyone should see the same total, the answer is a dashboard with a fixed running user, so the number is stable regardless of who opens it — and that has an access consequence worth stating, since it shows people data they cannot reach in a list view. If they should each see their own scope, then the report is correct and the conversation is about labelling it so nobody compares two different scopes again. Two other causes worth ruling out before settling on sharing: multi-currency, where two users in different corporate currencies see converted totals, and a date filter interpreted in each user's own time zone, which moves records in and out at the boundaries. Both produce smaller differences than this, and both have caused the same argument.

I would find out what runs rather than what exists. Counting CODE_UNIT_STARTED entries in a debug log from one real save shows which automation fires on the busiest objects, and login and report usage data shows what people use. Alongside that, the risk inventory: who has administrative permissions, which integrations exist and what they connect to, and whether anything is scheduled that nobody owns. Those two lists are worth more than a full metadata catalogue.

A complete map is a trap — it takes a month, it is out of date when it is finished, and it answers questions nobody asked. So I would aim at two things I can produce in a fortnight and keep using. First, the risk register: administrative permissions and who has them, integration users and what they can reach, scheduled jobs and their owners, and anything running as a person who has left. That is where an incident comes from, and it is a short list. Second, the automation picture on the three objects the business actually runs on — which triggers and flows fire on a save, in what order, and which of them are unordered. A debug log from one real save tells me more than reading 40 flow definitions. Along the way I would write down what I could not explain rather than skipping it, because that list is the handover I wish I had been given, and it is the thing that keeps somebody from deleting an integration that turns out to matter. What I would resist is changing anything in the first fortnight beyond genuine security findings, because I do not yet know what depends on what.