Interview Questions on Sharing and Security in Salesforce

 

Q. What is permission set group?

Permission Set Groups is a feature that allows Admins to combine multiple permission sets into a single permission set group for user assignment. With the grouping mechanism, admins can truly apply role-based access control for managing user entitlements in Salesforce orgs.

Q. What is custom permission set?

Currently, in Salesforce we have many features require access checks that specify which users can access certain functions. However, permission sets and profiles don’t include access for some custom processes and apps. Custom permissions let you define access checks that can be assigned to users via permission sets or profiles, similar to how you assign user permissions and other access settings. For example, you can define access checks in Apex that make a button on a Visualforce page available only if a user has the appropriate custom permission. Any time admin can revoke the custom permission from the profile or permission set to revoke the processor app access.

The below logic renders the page block based on the custom permission.

<apex:pageBlock rendered=”{!$Permission. Opportunity_Stage_Edit }”>

</apex:pageBlock>

Q How to trigger Sharing rule of Formula field?

Sharing rule does not let you use formula fields in the rule criteria, but workaround is to replace the formula field with a regular field and put the formula that populates it into a workflow that fires whenever an object is created or edited.That way you’ll have a regular field with the same value.

example- There is a city (formula field) on Student_c object and we need to use that in the criteria that when City = ‘Delhi’ then share with Sales Support role. Now because we cannot access formula field in the sharing rule so we will create another field on student object, lets say CityValue. Now we will create a workflow that whenever City (formulaField)= ‘Delhi’ then fieldUpdate CityValue (TextField) to ‘Delhi’. Then access the CityValue field in the Sharing rule.

Q. Is it possible to bypass Grant Login access using Hierarchies in case of standard objects?

No

Q. Can custom object on detail side has sharing rule?

Custom objects on the detail side of a master-detail relationship cannot have sharing rules, manual sharing, or queues, as these require the Owner field.

Q. Why I am not able to find list of Person Account fields in Field Level Security (FLS) settings when navigated to fields on Account Object?

Field Level Security (FLS) of Person Account fields are controlled by Contact Fields. So, if you want to setup FLS of Person Account Fields navigate to fields of Contact and it will be reflected on Person Account.

Q.Types of sharing rules, how many are there?

Sharing rules are used to open up the access to the Salesforce Record

Sharing rule works if OWD of record is either private or public read only

When sharing rule is executed then behind the scene salesforce created record for Share obect

We cannot share the records with user directly. We need to add users to public group to share records.

There are three type of sharing rules:

• Owner based sharing rule
• Criteria based sharing rule. You can’t use Apex to create criteria-based sharing rules. Also, criteria-based sharing cannot be tested using Apex.
• Guest user access, based on criteria

Can share record with –

• Public Group
• Roles
• Queues
• Roles and Internal Subordinates
• Roles , Portal and Internal Subordinates

Q.Explain Apex Sharing?

To access sharing programmatically, you must use the share object associated with the standard or custom object for which you want to share. For example, AccountShare is the sharing object for the Account object, ContactShare is the sharing object for the Contact object. In addition, all custom object sharing objects are named as follows, where MyCustomObject is the name of the custom object:

MyCustomObject__Share

A share object includes records supporting all three types of sharing:

managed sharing

user managed sharing

Apex managed sharing

Q. What are some considerations for Apex Managed Sharing?

Only users with “Modify All Data” permission can add or change Apex managed sharing on a record

Q. What are considerations of sharing object?

Objects on the detail side of a master-detail relationship do not have an associated sharing object.

We cannot create “__share” object by yourself. System create it for us. If sharing setting of an object is “Public Read/Write” system will not create “__share” object, as there is no scope of sharing, all record is open to everybody in org. However, if sharing setting of object is either “Public Read Only” or “Private“, system itself create a “__share” object for us.

Q. Case object has OWD set to private. Now regardless of hierarchies, like top to down (e.g. manager can view lead cases), down to top (e.g. lead can view manager cases), and horizontal (e.g. lead can view lead cases), and cross functionally, all cases should be visible to anyone without change in OWD. How is this possible?

Create a criteria based sharing rule where give access to “Roles and subordinates” to the head of department, this will let everyone access case regardless of hierarchy.

Q.Is it possible to create sharing rules for detail object?

No, we can create sharing rules for details objects because they don’t have owner field.

Q. What are properties of sharing object?

objectNameAccessLevel: The level of access that the specified user or group has been granted for a share sObject

Valid values are:

• Edit

• Read

• All

ParentID: The ID of the object. This field cannot be updated.

RowCause: The reason why the user or group is being granted access. The reason determines the type of sharing, which controls who can alter the sharing record. This field cannot be updated.

UserOrGroupId: The user or group IDs to which you are granting access. A group can be:

• A public group or a sharing group associated with a role.

• A territory group.

Q. What are some apex sharing considerations?

Objects on the detail side of a master-detail relationship do not have an associated sharing object. The detail record’s access is determined by the master’s sharing object and the relationship’s sharing setting.

Q.Apex run in which mode?

Apex generally runs in system context; that is, the current user’s permissions and field-level security are not taken into account during code execution. Sharing rules, however, are not always bypassed: the class must be declared with the without sharing keyword in order to ensure that sharing rules are not enforced.

The only exceptions to this rule are Apex code that is executed with the executeAnonymous call and Connect in Apex. executeAnonymous always executes using the full permissions of the current user. For more information on executeAnonymous, see Anonymous Blocks.

Q.What effect with sharing makes on user’s permission and FLS?

Enforcing sharing rules by using the with sharing keyword doesn’t enforce the user’s permissions and field-level security. Apex code always has access to all fields and objects in an organization, ensuring that code won’t fail to run because of hidden fields or objects for a user

Q.How to apply object-level and FLS in apex?

Apex doesn’t enforce object-level and field-level permissions by default, you can enforce these permissions in your SOQL queries by using WITH SECURITY_ENFORCED.

You can also enforce object-level and field-level permissions in your code by explicitly calling the sObject describe result methods (of Schema.DescribeSObjectResult) and the field describe result methods (of Schema.DescribeFieldResult) that check the current user’s access permission levels. In this way, you can verify if the current user has the necessary permissions, and only if he or she has sufficient permissions, you can then perform a specific DML operation or a query.

For example, you can call the isAccessible, isCreateable, or isUpdateable methods of Schema.DescribeSObjectResult to verify whether the current user has read, create, or update access to an sObject, respectively.

To check the field-level update permission of the contact’s email field before updating it:

1. if (Schema.sObjectType.Contact.fields.Email.isUpdateable()) {
2. // Update contact phone number
3. }

To check the field-level create permission of the contact’s email field before creating a new contact:

1. if (Schema.sObjectType.Contact.fields.Email.isCreateable()) {
2. // Create new contact
3. }

To check the field-level read permission of the contact’s email field before querying for this field:

1. if (Schema.sObjectType.Contact.fields.Email.isAccessible()) {
2. Contact c = [SELECT Email FROM Contact WHERE Id= :Id];
3. }

To check the object-level permission for the contact before deleting the contact:

1. if (Schema.sObjectType.Contact.isDeletable()) {
2. // Delete contact
3. }

Q.What is the use of stripInaccessible ?

Use the stripInaccessible method to enforce field- and object-level data protection. This method can be used to strip the fields and relationship fields from query and subquery results that the user can’t access. The method can also be used to remove inaccessible sObject fields before DML operations to avoid exceptions and to sanitize sObjects that have been deserialized from an untrusted source.

The access check is based on the field-level permission of the current user in the context of the specified operation—create, read, update, or upsert. The stripInaccessible method checks the source records for fields that don’t meet the field-level security check for the current user. The method also checks the source records for lookup or master-detail relationship fields to which the current user doesn’t have access. The method creates a return list of sObjects that is identical to the source records, except that the fields that are inaccessible to the current user are removed.

Q.Does stripInaccessible support AggregateResult object?

The stripInaccessible method doesn’t support AggregateResult SObject. If the source records are of AggregateResult SObject type, an exception is thrown.

Q.How to recalculate apex managed sharing?

To recalculate Apex managed sharing, you must write an Apex class to do the recalculation. This class must implement the Salesforce-provided interface Database.Batchable.

The Database.Batchable interface is used for all batch Apex processes, including recalculating Apex managed sharing.

For this example, suppose that you are building a recruiting application and have an object called Job. You want to validate that the recruiter and hiring manager listed on the job have access to the record. The following Apex class performs this validation. This example requires a custom object called Job, with two lookup fields associated with User records called Hiring_Manager and Recruiter. Also, the Job custom object should have two sharing reasons added called Hiring_Manager and Recruiter. Before you run this sample, replace the email address with a valid email address to which you want to send error notifications and job completion notifications.

Q.What is User Managed Sharing ?

In User Managed Sharing is, a user who has full access on the record shares the records with others, but when the record owner is changed, this record will be removed from Sharing table.  Similarly, when apex sharing is defined as “Manual” on RowCause, it will remove record from sharing table when the record owner is changed.

To resolve this issue, we need to define Apex Sharing Reason on Rowcause while writing Apex Sharing.

Example Code: 

Since we have defined Apex Sharing Reason on Custom Object sharing, it will keep Share table records updated whenever record owner is changed.  So, still granted user can access the records without any issue.

Q.Explain Apex Sharing for Standard Objects?

Standard objects don’t support Apex Sharing Reason. So, while sharing standard object records, by default you must define RowCause is “Manual”.

Q. Case object has OWD set to private. Now regardless of hierarchies, like top to down (e.g. manager can view lead cases), down to top (e.g. lead can view manager cases), and horizontal (e.g. lead can view lead cases), and cross functionally, all cases should be visible to anyone without change in OWD. How is this possible?

Create a criteria based sharing rule where give access to “Roles and subordinates” to the head of department , this will let everyone access case regardless of hierarchy.

What are scenarios where we can use without sharing?

Without Sharing

1.If we have LWC page in which we are showing “Sales Rep Performance” which displays a flag in red, green and yellow. Now ideally this field should not be visible whenever a Sales Rep accesses this page. But it is always visible if the class has no keyword specified or if a class has without sharing specified.

What are the considerations while using with sharing?

• If the class is not declared as With Sharing or Without Sharing then the class is by default taken as Without Sharing.
• Both inner classes and outer classes can be declared as With Sharing.
• If inner class is declared as With Sharing and top level class is declared as Without Sharing, then by default entire context will run in With Sharing Context.
• If a class is not declared as With/Without Sharing and if this class is called by another class in which sharing rules is enforced then both the classes run with With Sharing.
• Outer class is declared as With Sharing and inner class is declared as Without Sharing, then inner class runs in Without Sharing Context only(Inner class don’t take the Sharing properties from outer class).

Q.What is the difference between apex managed sharing and with sharing?

Apex Managed Sharing is used to grant the access to the records. It is about pro grammatically configuring sharing rules. Keyword “With Sharing” is used to respect the current user sharing rule.

Q.What are considerations while using apex managed sharing?

• If record owner changes, then sharing created through apex managed sharing are maintained but if user share record manually, then record sharing will be lost if owner changes.
• User with “modify All Data” can only add, edit or delete records in share table.

Q.What are the limitations of manual sharing?

• Manual Sharing cannot be stricter than Organization Wide Defaults.
• Manual Sharing is only available on individual records, it is not available for all records of a certain object.
• Only applicable on records that have Private or Public Read Only access in OWD.
• When setting Automatic and Manual Sharing users and admins should define if the security should be extended to related records.
• What is With sharing and without sharing?
• With Sharing: It means “with Security Settings enforced”.If you declare a class as a With Sharing, Sharing rules given to the current user will be taken into the consideration. This, pertains to only respecting OWDs and Sharing Rules.  We cannot “automatically” enforce field level security or profile permissions with “with sharing,”
• Example
• public with sharing class sharingClass
• Without Sharing:If you declare a class as a Without Sharing, then this Apex class runs in system mode which means Apex code has access to all the objects and field irrespective of current users sharing rules, field level security and Object permissions.

Q.Difference between role and profile?

• Profiles help to control object privileges such as CRED (Create, Read, Edit, Delete). They also contain system permissions that a user can carry out such as exporting data.
• Roles help with sharing records across an organization. They work in a hierarchical fashion, giving users access to records that are owned by people lower down in the hierarchy.
• A user can only have a single Profile and Role assigned to them.

Q.Difference between public group and queue?

• Queues are used when you we to assign a record to a bunch of users. With the help of queues we can assign a record to multiple users (using queues) so that any member of the queue can work on the record. It also allows the users to have there separate views.
• It is used for load balancing
• It can be created for Custom objects and for Case, Lead and Knowledge Article Version
• Example:
• Real life Scenario
• There are many Customer Care Executive in a call center and many customers call at a time and one executive can talk to one customer at one time,so other customer’s calls are kept in queues. Each user should assigned to at least one lead and same number of leads.
• Same thing is there in salesforce :
• User need to handle assigned lead individually and all users in organization should assigned with same number of leads, in this case we can define users in organization as Queue and assign them one by one and in same number using round robin lead assignment.

Public Group are team or group related user, used for a sharing data. They are not the owner of the records (like queue) but can share the records (in terms of access).

Public group can be created across any object.

Q.A can see B data but B cannot see A data. Why?

• Check following conditions
• 1 – Both users have same profile?
• 2. Check Role Hierarchy of A and B.
• 3. Check Sharing rule

Q.What is TOTP?

TOTP is time-based one-time password. We can use login flow that enhances TOTP authentication with a two-factor authentication method that Salesforce supports. The TOTP algorithm computes a one-time password from a shared secret key and the current time.

Users can use a time-based authentication application (such as Salesforce Authenticator or Google Authenticator) to scan the QR code and generate a TOTP token.

Q.What is With sharing and without sharing?

With Sharing: It means “with Security Settings enforced”.If you declare a class as a With Sharing, Sharing rules given to the current user will be taken into the consideration. This, pertains to only respecting OWDs and Sharing Rules.  We cannot “automatically” enforce field level security or profile permissions with “with sharing,”

Example

public with sharing class sharingClass

Without Sharing:If you declare a class as a Without Sharing, then this Apex class runs in system mode which means Apex code has access to all the objects and field irrespective of current users sharing rules, field level security and Object permissions.

Q.User A has the button CLONE visible on Accounts, User B can not see the button CLONE on Accounts. Why?

Check following conditions

1 – Both users have same profile?
2 – There is no Custom Permission Set assigned to any user
3 – Do you have record types for the Account Object and associated page layouts for those Record Types
4 – You have checked the page layout and Clone button is added to the Page Layout.

Q.We have 2 users A and B under same profile and Role. How can we restrict records of A to B and Vise versa?

In profile set View all data and modify all date permission to ‘false’. This will restric user to access data created by other users.

Q.There are 100 user. 90 user can read records, 10 users can update records?

Create two profiles:

First profile give read permission and add 90 users.

Second profile give read and edit permission and add 10 users.

Q.What is the types of OWD?

Private

Public read only

Public read and write

Public read/write/transfer

Q. What are limitations of OWD model?

OWD narrows down the access. Cannot open access

Q. There are five users under one profile and only one user see all the data. Account is private. Why?

Create permission set with view all access to accounts and assign permission set to specific user

Q. What is SAML?

Security Assertion Markup Language (SAML) is an open standard that enables single sign-on (SSO). By making a range of resources accessible with just one set of login credentials, you can provide seamless access to resources and eliminate insecure password proliferation.

SAML specifically enables identity federation, making it possible for identity providers (IdPs) to seamlessly and securely pass authenticated identities and their attributes to service providers (SPs).

Q. What is OWD and why it’s needed?
OWD is organization wide Default. It is used for record-level-security. It is base line security. It gives most restrictive access for the record and then we can open it up with role hierarchy, sharing rule, manual sharing.
Public Full access.
Public full action option is available for setting the Campaign Object only. Through public access the user can have the ability to search records, Reports and records, add related records, edit details of the record, can delete the record.
Read/Write/Transfer
Read/Write/Transfer option is only available for Leads and Cases. Here we can set to Private, Public Rad only, Public Read/Write and public/Read/Write/Transfer for case and lead objects. When case and lead objects are set to public/Read/Write/Transfer all users can view, edit, transfer and report on all cases and lead records.
Public Read/Write.
When ever a record is set to Public Read/Write the user can view, edit and report on all record.
Public Read Only.
When ever a record is set to public Read only the user can search the records, view and report on every record but the user can not edit that record. Record owners and users can edit that records.
Private.
When ever a record is set to private only that record owner and users above that roles in an hierarchy can view, edit and report on those records.
No Access, View only, Use.
This No Access, View only, Use options is available only for Price books only. We can set access level for price book OWD settings to either No Access, view only or use.
 Use is default access level for price Book and allows the users to access the price book information and can use that price book information in opportunities with products
 View Only allows the users to access the price book information and but not to use that price book information in opportunities with products.
 No Access restricts the users to access price book information and prices.

Q.What is Shield Platform Encryption?

Shield Platform Encryption gives your data a whole new layer of security while preserving critical platform functionality. It enables you to encrypt sensitive data at rest as well as while transmitted over network.

Shield Platform Encryption builds on the data encryption options that Salesforce offers out of the box. Data stored in many standard and custom fields and in files and attachments is encrypted using an advanced HSM-based key derivation system, so it is protected even when other lines of defense have been compromised.

Your data encryption key is never saved or shared across organizations. Instead, it is derived on demand from a master secret and your organization-specific tenant secret, and cached on an application server.

Q. How do we track whether the field is encrypted or nor?   

If you are an authorized user to access the record, the data will display normally in record. So how can we track whether the fields are encrypted or not. First thing we can check the filed information from Workbench

1. WorkBench: you can log in to the Workbench

Info-> Standard & Custom Object -> Select the object

Then expand Fields folder -> Select the field which you have encrypted. In details you will get Encrypted to true.

2. By Destroying the Tenant Key:   If you destroy the tenant key you will directly see the encrypted fields result at record level. To get authorized access again to encrypted fields  import the tenant key.

Encryption Statistics:

Encryption Statistics will provide you complete report on how much data is encrypted by Shield Platform Encryption and how much of data is encrypted by an active tenant secret.

Setup -> Platform Encryption -> Encryption Statistics

Q. Difference between Classic Encryption and Shield Encryption?

With Shield Platform Encryption, you can encrypt a variety of widely used standard fields, along with some custom fields and many kinds of files. Shield Platform Encryption also supports person accounts, cases, search, approval processes, and other key Salesforce features. Classic encryption lets you protect only a special type of custom text field, which you create for that purpose.

Q.What is implicit sharing?

Implicit sharing is automatic. You can neither turn it off, nor turn it on — it is native to the platform.

Parent implicit sharing provide read-only access to parent records (Account only), when user has access to children record, such as: Opportunities, Cases, or Contacts for that account. This does not mean the user must be the record owned of the child record.

When user have access to a record from other objects (NOT opportunity, case, or contact) that have lookup to Account, user will see the Account Name only, but not to access Account detail – this include Account lookup to the Parent Account, child account owner will see Parent Account Name only.

Child Implicit Sharing is ability for Account owner to access child records (contacts, opportunities, and cases), even they are not owned by Account owner. The account owner’s role determines the level of access to child records (read-only or read/write).

Q.What is System.RunAs?

Generally, all Apex code runs in system mode, where the permissions and record sharing of the current user are not taken into account. The system method runAs enables us to write test methods that change the user context to an existing user or a new user so that the user’s record sharing is enforced.

The runAs method doesn’t enforce user permissions or field-level permissions, only record sharing.We can use runAs only in test methods.