1.What are different Levels of data access in Salesforce.

Ans:
Organization level security
For our whole org, we can maintain a list of authorized users, set password policies, and limit logins to certain hours and locations.
Object level security
Here we set Object Level Access like Read, Create, Edit, Delete, View All and Modify All.
Field level security
We can restrict access to certain fields, even if a user has access to the object.
Record level security
We can allow particular users to view an object, but then restrict the individual object records they’re allowed to see. We can manage record-level access in these ways.
• Organization-wide defaults
• Role hierarchies
• Sharing rules
• Manual sharing
• Apex sharing (Coding)

2. What is a profile.

Ans: A Profile is used to give Object and Field Level Access.

3. Tell me the names of some standard profiles.

Ans: a] System Administrator
b] Standard User
c] Solution Manager

4. What is the "View All" AND "Modify All" permission

Ans: a] View All - Lets a user view all records of an object. Ignores sharing rules, but no edit/delete access.
b] Modify All - Lets a user view, edit, delete, and transfer all records of an object.Ignores all sharing and security settings.

5. Can we assign two profile to one users.

Ans:No. Only one profile per user is allowed.

6. Can we assing one profile to multiple users.

Ans: Yes.

7. Can we assign one Permission Set to multiple users.

Ans:Yes.

8. Can we assign two Permission Sets to one users.

Ans: Yes

9. What is FLS

Ans: FLS is Field Level Securities which controls which fields a user can see or edit on a Salesforce object.

10. What is a Permission Set.

Ans: A Permission Set is used to grant additional access to users without changing their Profile.

11. What is the difference between Profile and Permission Set.

Ans:

12. What is OWD

Ans: OWD is Organization-Wide Defaults is used to give record level access to the users when no other sharing rules apply.

13. Which record level access can be given using OWD

Ans:

14. In how many ways we can share a record.

Ans:
Manual Sharing – Users share specific records manually.
Sharing Rules – Auto-share records based on criteria or ownership.
Role Hierarchy – Users higher in the role hierarchy inherit access.
Apex Sharing – Programmatic sharing using Apex code.

And there are many ways...

15. What is difference between manual sharing and sharing rule.

Ans:
Manual Sharing: It shares single record at a time to the single or group of users. Sharing Rules: Records shared automatically to the group of users, if given criteria is safisfied.

16. What are the types of Sharing Rule.

Ans: There are two main types of sharing rules:
Owner-Based Sharing Rule:
Shares records owned by specific users or roles.
Example: Share all records owned by Role A with Role B.

Criteria-Based Sharing Rule
Shares records that meet specific field criteria.
Example: Share all Opportunities where Stage = 'Negotiation' with a Public Group.

If you enabled Experience Cloud/Community Cloud, there is an additional:
Guest User Sharing Rules
Shares records with unauthenticated (guest) users based on criteria.
Must be used carefully for public websites.

NOTE- Most of the students doesn't get this concepts easily, so check following explainations.

A] Based on Record Owner:
It decides, which Public Group Users wants to share record with Which Public Group Users.
Which Public Group Users -> With Which Public Group Users.

B] Based on the Criteria (Condition):
Here we create a Criteria.
Whenever a user creates Record, and if it satisfies Criteria, then the record shared with the selected Public Group. Users.
Criteria -> Which Public Group Users.

17. When to use salesforce sharing rule "Guest user access, based on criteria"

Ans:
Salesforce sharing rule “Guest user access, based on criteria” is used to grant record-level access to unauthenticated (guest) users visiting a Salesforce Experience Cloud (formerly Community Cloud / External Users) site, based on specific conditions.

Use Case:
Imagine you have a custom object called "Event__c" with a checkbox field Public_Event__c.
There are total 10 records. 04 Record with Public_Event__c checkbox true, and 06 Record with Public_Event__c checkbox false.

Now, you want to show 04 Record with Public_Event__c checkbox true to the external user/ experience cloud public users, then use this.

How to do this:
A] Create a criteria-based sharing rule on Event__c:
B] Select "Guest user access, based on criteria".
C] Criteria: Public_Event__c = TRUE.
D] Shared with: Guest user profile for your site.
E] Access Level: Read Only.

18. What is Roles and Hierarchies

Ans: Roles define a user’s position in the organization’s data access hierarchy.
In This, Manager (higher role) can see all records owned by their team members (lower roles).

19. Is it possible to restrict record level access for users using permission set?

Ans: No.

20. If I want to rectrict record level access, then what should I use from Salesforce security model?

Ans:OWD (Sharing Settings)

21. What is Mandatory while creating User, Role or Profile.

Ans: Profile

22. In the case of Master-Detail relationship, if OWD of master object is "Private", then can I set Details objects's OWD to "Public".

Ans: No, Details object is always Controlled by the Parents.

23. Suppose there are 3 users -> A,B and C, belongs to the profile “Manager”. All these three users can access (Read, Create, Edit, Delete) an object Account.
How to revoke the access of user B and C using permission set, so that they can not access object Account and only user A can access object Account.

Ans: Permission Set can not be used to revoke the permission once given over Profile Level.

First, remove all permission from Manager profile. In this way, users A,B,C will not be access Account object
Now create a new permission set and give Read, Create, Edit, Delete (whatever access you want) and then assign this permission set to user A.
In this way, only user A will access Account object.

24. I have created a Role and hierarchies. This is working fine for Other objects. But not for my custom object "Applicant__c". What is the issue?

Ans: In OWD, for "Applicant__c" object, enable “Grant Access Using Hierarchies” checkbox and save.

25. OWD of Account object is set to "Private". No manual sharing is done, No Sharing Rule applied, No Roles and Hierarchies applied. In this way, all the Profile's Users should see their own record only, right? The issue is, there is a Profile "Customer Care". All the Customer Care Users are able to see all the records of another users. What is the issue?

Ans: In "Customer Care" profile, View All is enabled for Account object. Disable it.

NOTE - As we know that, Profile settings are superior than OWD. Hence, Profile's View All will overlap OWD's Private setting.

26. There is a user “Bunty” having “Manager” profile. In Manager profile, Edit option is selected for Account object. OWD of Account is private.
Now, User Sheela shares an account record with Bunty with Read-Only access. Can Bunty edit this record?

Ans: No. Bunty can not edit this record.
Though, Profile -> Account is 'Edit' permission. And record is shared based on "Read-only", then Bunty can only read it.

27. Then, what is the meaning of Profile level -> Account 'Edit' permission.

Ans: Users will edit his records only.

28. Consider the following scenario.

Requirements:
A] Profile 'Policy Agent' users should not access Account object.
B] Profile'Policy Manager' users should access Account object.

Ans:
A] Go to Profile 'Policy Agent' and Remove all access from the Account object.
B] Go to Profile 'Policy Manager' and give Read, Edit, Delete etc.. access on the Account object.

29. Consider
A] Profile 'Policy Agent' users can Read, Create, Edit an Delete Account object.
B] Profile'Policy Manager' users can Read, Create, Edit an Delete Account object.

Requirements:
A] Profile 'Policy Agent' users should Read, Create and Edit Account object.
B] Profile'Policy Manager' users should Read, Create Account object.

Ans: Solution:
A] Go to Profile 'Policy Agent' and give Read, Create and Edit access on Account object.
B] Go to Profile 'Policy Manager' and give Read and Create access on the Account object.

30. Consider A] Profile 'Policy Agent' users have no access over Account object.
B] Profile'Policy Manager' users can Read, Create Account object.

Requirements:
A] Profile 'Policy Agent' users should Read Account object.
B] Profile'Policy Manager' users should Read and Edit Account object.

Ans: Solution:
A] Go to Profile 'Policy Agent' and give Read access on Account object.
B] Go to Profile 'Policy Manager' and give Read and Edit access on the Account object.

31. What is the difference between In-Active and to the user.

Ans:

32. There is a profile "Policy Manager" with users Bubli, Shyam and Pooja.
Currently they can Read, Create, Edit and Delete Account object.

Requirements:
A] Profile "Policy Manager" Users Shyam and Pooja should not access Account.
B] But Bubli user of the "Policy Manager" should Read the Account.

Ans: Solution:
A] Go to Profile 'Policy Manager' remove all the access from Account object. In this way Bubli, Shyam and Pooja can not access Account.
B] Now, create a Permission Set , Give Read access over Account and assign to Bubli. Now she can access Account

33. Let's Discuss about FLS i.e. Field Level Securities
A] Profile "Policy Agent" Users can Read and Edit the Rating field of Account.
B] Profile "Policy Manager" Users can Read and Edit the Rating field of Account.

Requirements:
A] Profile "Policy Agent" Users can only Read the Rating field of Account.
B] Profile "Policy Manager" Users should not access the Rating field of Account.

Ans: Solution:
A] Go to Profile 'Policy Agent' -> FLS -> Rating Read access only
B] Go to Profile 'Policy Manager' -> FLS -> Rating -> Remove Read and Edit access

34. Let's Discuss about FLS i.e. Field Level Securities
A] Profile "Policy Agent" Users can Read and Edit the Rating field of Account.
B] Profile "Policy Manager" Users can Read and Edit the Rating field of Account.

Requirements:
A] Profile "Policy Agent" Users Bunty, Kabira should only Read the Rating field and "Sheela" should Read+Edit the Rating field of Account.
B] Profile "Policy Manager" Users should not access the Rating field of Account.

Ans: Solution:
A] Go to Profile 'Policy Agent' -> FLS -> Rating -> Remove Read and Edit access.
Now, create a Permission Set -> Account -> FLS -> give Read, Edit access -> Assign to "Sheela".

B] Go to Profile 'Policy Manager' -> FLS -> Rating -> Remove Read and Edit access

35.Scenario : Consider following Roles and Hierarchical Structure of a company

If OWD of Account object set to “Private”, then

35.1. If staff 1 creates a record in account, then who can see this record?

Ans: The user Staff 1 and those are above to the Staff 1 can see this record, i.e Supervisor 1, General Manager and CEO.

35.2. If General Manager create a Account record, then who can see this record

Ans: General Manager and CEO.

35.3. If staff 5 creates a record in account, then who can see this record?

Ans: Staff 5 and those user who are above this user i.e Staff 1, Supervisor 1, General Manager and CEO.

35.4. If staff 5 creates a record in account, then can Staff 4 see this record?

Ans: NO

35.5. If staff 5 creates a record in account, then can Staff 3 see this record?

Ans: NO

35.6. If staff 5 creates a record in account, and Business (Client) says that it should be visible to Staff 4 only, what should we do?

Ans: Manual sharing with Staff 4.

35.7.What setting should we do so that above hierarchy come in effect for Account object.

Ans: General Manager and CEO.

36.What is a sharing object in salesforce OR What is Apex Sharing?

Ans: If we want to share a record programmatically, then we use a Sharing Object.

Sharing Objects:
A] Account -> AccountShare (Sharing Object)
B] Contact -> ContactShare (Sharing Object)
C] Applicant__c -> Applicant__Share (Sharing Object)
D] Passport__c -> Passport__Share (Sharing Object)

NOTE - We need not to create sharing object. It is automatically created by Salesforce itself.

For Example: Id accountId = '001XXXXXXXXXXXX'; // Replace with actual Account Id
Id userId = '005XXXXXXXXXXXX'; // Replace with target User Id

// Create AccountShare record
AccountShare accShare = new AccountShare();
accShare.AccountId = accountId;
accShare.UserOrGroupId = userId;
accShare.AccessLevel = 'Edit'; // Options: Read / Edit
accShare.RowCause = Schema.AccountShare.RowCause.Manual; // Or 'Manual' literal

insert accShare;