If you’re preparing for a Salesforce interview, one area you cannot afford to overlook is “Salesforce Security and Sharing” . Whether you’re aiming for any opportunity in salesforce domain.

At Salesforcehours , we understand the importance of real-world readiness. In this blog, we’ll walk you through must know security concepts and scenario-based questions that are frequently asked in Salesforce interviews. These insights will help you confidently answer questions related to access control, data privacy, and sharing rules ensuring you’re well-prepared to showcase your expertise.

Let’s dive into the world of Salesforce security and get you one step closer to acing that interview!

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

A Profile is the foundation of a user’s access in Salesforce, and every user must have exactly one. It defines a user’s baseline permissions, including what they can do with objects (Create, Read, Edit, Delete), their field-level security (FLS), assigned apps, tab visibility, and system permissions.
It should represent a user’s primary job function (e.g., “Sales User,” “Support Agent”).

Whereas ,A Permission Set is a collection of settings and permissions used to grant additional access to users. It is purely additive and can only grant permissions, never restrict them. A user can have many Permission Sets or none at all. They are the best practice for granting specialized permissions to a subset of users without creating new profiles.

Example: You have a “Sales User” Profile that doesn’t allow “Export Reports.” Instead of creating a whole new profile for managers, you create a Permission Set named “Report Export Access” and assign it only to the managers who need it.

2. How would you protect sensitive fields (like SSN or Salary) from being exported via reports by users who have object-level access?

This requires a multi-layered approach because object-level access does not grant field-level access.

1. Field-Level Security (FLS): This is the primary and most effective control. For all Profiles and Permission Sets that should not see the sensitive data, I would set the FLS for those fields to “No Access” (Hidden). If a user’s FLS prevents them from seeing a field, they cannot include it in a report, view it on a record, or export it.
2. Shield Platform Encryption: For the highest level of security, I would use Shield Platform Encryption to encrypt the data at rest. Access to view the decrypted data is then controlled by the “View Encrypted Data” permission. A user with object access but without this specific permission will only see masked values in reports and on the record itself.
3. Transaction Security Policies (Advanced): As a preventative control, I could implement a Transaction Security Policy. This could intercept a ReportEvent in real-time and block any report export that contains the sensitive fields, providing an active defense against data exfiltration.

3. What is the difference between “View All,” “Modify All,” “View All Data,” and “Modify All Data”?

These are distinct permissions with significant differences:

• “View All” / “Modify All”: These are object-specific permissions granted via Profile or Permission Set.
  • View All on an object allows a user to see all records of that object, regardless of sharing rules or OWD.
  • Modify All on an object allows a user to view, edit, and delete all records of that object, regardless of sharing rules.
    
• “View All Data” / “Modify All Data”: These are powerful system-level permissions. They apply to the entire organization.
  • View All Data allows a user to see all data in the org, overriding the sharing model for every object.
  • Modify All Data is the ultimate “super user” permission. It allows a user to view, edit, and delete all data in the org and change most system settings. It should be granted with extreme caution.

4. Scenario : A QA user is unable to edit a field on a Case record even though their profile has edit access. How would you investigate?

When a user can edit an object but not a specific field, the issue is almost always at the field or page level. My investigation checklist would be:

1. Field-Level Security (FLS): First, I’d check the user’s Profile and all assigned Permission Sets. A Permission Set could be overriding the Profile’s FLS, or the Profile FLS itself might be set to Read-Only for that field. The most restrictive setting between Profile and Permission Sets for FLS does not apply; permissions are additive. However, I need to check all sources.
2. Page Layout Properties: On the assigned Case Page Layout for the specific record type, the field might be set as Read-Only. This property overrides FLS and will prevent editing directly from the UI.
3. Field Properties on the Object: The field itself might be a formula field, a roll-up summary field, or an auto-number field, which are not editable by nature.
4. Validation Rules: A validation rule could be firing upon the user trying to save, making it appear as if the field is not editable when in fact the save action is failing. I would check the org’s active validation rules on the Case object.
5. Record-Level Access: As a final check, I’d confirm the user has ‘Write’ access to the specific record itself through ownership or sharing rules. An edit on a field requires edit access to the entire record.

5. Scenerio : You need to ensure that Sales users can’t delete records, but Marketing users can, even though both use the same object. What’s your approach?

This is a classic use case for separating permissions using Profiles and Permission Sets.

1. Establish a Baseline Profile: I would create a base Profile, for example, “Standard Business User,” that has Create, Read, and Edit permissions on the object, but not Delete. I would assign both Sales and Marketing users this Profile. This enforces the principle of least privilege.
2. Create a “Delete” Permission Set: I would then create a Permission Set named, for example, “Delete [Object Name] Records.” Inside this Permission Set, I would enable the “Delete” permission for that specific object.
3. Assign the Permission Set: Finally, I would assign this new Permission Set only to the Marketing users.

Result: Both Sales and Marketing users share the same base Profile, making them easy to manage. However, only the Marketing users receive the additional permission to delete records via the Permission Set.

6. What is Shield Platform Encryption?

Shield Platform Encryption is a premium Salesforce feature that enables you to encrypt sensitive data “at rest” in the Salesforce database. This means the data is encrypted when it’s being stored, adding a powerful layer of protection against unauthorized access to the underlying data. It helps companies meet compliance and governance requirements for data privacy.
Access to view the decrypted data is controlled by a specific user permission, “View Encrypted Data.”

7. A user reports they can see Accounts they don’t own, even though OWD is set to Private. How would you debug this?

When OWD is Private, any access must be explicitly granted. My debugging process would be:

1. Use the “Sharing” Button: The fastest and most effective first step is to navigate to the specific Account record the user can see and click the Sharing button. This opens the Sharing Hierarchy page, which details every user who has access and, crucially, the Reason for that access (e.g., “Role Hierarchy,” “Sharing Rule: West Coast Team,” “Manual Share”). This almost always provides the answer.
   
2. Check for “View All” Permissions: If the Sharing button doesn’t reveal the cause, I’d check the user’s Profile and all assigned Permission Sets for the “View All” permission on the Account object or the powerful “View All Data” system permission. These override all sharing settings.
   
3. Analyze Sharing Rules & Groups: I would go to Setup > Sharing Settings to review Account Sharing Rules. I’d check if the user’s role, territory, or a public group they belong to is being granted access.
   
4. Review Teams & Territory Management: I would verify if the user is part of an Account Team for that specific record or if Enterprise Territory Management rules are granting them access based on the account’s territory.

8. An external user is seeing records they shouldn’t . What steps would you take to audit and resolve this?

Securing data for external Experience Cloud users is critical. I would take immediate and systematic action:

1. Impersonate and Verify: First, I would log in as the external user to see exactly what they see and confirm which specific records are incorrectly visible.
2. Review Sharing Sets & Share Groups: This is the most common vulnerability. I’d go to Setup > Digital Experiences > Settings and meticulously audit all Sharing Sets and Share Groups. Sharing Sets grant access based on the user’s Account or Contact relationship. I’d ensure the profiles, objects, and access levels (e.g., Read-Only) are correctly configured.
3. Confirm External OWD: In Sharing Settings, I would verify that the Organization-Wide Defaults for all sensitive objects are set to Private for “External Access.” This is the foundational security setting for portals.
4. Audit the User’s Profile: I would inspect the external user’s Profile to ensure it’s using a Customer or Partner community license and that it does not have any elevated object permissions like “View All” or risky system permissions.
5. Use the User Access and Permissions Assistant: This AppExchange app from Salesforce is an excellent tool for analyzing and reporting on an external user’s permissions, and it can help pinpoint the source of a data leak quickly.

9. A user with multiple permission sets still can’t access a tab. What are the possible causes?

Tab visibility is determined by two key settings working together. If a user can’t see a tab, the cause is almost always one of these:

1. Tab Setting on Profile is “Tab Hidden”: The most common reason is that the tab setting on the user’s Profile is set to “Tab Hidden.” This is the most restrictive setting and cannot be overridden by a Permission Set. If the Profile says “Tab Hidden,” the tab will always be hidden for that user.
2. No “Visible” Setting Applied: If the Profile setting is “Default Off,” the user will only see the tab if at least one of their Permission Sets has the tab setting configured to “Visible” (the checkbox for “Available” on the Permission Set).
3. No Object-Level “Read” Permission: A user cannot see the tab for an object if they do not have at least “Read” permission on that object. I would verify their Profile and all assigned Permission Sets combined grant them “Read” access to the underlying object.

10. A user can access records via a flow, but not manually in the UI. What could be the cause?

This is a classic indicator that the Flow is running in a different security context than the user. The cause is that the Flow is configured to run in System Context Without Sharing.

• User Context: When a user interacts with the UI, their actions are governed by their own permissions, OWD, and sharing rules.
• System Context Without Sharing: When a Flow runs in this mode, it runs with system-level permissions, completely ignoring the running user’s personal permissions and all sharing settings. This allows the Flow to find, create, and update records that the user has no manual access to.

This might be intended for automation, but if it’s unexpected, a solution is to edit the Flow’s advanced properties and change the execution context to “System Context with Sharing” or “User Context.”

11. How does the Security Health Check help you?

The Security Health Check is a native Salesforce tool that measures an org’s security settings against Salesforce’s recommended baseline. It provides a score from 0-100 and identifies potential risks in areas like Password Policies, Session Settings, and File Upload Security. I use it proactively to:

1. Establish a Baseline: Get a quick, high-level overview of the org’s security posture.
2. Identify and Remediate Risks: Use the results to identify and fix vulnerabilities, often with a single click using the “Fix Now” button.
3. Demonstrate Compliance: Show stakeholders and management that we are adhering to security best practices over time by tracking the score.

12. You have a team of users under the same role and profile, but only some need access to a custom object. How would you achieve this?

This is a perfect use case for Permission Sets and the principle of least privilege.

1. Configure the Profile: On the shared Profile, I would remove all access to the custom object. I’d set its object permissions to None (no CRUD access) and set the tab setting to “Tab Hidden.” This ensures the baseline for everyone on that profile is no access.
2. Create a Permission Set: I would create a new Permission Set named, for example, “[Custom Object Name] User Access.” Inside this Permission Set, I would grant the necessary permissions: “Read” and “Create” on the object, visibility for the relevant fields through FLS, and set the tab to “Default On.”
3. Assign to Specific Users: Finally, I would assign this Permission Set only to the specific users on the team who need to access the custom object.

This approach keeps the Profile clean and simple while providing granular, auditable access to those who require it.

13. A manager needs read-only access to Opportunities created by their team, but shouldn’t be able to edit them. How will you set this up?

This scenario requires a combination of Role Hierarchy and Profile settings.

1. Set OWD: Ensure the Opportunity OWD is set to Private.
2. Configure Role Hierarchy: Place the manager in a Role directly above their team members in the Role Hierarchy. By default, this will grant them full edit access to their team’s opportunities.
3. Restrict via Profile: This is the key step. On the manager’s Profile (or a Permission Set), I would modify the object permissions for the Opportunity object. I would uncheck the “Edit” permission, leaving only the “Read” permission checked.

Result: The Role Hierarchy will try to grant access down to the manager, but the manager’s own Profile permissions will act as the final gatekeeper. The hierarchy gives them visibility to the records, but their Profile prevents them from being able to edit them.

14. A Director wants to view all records of their subordinates but not through a report. How will you enable this?

This is the primary function of the Role Hierarchy. By placing the Director in a role above their subordinates, they automatically gain visibility into their records.

Setup Steps:

1. Navigate to Setup > Roles and confirm the Director’s assigned role is directly above the roles of their subordinates (e.g., “Director of Sales” is above “Sales Manager”).
   
2. Go to Setup > Sharing Settings and ensure the “Grant Access Using Hierarchies” setting is enabled for the object in question. This is on by default for standard objects but must be verified for custom objects.

Once configured, the Director can simply navigate to the object’s list view and select a pre-built filter like “My Team’s [Records]” to see all the records owned by users in roles directly below them.

15. You’ve been asked to automatically share all High Priority Cases with a specific team. What’s the most scalable approach?

The most scalable and maintainable approach is to use a Criteria-Based Sharing Rule.

1. Create a Public Group: First, I would go to Setup > Public Groups and create a new group called, for example, “High Priority Case Team.” I would add all the relevant users to this group. Using a group is more scalable than sharing with individual roles, as team members can change without having to edit the sharing rule itself.
2. Create the Sharing Rule:
   • Navigate to Setup > Sharing Settings.
   • Under the Case Sharing Rules, create a new rule.
   • For the criteria, I would set Field: Priority, Operator: equals, Value: High.
   • For the “Share with” setting, I would select “Public Groups” and choose the “High Priority Case Team” group I just created.
   • I’d set the access level to “Read/Write” or “Read-Only” as required by the business.

This rule will now automatically and dynamically share any Case that is created or updated to have a “High” priority with the designated team.

16. How can you allow temporary record access for a support team during product launch month only?

Using Permission Sets with an expiration date is the most modern, auditable, and secure way to handle this.

1. Create a Permission Set: I would create a Permission Set that grants the necessary temporary access. For example, if they need access to a “Launch Projects” custom object, I would grant CRUD permissions and tab visibility in this Permission Set.
2. Assign with Expiration: When assigning this Permission Set to the support team users, I would use the Assignment Expiration feature. I would set the expiration date to the end of the launch month.
3. Automation: Salesforce will automatically revoke the permissions from all assigned users on the specified expiration date.

This method is far superior to manual methods like adding users to a public group and trying to remember to remove them later. It is self-managing and creates a clear audit trail.

17. A business asks you to restrict visibility to Opportunities in certain regions for specific users. How would you implement this?

This is a perfect use case for a Restriction Rule. Restriction Rules act as a filter on the records a user can see from the list they already have access to.

Implementation Plan:

1. Identify Users: I would identify the users who need this restriction. I could either target their Profile or, for better flexibility, create a new Permission Set called “Regionally Restricted” and assign it to them.
   
2. Create Restriction Rule: I would navigate to the Opportunity object in Object Manager and create a new Restriction Rule.
   • User Criteria: I would set the rule to apply to users who have the “Regionally Restricted” Permission Set assigned ($Permission.Regionally_Restricted = true).
   • Record Criteria: I would define the filter logic to match the user’s region to the opportunity’s region. For example: User.Region__c = Record.Region__c.

This ensures the targeted users can only see Opportunity records where the “Region__c” field on the Opportunity matches the "Region__c" field on their own User record, without affecting anyone else’s visibility.

18. What’s the difference between using Sharing Rules vs. Territory Management to solve data visibility?

Both grant record access beyond OWD and the Role Hierarchy, but they are designed for different business models.

• Sharing Rules are best for straightforward, stable sharing requirements based on record ownership or record attributes. They are a universal tool that works for all orgs.
  • Example: “Share all accounts owned by the US Sales team with the US Support team.”
    
• Territory Management is a more complex and structured solution designed for organizations where account access is determined by territory assignments, not just ownership. It’s a hierarchical model based on geographic, industry, or other attributes. It primarily affects Accounts, Opportunities, and Cases.
  • Example: “An account is in California. Grant access to all sales reps assigned to the ‘CA-North’ territory, regardless of who owns the account. Also, grant access to their managers in the ‘Western Region’ territory hierarchy.”

Key Takeaway: Use Sharing Rules for most standard sharing needs. Use Territory Management when your sales model is based on complex, hierarchical territories rather than a simple ownership model.

19. Can a user above in the role hierarchy see everything below? Always?

Generally, yes, but not always. The “Grant Access Using Hierarchies” setting is the key.

For most standard objects (like Opportunity and Case), this setting is enabled by default and cannot be changed. This means managers can always see the records of subordinates in their hierarchy.

However, for custom objects, this is a checkbox that can be disabled. If an administrator disables “Grant Access Using Hierarchies” for a custom object, then the role hierarchy will not grant any access to that object’s records. In this case, a manager would not be able to see their subordinate’s custom object records unless a sharing rule explicitly granted them access.

20. What is the impact of a Private OWD on reporting?

A Private OWD significantly impacts reporting. When a user runs a report, the results will be automatically filtered to show only the records they have access to based on the sharing model. A user will only see records they own, records shared with them via the role hierarchy, or records shared via sharing rules, teams, or manual sharing.

Example: If the Opportunity OWD is Private, and a sales rep runs a company-wide “All Opportunities” report, their version of the report will only contain their own opportunities. When their manager runs the exact same report, they will see their own opportunities PLUS all the opportunities of the reps below them in the hierarchy.

21. You need to give a user access to dashboards based on records they don’t own. How would you handle that?

Dashboard visibility depends on two things: access to the folder and access to the data in the reports. The solution here lies with the dashboard’s Running User.

1. Dashboard Folder Access: First, I would ensure the user has at least “Viewer” access to the folder where the dashboard is stored.
2. Set a “Running User”: By default, a dashboard runs as the “Logged-in User,” respecting their personal permissions. To solve this, I would edit the dashboard and set it to “Run as a specified user.” I would choose a user (like a team manager or a system integration user) who has full visibility into all the required records.

Example: A junior marketing user needs to see a “Campaign ROI Dashboard” that includes data from all active campaigns. The Campaign OWD is Private. I would set the dashboard’s Running User to be the Marketing Director. Now, when the junior user views the dashboard, it will display the data as if the Director were running it, showing all the necessary records. This is sometimes referred to as a Dynamic Dashboard.

22. You’re implementing a partner portal and need separate access control for internal and external users. How will you structure roles and sharing?

Structuring a secure partner portal (Experience Cloud) requires a clear separation between internal and external security models.

1. Licenses and Roles: Internal users will keep their standard Salesforce licenses and remain in the internal Role Hierarchy. Partner users will be assigned Partner Community licenses. Their roles will exist in a separate hierarchy under their company’s Account record (e.g., Partner User, Partner Manager). These external roles do not report into the internal role hierarchy, creating a natural security boundary.
   
2. External OWD: The first and most critical step is to go to Sharing Settings and set the “External Access” OWD for all key objects to Private. This isolates external user data from the start.
   
3. Sharing Mechanisms:
   • Internal Users: We continue to use the Role Hierarchy and internal Sharing Rules.
   • External Users: We will primarily use Sharing Sets. I would create a Sharing Set for the partner profile that grants them access to records (like Cases or Opportunities) that are related to their own Account record. This is the primary mechanism for secure portal sharing. For more complex needs, Share Groups can be used to extend specific sharing rules to partners.

23. When should we use Teams (Account/Opportunity/Case)?

You should use Teams when you have a group of users who consistently work together on specific records, but the composition of that group changes from record to record. It’s a flexible, record-by-record approach to sharing.

Example: For a large, complex Opportunity, the owner might add an Account Executive, a Sales Engineer, and a Legal expert to the Opportunity Team. Each team member can be assigned a specific role and level of access (Read-Only or Read/Write) to that single Opportunity. On the next big deal, the team might be composed of entirely different people. This is much more scalable than creating hundreds of one-off sharing rules.

24. What is Apex Managed Sharing?

Apex Managed Sharing is a programmatic way to share records with users or groups using Apex code. Unlike other sharing types, the sharing records created via Apex Managed Sharing persist even when the record owner changes. It is used for complex sharing requirements that cannot be met by standard sharing rules.

A developer writes an Apex class that implements the CalcSharing interface to create, update, or delete the share records. This is necessary when sharing logic depends on values from a different object or involves complex calculations.

25. What is implicit sharing in Salesforce?

Implicit Sharing is an automatic, built-in sharing behaviour that grants access to parent records when a user has access to a child record. It mainly applies to the relationship between an Account and its child Contacts, Opportunities, and Cases. It cannot be turned off.

Example: The OWD for Accounts is Private. A user who is not the account owner is given access to a single Opportunity record (perhaps via a sharing rule). Implicit Sharing will automatically give that user Read-Only access to the parent Account record associated with that Opportunity. This ensures the user has the necessary context about the Account while working on the Opportunity.

26. OWD Scenario: Your company acquires a new business. For legal reasons, their sales team must only see their own accounts for the first six months. How do you configure the Account OWD to handle this?

This requires a time-based sharing solution that starts with a restrictive foundation.

1. Set OWD to Private: The Account OWD must be set to Private. This ensures that by default, no one can see accounts they don’t own.
2. Identify the Acquired Accounts: I would create a new checkbox field on the Account object called “Acquired Account” and a Date field called “Acquisition Date.” I would populate these fields for all imported accounts.
3. Create Public Groups and Roles: I would place the acquired sales team into their own Roles and a dedicated Public Group.
4. Create a Criteria-Based Sharing Rule: I would create a criteria-based sharing rule that shares accounts where Acquired Account = FALSE with the original company’s roles/groups. This keeps the original data visible to the original team. The new team will only see what they own.
5. Plan for the Future: After six months, I would create a new owner-based sharing rule to share the acquired team’s accounts with the broader organization as needed, or I would run a data update to uncheck the “Acquired Account” box, which would then make them eligible for existing sharing rules.

27. Role Hierarchy Scenario: Two VPs of Sales are at the same level in the role hierarchy. They need to see each other’s team pipelines to collaborate on a major deal. How can you enable this without changing the OWD for Opportunities?

Since they are peers in the hierarchy, vertical sharing won’t work. The best solution is to create a specific sharing rule to open up horizontal access.

1. Create a Public Group: I would create a new Public Group called “VP of Sales Collaboration Group.” I would add both VPs to this group.
2. Create an Owner-Based Sharing Rule: I would then go to Sharing Settings for the Opportunity object and create a new sharing rule.
   • Rule Type: Owner-based.
   • Share records owned by members of: “VP of Sales Collaboration Group”.
   • Share with: “VP of Sales Collaboration Group”.
   • Access Level: Read-Only (or Read/Write, depending on the requirement).

This rule effectively says, “Any opportunity owned by a member of this group should be shared with every other member of this group.” This solves the problem without altering the OWD or the entire role hierarchy.

28. Profile Scenario: You’ve been asked to create a new custom profile for a team of interns. What is the best practice for creating this profile to ensure absolute minimal access?

The best practice is to always start with the most restrictive baseline possible and only add what is necessary.

1. Clone the “Minimum Access – Salesforce” Profile: I would navigate to Profiles, find the standard “Minimum Access – Salesforce” profile, and clone it. This profile has almost all permissions turned off by default. I would name the clone “Intern Profile.”
2. Grant Access via Permission Sets: Instead of enabling permissions directly on the new profile, I would create one or more Permission Sets for the tasks the interns need to perform (e.g., “View Accounts and Contacts,” “Create Case Comments”).
3. Assign Permission Sets: I would then assign these granular Permission Sets to the intern users.

This approach follows the principle of least privilege. The Profile itself remains clean and minimal, and all permissions are granted through auditable Permission Sets, making it easy to add or remove access as their responsibilities change.

29. Permission Set Scenario: A group of users needs to ‘Delete’ Opportunity records, but this is disabled on their Profile for compliance reasons. What’s the most secure way to grant this permission without changing their Profile?

The most secure and appropriate way to handle this is with a Permission Set.

1. Create a New Permission Set: I would create a new Permission Set called “Opportunity Delete Access.”
2. Grant Object Permission: Inside this Permission Set, I would navigate to “Object Settings,” select “Opportunities,” and enable the Delete permission. I would ensure no other permissions (like Edit or View All) are enabled unless explicitly required.
3. Assign to Specific Users: I would then assign this new Permission Set only to the specific users in the group who have been approved for this elevated privilege.

This method is secure because it doesn’t require cloning or changing the base profile, which might have dozens or hundreds of other users. It provides a very specific, additive permission that is easy to assign, revoke, and audit.

30. Sharing Rule Scenario: The OWD for ‘Case’ is Private. The support team is split into ‘Tier 1’ and ‘Tier 2’. How do you ensure all ‘Tier 1’ members can see all cases assigned to other ‘Tier 1’ members?

This is a classic use case for an owner-based sharing rule using a public group.

1. Create a Public Group: First, I would create a Public Group called “Tier 1 Support.” I would add all users who are part of the Tier 1 team to this group. Using a group is essential for scalability.
   
2. Create an Owner-Based Sharing Rule: I would then navigate to Sharing Settings for the Case object and create a new sharing rule.
   • Rule Type: Owner-based.
   • Share records owned by members of: The “Tier 1 Support” Public Group.
   • Share with: The “Tier 1 Support” Public Group.
   • Access Level: Read/Write, so they can collaborate and take over cases from each other.

This rule creates full visibility and collaboration within the Tier 1 team, without granting them access to Tier 2 cases or any other records.

31. Mixed Scenario: A Finance user needs read-only access to all ‘Closed Won’ Opportunities. Their profile grants zero access to the Opportunity object. What is the most secure and efficient way to grant this?

The most secure and efficient way is to use a Permission Set combined with a Restriction Rule.

1. Create a Permission Set: I would create a Permission Set called “Finance – View Closed Won Opps.”
   • In this Permission Set, I would grant Read access to the Opportunity object.
   • I would set Field-Level Security to ensure all necessary fields are readable.
2. Create a Restriction Rule: To ensure they only see Closed Won opportunities and not all opportunities that their new Read access would grant, I would create a Restriction Rule on the Opportunity object.
   • User Criteria: The rule would apply to users with the “Finance – View Closed Won Opps” Permission Set.
   • Record Criteria: The rule would be StageName = 'Closed Won'.
3. Assign the Permission Set: I would assign the new Permission Set to the Finance user.

This combination ensures the user gets the necessary object and field access but is restricted to seeing only the specific subset of records relevant to their job function.

32. OWD vs. Sharing Scenario: The ‘Lead’ object is Private. The marketing team needs to see all leads generated from their campaigns, regardless of who owns them. How would you set up this sharing model?

This is a perfect scenario for a Criteria-Based Sharing Rule. The trigger for sharing is an attribute on the Lead record itself (its connection to a marketing campaign), not who owns it.

1. Create a Public Group: I would create a Public Group called “Marketing Team” and add all relevant marketing users.
   
2. Create the Sharing Rule: I would go to Sharing Settings for the Lead object.
   • Rule Type: Criteria-based.
   • Criteria: The criteria would be CampaignId NOT EQUAL TO "". This ensures that any lead associated with any campaign is included.
   • Share with: The “Marketing Team” Public Group.
   • Access Level: Read-Only, as they primarily need to see and report on the leads.

This rule automatically shares all campaign-generated leads with the marketing team, providing them with the visibility they need for their analysis.

33. Access Restriction Scenario: Can you use a sharing rule to restrict access to records? Explain your answer.

No, you cannot. This is a fundamental concept of the Salesforce sharing model.
Sharing rules can only be used to grant additional access but they can never be used to restrict or take away access that a user already has through their Profile, OWD, or Role Hierarchy.

Workaround : The correct way to restrict access to records that a user might otherwise see is with a Restriction Rule. Restriction Rules apply a filter to the records a user sees, effectively hiding a subset of records from their view without changing their underlying access rights.

34. Temporary Access Scenario: A manager is on vacation. How would you give their subordinate temporary access to approve discount requests in their absence? Name two methods.

There are two primary, standard methods for handling this:

1. Delegated Approver: This is the preferred and simplest method. The manager (or an administrator) can navigate to the manager’s own User record, go to Approver Settings > Delegated Approver, and select the subordinate. All approval requests sent to the manager will be automatically routed to the subordinate for the duration of their absence. The manager can turn this off upon their return.
   
2. Manual Reassignment from Queue: If the approval process is configured to send approvals to a Queue that both the manager and subordinate are members of, the subordinate could simply take ownership of the approval requests from the queue. If the request goes directly to the manager, an administrator with “Modify All Data” permissions can manually reassign the pending approval request to the subordinate.

35. Design Scenario: You are designing the security for a new custom application. What are the first three questions you would ask the business stakeholders to determine the right OWD and sharing model?

To design an effective security model, I need to understand the business process and data sensitivity. My first three questions would be:

1. “What should be the default visibility for a new record? By default, who should be able to see a record that someone else just created?” This question directly determines the Organization-Wide Default (OWD). If the answer is “only the owner and their manager,” the OWD should be Private. If it’s “everyone,” it should be Public Read-Only or Public Read/Write.
   
2. “Are there any teams or groups of users who need to see each other’s records, even if they don’t own them?” This question uncovers the need for horizontal sharing and will determine the owner-based sharing rules required. For example, “The West coast sales team needs to see all of the West coast support team’s records.”
   
3. “Are there any conditions or attributes of a record itself that should automatically trigger sharing with a specific group?” This question identifies the need for criteria-based sharing rules. For example, “Should all projects with a budget over $1M be automatically visible to the executive team?”
   
   Then again Questions can vary upon use case and business requirement .

36. Explain the importance of session settings like timeout values and requiring HTTPS.

Session Settings are critical for protecting against unauthorized access to active user sessions.

• Timeout Value: This setting automatically logs a user out after a defined period of inactivity. A short timeout (e.g., 15-30 minutes) significantly reduces the risk of an unauthorized person using an unattended, logged-in computer to access Salesforce.
• Requiring HTTPS: This ensures that all data transmitted between a user’s browser and Salesforce is encrypted. Without it, data is sent as plain text, making it vulnerable to interception by attackers on the same network (e.g., public Wi-Fi), an attack known as “session hijacking.”
  
  Setup –> Quick find –> Session settings

37. What is Multi-Factor Authentication (MFA) and why is it crucial?

Multi-Factor Authentication (MFA) is a security control that requires users to provide two or more pieces of evidence (or “factors”) to prove their identity when logging in. It combines something they know (password) with something they have (an authenticator app or security key).

Why it’s crucial: Passwords alone are no longer secure. They can be stolen or guessed. MFA provides a critical second layer of defense. Even if an attacker steals a user’s password, they cannot log in without also having physical access to the user’s phone or security key.

38. Your company uses Shield Platform Encryption. Can a user with “View All Data” but without the “View Encrypted Data” permission see the value in an encrypted field?

No. Shield Platform Encryption provides data-at-rest encryption. Access to view encrypted data is controlled by a specific system permission: “View Encrypted Data”. A user with “View All Data” has broad access to records, but that permission does not bypass Shield’s encryption layer. If they do not also have the “View Encrypted Data” permission, they will see the encrypted fields as masked (e.g., “*********”).

39. When should you use Manual Sharing?

You should use Manual Sharing for one-off exceptions where a specific user needs access to a single record they wouldn’t normally see.

Example: A Sales Rep is working on a unique deal and needs their manager’s boss (who is in a different division) to see one specific Opportunity record to provide advice. The rep can use the “Sharing” button on the record to manually share it with that specific executive.

40. What is a public group?

A public group is a collection of individual users, other groups, or users in specific roles or territories. The purpose of a public group is to simplify sharing and access management. Instead of sharing a record with many individual users, you can share it with a single public group. They are commonly used as the target for sharing rules.

41. What if OWD is Public Read/Write and I want some users to only have Read access?

You cannot use sharing rules to restrict access; they only grant access. The correct way to handle this is at the Profile or Permission Set level.

1. Set the Organization-Wide Default (OWD) for the object to Public Read-Only. This becomes the new baseline for everyone.
2. On the Profiles or Permission Sets of the users who still need to edit records, grant them the “Edit” permission for that object.

This creates a “least privilege” model where most users can only read, and you explicitly grant edit access to those who need it.

42. A user with “Modify All Data” cannot delete a specific record. What could be the cause?

This is a tricky question. While “Modify All Data” allows a user to bypass the sharing model, it does not allow them to bypass business logic or certain system constraints. The most likely reason is that the record is part of a process that prevents deletion.

Example: The record is a Contact that has been enabled as a User for a customer community. You cannot delete a Contact that is associated with an active User. The user record must be deactivated first. Another possibility is that the record has a lookup relationship to another record that is configured to not allow deletion of the parent record.

43. Can two users with the same Profile have different access to the same object?

So the simple answer is “Yes” , While their baseline permissions from the Profile are identical, their final access can differ due to:

1. Permission Sets: One user might have a Permission Set granting additional access that the other user doesn’t.
   
2. Role Hierarchy & Sharing rules : One user might be the record owner, or be above the owner in the role hierarchy, or be part of a public group that gets access via a sharing rule. The other user might not meet any of that criteria.

44. When should you use a criteria-based sharing rule?

You should use a Criteria-Based Sharing Rule when the decision to share a record is based on the attributes of the record itself, not on who owns it.

Example: A company has a rule that all Opportunity records with an Amount greater than $1,000,000 must be visible to the “Major Deals” public group. This rule is based on a field value on the Opportunity record, making it a perfect case for a criteria-based sharing rule.

45. What is the difference between deactivating a user and freezing a user?

• Deactivating a User: This is the standard process for permanently revoking a user’s access. It immediately frees up their Salesforce license.
  
• Freezing a User: This is a temporary action that instantly prevents a user from logging in. It does not free up their license, and you don’t have to reassign their records. It’s ideal for when an employee is on temporary leave or you need to immediately lock an account during a security investigation.

46. What is the key difference between a Profile and a Role?

This is a fundamental concept.

• Profile controls what a user can do. It determines object-level permissions (CRUD), field-level security, and system permissions. It defines a user’s functional access.
  
• Role controls what a user can see. It primarily determines record-level access through the Role Hierarchy and is used in sharing rules. It defines a user’s position in the data visibility hierarchy.

Analogy: The Profile is the user’s “job description,” while the Role is their position on the “org chart.”

47. What is an owner-based sharing rule?

An Owner-Based Sharing Rule opens up access to records based on who owns them. It shares records owned by users in a specific public group, role, or territory with users in another public group, role, or territory.

Example: The support team needs to see the accounts of the sales team to better serve customers. You can create an owner-based sharing rule that states: “Share Account records owned by users in the Role: Sales Rep with users in the Public Group: Support Team.”

48. Can a Permission Set restrict access?

No. A Permission Set can only grant permissions. It is purely additive. It cannot be used to take away or restrict any access that is granted at the Profile level.

Example : If a Profile grants “Edit” on Accounts, you cannot use a Permission Set to make Accounts Read-Only for that user.

49. What is the purpose of Field-Level Security (FLS)?

The purpose of Field-Level Security (FLS) is to control user access to specific fields on an object. It allows you to restrict what fields a user can see or modify (Editable), even if they have access to the record itself. FLS is essential for protecting sensitive information and ensuring data quality by preventing users from editing fields they shouldn’t.

Example: A support agent can see and edit a Case record, but FLS can be used to hide a sensitive custom field called “Potential_Legal_Issue__c” from their view, making it visible only to users with a “Legal Team” profile.

50. How does a user’s Locale or Language setting impact security?

A user’s Locale and Language settings have no direct impact on the security model. They do not affect a user’s ability to see or edit records. These settings are purely for user experience, controlling how dates, times, numbers, and currencies are displayed, and in what language the Salesforce UI appears. Security is determined entirely by the user’s Profile, Role, Permission Sets, and the org’s sharing model.