Who Sees What?
What setting controls the baseline visibility of Contact records in your org?
What is Organization-Wide Defaults (OWD)? OWD is the most restrictive baseline setting. In your org, Contact and Case OWD is set to Private, which means users can only see these records if they own them or if sharing rules explicitly allow access.
Name the top-level role in your org’s hierarchy for internal visibility.
Harvard Medical School. Under HMS, you have the “Integration Users” and “Internal Users” roles. This structure doesn’t control access directly (due to OWD = Private), but it's used to organize users and determine sharing rule targets via “Role and Subordinates.”
There are two main types of sharing rules in Salesforce. What are they? Bonus points, if you can share how they are different?
What are Owner-Based and Criteria-Based Sharing Rules?
Owner-Based Sharing Rule: Shares records based on who owns them (e.g., share all Contacts owned by users in Role A with users in Role B). Often used when team assignments are consistent by user groups.
Criteria-Based Sharing Rule: Shares records based on field values (e.g., Record Type = Harvard Contact AND hud_PRIVACY_VALUE = 4 or 5). Ideal for when access depends on business rules or data-sensitive conditions.
In your org, what grants baseline object access?
A minimal user profile is assigned to all internal users
A user can access the Contact record but cannot see the GPA field. It is visible in the page layout. What’s the most likely reason?
✅ What is Field-Level Security (FLS)? Regardless of whether a field is on the page layout, the user won’t see it unless they have Read (or Edit) permission through their profile or permission set.
A Contact record is Private by OWD, but some users see specific records based on certain record types and field values. Why?
Because a Criteria-Based Sharing Rule has been configured. Your existing Contact sharing rules allow users in Internal and Integration roles to see records based on conditions like: (RecordType = Harvard Contact) AND (Privacy = 4 or 5).
True or False: Internal Users will automatically see records owned by Integration Users because they are in the same role hierarchy branch.
What is False? Role hierarchy access only applies when one role is above another. Since Internal and Integration Users are sibling roles under HMS, no access is inherited between them.
This sharing rule shares External Contact records with Internal User role. What’s the logic?
The rule likely includes criteria: RecordType = External Contact.
How many profiles can a Salesforce user have? And how many permission sets?
A user can have only 1 profile. However, a user can be assigned multiple permission sets, allowing greater flexibility.
True or False: Field-Level Security can block access even if the user has full object permission.
What is True. A user with full object access (e.g., Read/Edit on Contact) could still be blocked from seeing or editing specific fields due to FLS rules in the permission set or profile.
True/False – Role Hierarchy alone allows Internal Users to see Contacts they do not own.
What is False. If the OWD for a standard or custom object is set to Private, then users do not automatically get access to records owned by subordinates unless “Grant Access Using Hierarchies” is enabled (and only for certain standard objects). In your org, Contact OWD is Private, so role hierarchy doesn’t auto-extend access.
Record access in your org is mostly based on specific criteria like record type and privacy level. What feature enforces this?
What is Criteria-Based Sharing Rules? Your org uses logic like “Record Type = Harvard Contact AND hud_PRIVACY_VALUE = 4 or 5” to grant access to specific roles without relying on hierarchy.
What does “Role: Internal and Portal Subordinates” mean when used in a sharing rule target?
The rule opens access to all users who are in the specified role (Internal) and any roles beneath them
What is the advantage of using permission sets over creating multiple profiles?
Flexibility. Permission sets allow modular access control without creating dozens of profiles. You assign “just enough access” and can add or remove functionality based on job functions or projects.
Where do you configure field-level access in your permission model?
What is in the “Object Settings” section of a Permission Set. Navigate to Setup → Permission Sets → [Set Name] → Object Settings → Contacts → Field Permissions to configure visibility at the field level.
What Salesforce feature allows you to analyze why a certain user has access to a record even if they don’t own it?
The “Sharing Button” on a record detail page. This lets you check who has access, and why—like via a sharing rule or role hierarchy.
If a user owns a record and another user is in the same role, will they automatically get access to it via hierarchy?
What is No? Users in the same role do not share access via hierarchy, even if “Grant Access Using Hierarchies” is enabled. Record ownership and sharing rules still control access.
A user in the "Internal User" role reports that they can’t see a Contact they believe they should have access. What are the possible reasons they can’t see the record — even though a sharing rule should apply?
What is: There are a few possible causes —
You want to restrict access to a custom button that launches a Flow for approving a student's course exception. Only certain advisors should see and use it. What Salesforce feature allows you to gate access this way without using sharing rules or object permissions?
What is a Custom Permission?
A Custom Permission is a developer/admin-defined security check that can be referenced in Flows, Apex code, or component visibility filters. You assign the permission using a Permission Set, and only users with it will see or trigger that functionality. It works alongside object/field permissions to control access to features or business logic — not data.
An internal staff user can’t see the "Student GPA" field on a Contact record. It’s confirmed that the field is on the page layout and the user has Read access to the Contact object. How do you confirm whether field-level security is the issue?
What is: Use the "View Field Accessibility" tool in Setup. This tool shows whether the field is visible, read-only, or hidden for each profile assigned to users — helping confirm if FLS is what’s blocking access.
A user has read-only access to Contacts with hud_PRIVACY_VALUE = 4 or 5. What two elements must be in place to grant this?
(1) A criteria-based sharing rule targeting record types and privacy field values; and (2) a permission set giving the user Read access to the Contact object itself. Both conditions must be met: one controls visibility (allows a record to be seen by a user), the other controls access level (CRUD) (determines what actions a user can take once they can see the record).
Your org has “Grant Access Using Hierarchies” enabled, but record access between Internal and Integration Users is still blocked. Name two reasons why this is happening.
What are:
The Internal and Integration Users are in sibling roles, not a parent-child hierarchy. Role hierarchy only grants access when one role is positioned above another in the hierarchy tree.
OWD for the object (e.g., Contact) is set to Private, and no manual sharing or sharing rule exists to allow access. With Private OWD, access must be explicitly granted — hierarchy inheritance only works between users in properly aligned roles.
Can integration users access Contacts without sharing rules? What else must be configured?
No. Even if the sharing rule allows visibility, Integration Users must also have the correct permission set granting Read (or Read/Edit) access to the Contact object. Sharing rules determine who can access records, but permission sets determine what a user can do with them.
You built a screen Flow that lets advisors submit updates to sensitive student demographic fields. All advisors have permission sets with full access to the Contact object. The Flow is embedded on a Lightning page, but now it's visible to all users — including those who shouldn't run it. What security feature should you implement to restrict access to only specific advisors, and where should it be applied?
What is: A Custom Permission, used either in the Lightning component visibility filter or inside the Flow logic.
A faculty advisor previously had access to view “SSN” and “GPA” fields on student Contact records but can no longer see them. The Contact records are still visible, and the user still has the correct role, page layout, and object-level access. “SSN” and "GPA" are Read-only fields in a permission set that was added to a permission set group. What advanced FLS-related issue could be causing this, and how would you troubleshoot and fix it?
What is: The permission set granting field-level access may have been removed from the permission set group, deactivated, or overridden by another permission set with more restrictive access.
To troubleshoot:
Use the “View Field Accessibility” tool to verify if those fields (SSN, GPA) are hidden for that user’s profile.
Go to the user’s assigned Permission Set Group and inspect all included permission sets. Check if the permission set including Read access to SSN and GPA is still:
Use the user’s "Permission Set Assignments" view to confirm if any recent changes removed individual permission sets or altered the group composition.