Sharing And Security Salesforce Interview Questions

Preparing for Sharing and Security Salesforce Interview Questions. Then this article is for you.

Contents

1 Sharing and Security Salesforce Interview Questions

Sharing and Security Salesforce Interview Questions

1. What are different levels of security in salesforce?

Object level security

The bluntest way that we can control data is by preventing a user from seeing, creating, editing, and/or deleting any instance of a particular type of object, like a Position or Review. Object-level access allows us to hide whole tabs and objects from particular users, so that they don’t even know that type of data exists.

On the platform, we set object-level access rules with object permissions on user profiles.

Field level security

A variation on object-level access is field-level access, in which a user can be prevented from seeing, editing, and/or deleting the value for a particular field on an object. Field-level access allows us to hide sensitive information like the maximum salary for a position or a candidate’s social security number without having to hide the whole object.

On the platform, we set field-level access rules with the field-level security.

Record level security

To control data with a little more finesse, we can allow particular users to view an object, but then restrict the individual object records that they’re allowed to see. For example, record-level access allows an interviewer like Melissa Lee to see and edit her own reviews, without exposing the reviews of everyone else on her team.

On the platform, we actually have four ways of setting record-level access rules:

Organization-wide defaults
Role hierarchies
Sharing rules
Manual sharing

2. What is Organization wide default?

OWD stands for Organization wide defaults. This setting is defined at object level. OWD defined the default record level sharing for objects. All profiles get at least the privileges defined in OWD. OWD takes three different values –

A. Private

B. Public Read only

C. Public Read-WriteTo find out what should be set as OWD for an object, first find out which user requires least access to an object. OWD is set based upon this users access requirements.
Most restrictive record access is defined using OWD. Access to additional records is made available through Role hierarchy, Sharing rules, Manual sharing.

3. What is role hierarchy?

Role Hierarchy allows additional users access to records. A hierarchy of roles is defined based upon access requirements at record level. Each user belongs to a unique role. If a role has access to some record, than its parent and ancestors will also have access to this record. Roles can be created using the Manager Users menu. Roles are used to control record access, where as profiles are used to specify access at object and field level.

4. What is public group?

Public group consists of users, roles or “roles and subordinates”. Sharing rule is defined using public groups. Record that match certain condition can be assigned to users in public groups using Sharing Rules. Sharing rules functionality is available via the menu Sharing Settings.

5. What is manual sharing (User Managed Sharing)?

Manual Sharing is used to grant one-off access. Manual sharing can be granted by record owner, any one above the owner in role hierarchy and System Administrator. Manual sharing is used to handle exception cases where access to a particular record needs to be given to a specific user. There is a Sharing button on the records page. This is used to provide manual sharing.

6. When Share button will be available on record detail page?

When OWD for object is “Public Read Only” or “Private”.
If OWD is Public Read-Write, then everyone in org have access to all records of object.

7. How to check whether user has access to a particular record or not?

Query “userRecordAccess” to check whether has access to record or not.

For example:
SELECT RecordId, HasReadAccess, HasTransferAccess, MaxAccessLevel, HasAllAccess, HasDeleteAccess, HasEditAccess FROM UserRecordAccessWHERE UserId = “005xxxxxxxxx”AND RecordId = “001xxxxxxxx”

HasAllAccess Indicates whether a user has all access–read, edit, delete, and transfer—to the record (true) or not (false).

HasReadAccess, HasEditAccess , HasDeleteAccess ,HasTransferAccess return Boolean value.
MaxAccessLevel return access level like None, read, Edit,Delete,Transfer and All.

8. What will happen if a field is hidden through Field level security and user search a values in that field?

Field-level security doesn’t prevent searching on the values in a field. When search terms match on field values protected by field-level security, the associated records are returned in the search results without the protected fields and their values.

9. What does “View all” and “Modify all” permission do at object level?

When you grant “View All” or “Modify All” for an object on a profile or permission set, you grant any associated users access to all records of that object regardless of the sharing and security settings.
In essence, the “View All” and “Modify All” permissions ignore the sharing model, role hierarchy, and sharing rules that the “Create,” “Read,” “Edit,” and “Delete” permissions respect. Furthermore, “Modify All” also gives a user the ability to mass transfer, mass update, and mass delete records of that specific object, and approve such records even if the user is not a designated approver.
These tasks are typically reserved for administrators, but because “View All” and “Modify All” let us selectively override the system, responsibilities that are usually reserved for the administrator can be delegated to other users in a highly controlled fashion.

10. If object-level permissions conflict with record-level permissions, then what will happen?

If object-level permissions conflict with record-level permissions, Salesforce applies the most restrictive settings.

If a user’s profile grants him update permission on an object, he will not be able to edit records of that type owned by other users unless read/write record-sharing has been granted.
If read/write sharing has been granted, a user whose profile does not specify update permission will not be able to edit records of that type.

11. What will happen if profile related to user U1 above in role hierarchy doesn’t have CRUD permission for object say A. User U2 below in his role hierarchy have CRUD permission to object A. Will user U1 will be able to see or edit record if Grant Access Using Hierarchies is checked for object A in sharing settings?

No. If a user does not have read or edit access to an object via OWD, a profile or permission set, they will have no visibility over an object regardless of their role and role hierarchy.

Always remember that User above in role hierarchy can see records of users below in hierarchy but operation which he can perform depends on permission on his profile (CRUD & View All & Modify All).

12. What is permission Set?

A permission set is a collection of settings and permissions that give users access to various tools and functions. The settings and permissions in permission sets are also found in profiles, but permission sets extend users’ functional access without changing their profiles.

For example, to give users access to a custom object, create a permission set, enable the required permissions for the object, and assign the permission set to the users. You never have to change profiles, or create a profile for a single use case. While users can have only one profile, they can have multiple permission sets.

13. Is it possible to restrict permission for users using permission set?

No. Permission Set always extends the permission.

14. If you have two record types for an object, do you need to have two page layouts for that objects?

No. It is not required but if user want different UI for different record type then we can create 2 different page layout and assign page layout to profiles based on record type.

15. If a user does not have access to a specific record type, will they be able to see the records that have that record type?

Yes. Record type controls only visibility of record on UI not its access to users.

16. True or False: A field hidden by field-level security is still visible through the API?

False

17. True or False: Child records in master-detail relationships have their own OWD?

False. In Master detail relationship, child inherit OWD from OWD. If you see OWD for child in master detail relationship, then system will display “Controlled by parent” in OWD settings page.
Child in look up relationship have different OWD as they are loose coupled.

18. If even one person in your organization is not allowed to see position data, what will be OWD ?

Private

19. What is apex manage sharing?

Apex managed sharing is a type of “Programatic Sharing” which allows you to define a custom sharing reason to associate with your programatic share. Standard Salesforce objects support “Programatic Sharing” while custom objects support Apex managed sharing.

More specifically, object shares can be written to both standard and custom objects, however custom sharing reasons can only be defined for shares written to custom objects.

apex manage sharing is used for custom objects as we can define apex sharing reason for custom objects. For standard object, apex sharing reason will be “Mannual”.

Salesforce create share table for all objects for which OWD is either public read only or Private. For standard object, share table name is table name followed by share word.

For example: AccountShare, ContactShare, CaseShare
For custom object, it is followed by __share. For example : For Position__c, share table name is Position__share

20. How to create share table record using apex?

Share table contains four columns: ParentId, UserOrGroupId, RowCause, AccessLevel.
Below is code to create position__share record:

Position__share p = new Position__share();
p.parentId = ‘Position Record Id which needs to be shared’;
p.userOrGroupId= ‘User id or Group id with which we want to share record’;
p.RowCause=’ apex sharing reason defined for custom object, here for position__c’;
p.AccessLevel =’access level for record’; //can be Read or Edit
insert p;

Note: You cannot update share table record. System only allows insert or delete of records for share table. So if you have to change access for user, you have create new record and can delete already existing record if you want.

21. Can we define apex sharing reason for standard object?

No. We can define apex sharing reasons for custom object.
Apex sharing reasons are defined object by object. – so, positions might have different reasons than candidates.

Related Salesforce Interview Question:

More Salesforce Interview Question: