12 Salesforce Admin Interview Questions on Profiles, Permission Sets, and Access

Strong answer

Usually no. Every user needs one profile, which is useful for default settings such as assigned apps, default record types, page layouts, login hours, and login IP ranges. For additive object, field, user, custom, Apex class, or connected-app access, I prefer a focused permission set.

I would name the permission set for the business task—for example, Opportunity_Discount_Editor—and include only the permissions needed for that task. This avoids creating nearly identical profiles and makes the grant easier to assign, audit, deploy, and remove.

I would clone or create a profile only when the required baseline settings cannot be modeled through permission sets, or when a distinct user-license or default-setting boundary genuinely requires it. “We have another department” is not enough by itself.

Strong answer

I design permission sets as reusable, task-based building blocks, not as one-off containers named after individual users. Examples include “Export Approved Reports,” “Edit Opportunity Discounts,” or “Run Renewal Automation.” A permission set group can then assemble those building blocks for a job function such as Sales Operations Analyst.

This design keeps the reason for each grant visible. It also reduces permission sprawl: when the task changes, I update one scoped building block instead of finding the same permission copied across several persona-specific sets.

The trade-off is that permission sets must be small enough to reuse but not so fragmented that administrators cannot understand the resulting access. I document the owner, business purpose, sensitive permissions, required license, and removal rule for every set.

Strong answer

No. Profiles, permission sets, and permission set groups grant access; they do not create a global deny that overrides another grant. If a user receives a permission from any applicable profile, permission set, or permission set group, leaving it unchecked somewhere else does not remove it.

To revoke access, I identify every source granting the permission and remove or redesign those grants. For a sustainable model, I keep the profile baseline narrow and add capabilities through permission sets. That makes revocation much easier than untangling a powerful profile later.

I would also clarify whether the reported problem is record access. Removing Read from one permission set does not matter if another assignment still grants object read, and removing object Edit does not explain why a user can view a particular record. Effective access is additive and layered.

Strong answer

Object permission answers whether the user can read records of that object at all. Record access answers which individual records the user can read. After confirming object Read, I inspect organization-wide defaults, ownership, role hierarchy, sharing rules, teams, territories, manual sharing, and any relevant restriction rules.

Field-level security is a third layer. A user may open the record but still be unable to see or edit a particular field. Page layouts affect presentation and edit experience; they are not a replacement for object, field, or record security.

My interview answer would name the failing layer before choosing the fix. I would not grant View All merely to make one record visible, because that bypasses the intended record-sharing design.

Strong answer

I use a permission set group to bundle reusable task-based permission sets for a job function. For example, a Sales Operations Analyst group could include report management, opportunity data maintenance, and approved data-import permissions. Assigning the group makes the persona easier to provision and review without duplicating the underlying permissions.

I keep the individual permission sets meaningful outside the group and avoid placing unrelated high-risk administration powers into a broad persona. I also check the group’s calculation status after changes. The effective combined permissions are updated asynchronously, so a successful metadata deployment does not by itself prove that users already have the new calculated result.

Strong answer

A muting permission set suppresses selected permissions from one permission set group’s calculated access. It is useful when a shared building block contains a capability that one persona should not receive, and creating a nearly identical copy would add maintenance debt.

The important limitation is scope. Muting affects only the related permission set group. If the same permission is granted through the user’s profile, a direct permission-set assignment, or another group, the user still has it. I would never say “muted means denied everywhere.”

I use muting selectively. If a group requires many exceptions, that usually signals poor composition and I would redesign the underlying permission sets instead of building a difficult-to-audit web of mutes.

Strong answer

I check license compatibility before changing the permission set. A user’s license defines the functionality they are entitled to use. Some features also require a permission set license. The permission set then grants a subset of the permissions made available by those licenses.

If the user does not have a compatible user license or required permission set license, Salesforce can reject the assignment. I review the user’s license, the permission set’s License field, Permission Set License Assignments, available license counts, and any package or product prerequisites.

I would not “fix” the error by copying permissions into an unlicensed set. That can fail again or create a misleading configuration. Entitlement and permission are separate controls, and both must be correct.

Strong answer

Page layouts control how a record page is presented. They do not secure a field across reports, list views, search, API access, related lists, or other interfaces. I would inspect field-level security from the user’s profile, permission sets, and permission set groups.

If the user must not read the field anywhere, remove every grant of field Read. If the user may read but not change it, keep Read and remove Edit. Then test the effective access using a representative least-privileged user in all relevant channels, not only on the record page.

I would also check whether formulas, reports, integrations, or Apex expose the sensitive value indirectly. Securing the page layout alone gives a false sense of protection.

Strong answer

I start on the user’s detail page in Setup and open View Summary. User Access Summary consolidates key assigned permissions and tabs. For the unexpected object, field, or user permission, I use Access Granted By to trace the profile, permission set, or permission set group supplying it.

Then I decide whether the assignment is wrong or the shared access component is too broad. Removing a user from the wrong group has a smaller blast radius than editing a permission set assigned to hundreds of users. If I change a shared component, I identify every affected assignment and include them in the test plan.

Finally, I check record sharing separately. User Access Summary helps with permissions and assignments, but effective record visibility can also come from ownership, hierarchy, groups, sharing rules, teams, territories, or manual sharing.

Strong answer

I inspect the permission set group status. Changes to included permission sets trigger an asynchronous recalculation of the group’s combined permissions. While the group is Outdated or Updating, assigned users continue with the permissions from the last completed calculation. If the status is Failed, the new result is not available.

I wait for recalculation, review the recently changed component, verify license and managed-package dependencies, and use manual recalculation when appropriate. I do not repeatedly edit assignments while the group is still calculating, and I do not claim deployment success until the status is Updated and a representative user test passes.

For a production change, the runbook should include the expected groups, their post-deployment status, the tested persona, and the specific action the user can now perform.

Strong answer

I create or reuse the smallest task-based permission set or group, obtain the required approval, and assign it with an expiration date. I verify the exact expiry date, time zone, and any permissions that make an expiring assignment ineligible. I also record the business owner and reason for the temporary grant.

The access still needs a complete design. If the task requires editing Opportunities, the user needs compatible licensing, object and field permissions, and access to the relevant records. A permission-set expiration removes only what that assignment granted; it does not remove equivalent access coming from another source.

Before the project ends, I test the approved task. After expiration, I confirm both that the assignment is gone and that the formerly allowed action is no longer possible. That second check catches duplicate grants.

Strong answer

I begin with governed user attributes and a written mapping from job criteria to access. Where the edition and use case support it, User Access Policies can grant or revoke permission set licenses, permission sets, permission set groups, package licenses, queues, and public-group membership for matching users.

The biggest risk is automating bad criteria. Department, role, worker type, or custom entitlement fields must have clear owners, validation, and restricted edit access. I test both sides of every transition: the new access is granted when criteria become true, and old access is revoked when criteria stop being true.

For joiners, movers, and leavers, I monitor policy results, exceptions, license exhaustion, and stale assignments. A mover test must cover simultaneous removal and addition; otherwise a user can accumulate permissions from every role they have held.