Salesforce Security And Sharing Interview Questions

1. What is Salesforce Security Model Classification?

Generally, Salesforce security can be divided into two types. They are

• System Level Security
• Application Level Security

2. What is System Level Security?

System-level security in Salesforce is basically a set of security controls that we have to enter when logging into the Salesforce application.

• Authentication
• Authorization
• Social Sign-On

3. What is Authentication level security in Salesforce?

• Single Sign-On.
• Federated Authentication.
• Delegate Authentication.

4. What is Authorization level security in Salesforce?

• OAuth

5. What is Social Sign On level security in Salesforce?

• Twitter.
• Facebook.
• Salesforce.
• Google.
• Janrain: provides 25+ different authentication users.

6. What is Application Level Security?

In Salesforce, Application Level Security controls and restricts what the user can Edit, Delete, and View about the objects’ fields. After logging into Salesforce, this Salesforce security type is applied. Salesforce.com offers four levels of data access. As follows:

• Organization level Security or System Level Security.
• Objects level Security
• Field Level Security
• Record level Security

7. What is Organization level Security or System Level Security?

We maintain a list of authorized users, Password policies, Login IP ranges, limiting login access to specific hours, Session Security, Login Flows, and Network Access at the system level of Salesforce security.

8. What is Objects level Security?

Salesforce security at the object level is also called “Object Level Permissions.” The data can be controlled in this section. Salesforce object level security entails providing or controlling permission to the prescribed user at the object level. The following features can be included in object-level security.

• The user can be prevented from editing, seeing, creating, deleting, and managing certain types of objects.
• It is possible to hide the entire TAB from a user.

9. What is Field level Security?

Even if a user has access to an object, you can restrict access to certain fields. It is possible to make the salary field in a position object invisible to interviewers but visible to hiring managers and recruiters.

10. What is Record level Security?

An object can be restricted to specific users, but they can view the individual records of that object. The review of each interviewer can be viewed and edited by the interviewer who wrote it, but the review of any other interviewer cannot be seen or edited. These four methods can be used to manage access at the record level.

• Organization-wide defaults
• Role hierarchies
• Sharing rules
• Manual sharing
• Apex Managing sharing

11. What are Organization-wide Defaults?

Salesforce’s Organization-Wide Defaults (OWD) defines the level of access that the most restricted user should have. Access is restricted using Organizational Wide Defaults. In addition to sharing rules, role hierarchies, sales teams and account teams, manual sharing, and Apex sharing, you can also grant access through other means. A default level of access to other users’ records is defined by Organization-Wide Defaults (OWD).

12. What are Role Hierarchies?

Users higher in the hierarchy have access to all records owned by users below them. It’s not necessary to have a perfect match between your role hierarchy and your organization chart. Each role in the hierarchy should represent a level of access to data that a user or group of users requires.

13. What are Sharing Rules?

For certain groups of users, Sharing Rules are automatic exceptions to organization-wide defaults that allow them to access records they don’t own or have access to normally. The purpose of sharing rules, like role hierarchies, is to provide additional users with access to records. It is not possible for them to be more strict than the default settings set by your organization.

14. What is Manual sharing?

Records can be shared among users by their owners. A recruiter going on vacation may need to temporarily assign ownership of a job application to another recruiter when manual sharing isn’t automated, like organization-wide sharing settings, role hierarchies, or sharing rules.

15. What is Apex Managing sharing?

The apex managed sharing feature gives you the control you need if sharing rules and manual sharing do not meet your needs. Developers can share custom objects programmatically with apex-managed sharing. In apex-managed sharing, only users with the “Modify All Data” permission can add or change the sharing on a custom object’s record, and the sharing access is maintained across changes in the record owner.

16. How can we perform Object Level Security?

The following sections describe how to implement object-level security.

• Permission Sets.
• Profiles

17. What is Permission Set?

• Users have access to various tools and functions through permission sets, which are collections of settings and permissions. Permission sets contain settings and permissions that are also found in profiles, but they extend users’ functionality without modifying their profiles.
• Using permission sets, you can grant access to the various apps and custom objects in your organization and remove them when no longer needed.
• Multiple permission sets can be assigned to a user, but only one profile can be created.

18. What is Profile?

• Data and features that can be accessed by a user are controlled by their profile. Permissions and settings are stored in a profile. A user’s profile settings determine what data he or she can view, while permissions determine what he or she can do with that data.
• Depending on the settings in a user’s profile, certain apps, tabs, fields, or record types will not be visible to her.
• Users’ profiles determine whether they can create or edit records of a given type, run reports, and customize the app.
• It is common for profiles to match up with users’ job functions (for instance, system administrator, recruiter, or hiring manager), but you can create profiles for anything that makes sense for your Salesforce organization. A user can have only one profile at a time, although a profile can be assigned to many users.

19. What are Standard Profiles?

It’s common for profiles to be defined by a user’s job function, but anything that makes sense in an organization can be used as a profile. Standard profiles are included with the platform. For all the standard objects available on the platform, each standard profile includes a default set of permissions. Some of them are:

• Standard User: This profile has access to most standard objects with reading, Edit, and Delete permissions.
• Read Only: Standard users have the same permissions as read-only users, but read-only users have limited access.
• Marketing User: Permissions of Standard User+ Additional Permissions.
• Contract Manager: Permissions of Standard User + Additional Permissions.
• Solution Manager: Permissions of Standard User + Additional Permissions.
• System Administrator: System Administrators have the most access to data and the greatest ability to customize Salesforce. Besides the “View All Data” permission, the System Administrator profile also has the “Modify All Data” permission.

Most profiles, except those with modify all data permission, do not give access to a custom object when it is created.

20. How does the “View all” and “Modify all” permission work?

• Permissions to view all and modify all are usually assigned to system administrators. The “View All” or “Modify All” permission for an object on a profile or permission set grants all associated users access to all records of that object regardless of sharing or security settings.
• Basically, the “View All” and “Modify All” permissions ignore the sharing model, role hierarchy, and sharing rules that are respected by the “Create,” “Read,” “Edit,” and “Delete” permissions. As well as mass transferring, mass updating and mass deleting records of that specific object, “Modify All” allows a user to approve such records even if he or she is not designated as an approver.
• Because “View All” and “Modify All” let us selectively override the system, responsibilities that are usually reserved for administrators can be delegated to other users in a highly controlled manner.

21. Custom permission sets – what are they?

We currently have many Salesforce features that require access checks to determine which users can access them. Some custom processes and apps are not included in permission sets and profiles. Similar to how you assign user permissions and other access settings, custom permissions let you define access checks which can be assigned to users via permission sets or profiles. 

In apex, you can define access checks that make a button on a Visualforce page available only to users who have the right permissions. A processor app can be revoked at any time by an admin by revoking custom permissions from a profile or permission set.

Below is the logic used to render the page block based on the custom permissions.

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

</apex:pageBlock>

22. Can permission sets be used to restrict permissions for users?

No, permissions are always extended by Permission Sets. Users are not restricted in their permissions.

23. Is a user able to see records with a particular record type if they do not have access to that type?

The record type controls only its visibility on the user interface, not its access. The UI will not allow the user to create records for a record type if the user does not have access to that record type. However, users will be able to view records if they have the appropriate permissions.

24. What is Profile Control?

Profile Control Includes Object Permission, Field Permission, User Permission, Tab Settings, App Settings, Apex class access, Visualforce page access, Page Layouts, Record Types, Login Hours, and Login IP Ranges.

25. What is Permission Set Control?

Permission set controls include Object Permission, Field Permission, User Permission, Tab Settings, App Settings, Apex class access, and Visualforce Page access.

26. How to set Organization-Wide defaults?

Organization-Wide defaults can be set to any of the following three:

• Public Read/Write: All users have access to view, edit, and report on all records.
• Public Read-Only: Records can be viewed and analyzed by all users, but they cannot be edited. Those records can only be edited by the owner and users above them in the hierarchy.
• Private: Users above the record owner in the hierarchy can view, edit, and report on records that are private.

27. What are the types of Sharing Rules?

In Salesforce, there are two types of Sharing Rules:

• Owner Based: Records owned by certain users are shared based on ownership. It is possible to identify owners through public groups, roles, and subordinates.
• Criteria Based: A criteria-based sharing system shares records that meet certain criteria.

28. What are the ways that users can share records in Manual Sharing?

The record can only be shared by these four users:

• Record Owner.
• A user in a role above the owner in the role hierarchy.
• Users granted “Full Access” to record.
• Administrator.

29. What are the Access Levels Provided to Users in Manual Sharing?

Access levels are determined by four access levels

• Full Access: In addition to viewing, editing, deleting, and transferring records, users with full access can also modify them. Sharing access can also be extended to other users by these users. It is not possible for users to grant full access to other users.
• Read/Write: Besides viewing and editing the record, users can add associated records, notes, and attachments.
• Read Only: The record can be viewed, and associated records can be added. It is not possible for them to edit the records or add notes or attachments.
• Private: The record cannot be accessed by users in any way.

30. What is the format of the Username?

Username in Salesforce must be in Email address format and unique.

31. Number of users that can be created at a time in Salesforce?

We can add up to 10 users at a time in Salesforce.

32. SAML – what is it?

The Security Assertion Markup Language is an XML-based framework that dates back to 2001. User authentication and authorization are handled by SAML between service providers and identity providers.

33. What are the reasons why SAML is implemented in organizations?

Every organization operates its functions in the “Cloud” as a result of Cloud Computing. For data to be exchanged between a Service Provider and an Identity Provider, authentication and authorization are required. Our Salesforce.com implementation uses the SAML protocol to implement Single Sign-On (SSO).

34. What are SAML features and benefits?

• The function of Single Sign-on is enabled by it.
• Single logout functionality is enabled by SAML.
• Security Assertion Markup Language uses XML assertion to authenticate and authorize users in Salesforce.

35. What are SAML Components?

The Security Assertion Markup Language (SAML) consists of three components:

• Authentication:– Who is the user.
• Attribute:– Details about User.
• Authorization:– is the user authorized to access.

36. What is Assertion Information?

Assertion contains four important pieces of information.

• IDP provides digital signatures.
• Issuer: The service provider’s name.
• Entity ID: Identifies the service provider
• The Subject: User ID for Salesforce.com.

37. What is SAML Protocol?

Describes how data is transmitted between an Identity Provider and a Service Provider.

38. What is SAML Binding?

Binding in SAML maps protocols.

39. How to configure SAML settings in Salesforce?

To implement Single Sign-On (SSO), we configure SAML settings in Salesforce. In Salesforce, single sign-on can be accomplished in three steps. They are

• Establishing the relation between Salesforce and SAML identity provider.
• Downloading digital certificate.
• Configuring SAML single single-on settings.

40. How does SAML Works?

• Trust is a major component of the Security Assertion Markup Language.
• To establish a connection between Service Provider and Identity Provider in Salesforce.com, Single Sign-on must be enabled.
• The service provider is connected to the identity provider, and the identity provider is connected to the end user in this process.

41. SFDC Public Groups: What are they?

A public group is a collection of users, other groups, roles, and/or roles with their subordinates that all have a common function

42. What is the purpose of public groups in Salesforce?

Salesforce uses public groups to define sharing rules.

43. What is the process for creating public groups in Salesforce?

In Salesforce, public groups are used to extend sharing rules beyond Role hierarchies. Let’s create a public group with different users who have different profiles and roles.

Step 1: Create a public group by logging into Salesforce and going to Administer | Manage users | Public groups.

Step 2: Go to Public groups and click the New button.

Step 3: Type the Public label group.

Step 4: Give the group a name.

Step 5: Select members from Available members and add them to the selected member’s list.

Step 6: Press the Save button.

44. What are the Different Sharing Rule components in Salesforce?

There are three types of sharing rule components in Salesforce:

• Share with records.
• With which Users.
• What kind of access.

45. What are the sharing rule types in Salesforce?

In Salesforce, there are two types of rules.

• Based on the record owner.
• Based on criteria.

46. What are the Different Page Types in Salesforce?

Basically, there are three types of page types in Salesforce:

• Home Page.
• Detail Page and.
• Edit page.

47. What is Home Page?

As soon as we click on the object tab, we are taken to the Home Page by default.

48. What is the Detail page?

When we click on a record, we are taken to the Detail Page. Details about a record can be found on the detail page. Trying to edit a record in the detail page takes us to the edit page.

49. What is Edit Page?

On the Edit page, all fields that require user input are displayed.

50. What are Different Page Elements in Salesforce.com?

Salesforce has the following page elements.

• Tag.
• Feed.
• Sidebar.
• Section.
• Links.
• Related List.

51. What is a Tag?

Users can add short phrases or words to most Salesforce records and personal information by using Tags.

52. What is a Feed?

Whenever a record or field is updated, feeds are automatically generated.

53. What is a Sidebar?

It offers the option to create new items, recent items that we have accessed, and the recycle bin.

54. What is a Section?

Several fields can be grouped together in a section of the page.

55. What is a Link?

Salesforce provides easy access to related lists through links.

56. What are related lists?

The related list is a visual representation of the relationship between one object and another.

57. What are the types of Sharing Rule?

Rules for sharing can be divided into three types. They are

• Manual Sharing.
• Automatic Sharing.
• Guest user access, based on criteria

58. What does Field Dependency mean?

There are two fields in Field Dependency: the controlling field and the dependent field. Dependent picklist values are controlled by the controlling field when a selection is made.

59. What is the process for triggering the Sharing rule of a Formula field?

You can’t use formula fields in the sharing rule criteria, but you can replace the formula field with a regular field and put the formula that populates it in a workflow that fires whenever an object is created or edited. That way, you’ll have a regular field with the same value as the formula field.

60. In Visual Force, how many field dependencies can we use?

Visualforce pages allow us to use up to ten field dependencies.

61. For standard objects, is it possible to bypass Grant Login access using Hierarchies?

No, it is possible to bypass Grant Login access using Hierarchies in the case of standard objects.

62. How can we Control Field level Security?

Profiles and permission sets can be used to control Field Level Security.

Profiles:

• Page Layouts, IP Ranges, Login Hours, Desktop, Client Access.

Permission sets:

• App Permissions, Record Types, Tab Settings, Assigned Apps, Object Permissions, Field Level Security, Apex Classe, Visual Force Pages. 

63. Is it possible to have a sharing rule on a custom object on the detail side?

In a master-detail relationship, custom objects cannot have sharing rules, manual sharing, or queues because these require the Owner field.

64. Login hours and IP ranges: what are they?

• Users who attempt to log in before or after the login hours are restricted in an organization. An organization’s login hours can be set by going to Setup=>Administration=>Manage users=>Profiles.
• Login attempts from unknown IP addresses are restricted by IP ranges. Login IP ranges are usually maintained by organizations. Login IP ranges can be set in Salesforce by going to Setup=>Administration Setup=>Manage Users=> Profiles.

65. When I navigate to fields on Account Object, I cannot find the list of Person Account fields in Field Level Security (FLS) settings?

Contact fields control Field Level Security (FLS) of Person Account fields. To set FLS for Person Account Fields, navigate to fields of contact, and it will be reflected on Person Account.

66. User Records: What are they?

The user record contains key information about the user.

67. Explain Apex Sharing?

A shared object must be associated with the standard or custom object for which you want to share in order to access sharing programmatically. The AccountShare object is the sharing object for the Account object, and the ContactShare object is the sharing object for the Contact object. Moreover, all custom object sharing objects are named as follows, where MyCustomObject is the custom object’s name:

MyCustomObject__Share

All three types of sharing are supported by a share object:

• managed sharing
• user managed sharing
• Apex managed sharing

68. Record owners: what are they?

Ownership of a record refers to the User or Queue who controls it and has access to it.

Owners generally fall into two categories. They are

• Users.
• Queues.

69. Apex Managed Sharing: What are some considerations?

It is only possible to add or change apex managed sharing on a record if the user has the “Modify All Data” permission.

70. What are the best practices for creating contact sharing rules?

For red, write, and read/write permissions, organization-wide default settings are used

71. How should sharing objects be considered?

There is no sharing object associated with objects on the detail side of a master-detail relationship.

It is not possible for us to create a “__share” object on our own. We create it ourselves with the help of the system. Objects with “Public Read/Write” sharing settings will not create “__share” objects because there is no scope of sharing, all records are open to anyone in the organization. If the sharing setting of an object is either “Public Read Only” or “Private,” then the system automatically creates a “__share” object.

72. Governor limits: what are they?

In Salesforce.com, governor limits are runtime limitations enforced by the Apex runtime engine.

73. The OWD of the case object is set to private. All cases should now be visible to anyone without changing OWD, regardless of hierarchies, such as top-down (for example, managers can see lead cases), horizontal (for example, leads can see manager cases), or cross-functional. What makes this possible?

Assign “Roles and subordinates” access to the head of the department so that everyone can access cases regardless of their hierarchy.

74. Is it possible to restrict access to data using sharing rules?

It is not possible to restrict data access using sharing rules.

75. How do sharing objects differ from other objects?

The level of access that the specified user or group has been granted to a shared object

The following values are valid:

• Edit, Read, All.
• ParentID: The object’s ID. There is no way to update this field.
• RowCause: The reason for granting access to the user or group. Sharing records is controlled by the type of sharing, which determines who can alter them. It is not possible to update this field.
• UserOrGroupId: The user or group IDs you are granting access to. There are several types of groups:
  • Associated with a role, a public group, or a sharing group.
  • Groups based on territories.

76. Is there anything to consider when sharing apex data?

There is no sharing object associated with objects on the detail side of a master-detail relationship. Details record access is determined by the master’s sharing object and the relationship’s sharing settings.

77. When apex runs, what mode does it use?

Generally, the apex runs in the system context, so permissions and field-level security of the current user are not taken into account. In order to avoid sharing rules from being enforced, the class must be declared without sharing keywords.

Only Apex code executed with the executeAnonymous call and Connect in Apex are exceptions to this rule. A user with full permissions always executes executeAnonymous. Detailed information about executeAnonymous can be found in Anonymous Blocks.

78. When users share, what effect does it have on their permission and FLS?

The with sharing keyword does not enforce the user’s permissions or field-level security when enforcing sharing rules. Code in apex has access to all fields and objects in an organization, so it won’t fail to run because of hidden fields or objects.

79. What is the purpose of stripInaccessible?

• Data protection can be enforced at the field and object levels by using the stripInaccessible method. Query and subquery results can be stripped of fields and relationship fields that the user cannot access using this method.
• Furthermore, this method can be used to sanitize sObjects deserialized from untrusted sources by removing inaccessible sObject fields before DML operations.
• In the context of the specified operation-create, read, update, or upsert-the access check is based on the field-level permission of the current user. If a field in the source record does not meet the field-level security check for the current user, then the stripInaccessible method checks it for the current user.
• Also, the method checks the source records for lookup fields or master-detail relationship fields that aren’t accessible to the current user. A return list of sObjects is created that is identical to the source records, except that the inaccessible fields are removed.

80. Is stripInaccessible compatible with AggregateResult objects?

AggregateResult SObjects cannot be stripped inaccessible by the stripInaccessible method. An exception is thrown if the source records are of the AggregateResult SObject type.

81. What is the process for recalculating apex-managed sharing?

• You must write an Apex class to recalculate Apex-managed sharing. Salesforce provides the Database. Batchable interface for this class.
• All batch Apex processes, including recalculating apex-managed sharing, use the Database.Batchable interface.

82. User Managed Sharing: What is it?

• Using User Managed Sharing, a user with full access to the record shares the record with others, but when the record owner changes, the record is removed from Sharing. 
• When Apex sharing is set to “Manual” on RowCause, a record will be removed from the sharing table when its owner changes.
• Apex Sharing Reason needs to be defined on Rowcause that is used for Apex Sharing in order to resolve this issue.

83. What is Apex Sharing for Standard Objects?

Apex Sharing Reason is not supported by standard objects. By default, you must define RowCause as “Manual” when sharing standard object records.

84. When it comes to apex-managed sharing versus with sharing, what is the difference?

To grant access to records, Apex Managed Sharing is used. Basically, it involves configuring sharing rules grammatically. To respect the current user sharing rules, the keyword “With Sharing” is used.

85. When using apex-managed sharing, what should be considered?

• Shared records created through apex-managed sharing are maintained if the record owner changes, but records shared manually will be lost if the owner changes.
• Share table records can only be added, edited, or deleted by users with “modify All Data” rights.

86. Manual sharing has limitations; what are they?

• Organization-Wide Defaults cannot be stricter than Manual Sharing.
• Individual records can be shared manually, but not all records of an object.
• OWD only applies to records with Private or Public Read Only Access.
• Users and administrators should define if related records were protected when setting Automatic and Manual Sharing.

87. What is With sharing and without sharing?

With Sharing means that the security settings of the current user will be taken into consideration when you declare a class as With Sharing. It pertains to respecting OWDs and sharing rules only. With “with sharing,” we cannot “automatically” enforce field-level security or profile permissions.

A Without Sharing Apex class runs in system mode, which means Apex code can access all objects, fields, and permissions regardless of the current user’s sharing rules, field level security, or object permissions. 

88. What is the difference between a role and a profile?

• By using profiles, you can control object privileges such as CRED (Create, Read, Edit, Delete). Additionally, they contain system permissions, such as exporting data, that a user can access.
• Records can be shared across an organization with the help of roles. Users can access records owned by people lower down in the hierarchy through hierarchical systems.
• It is possible for a user to have only one Profile and Role.

89. Difference between public group and queue?

Queues: Used to assign records to groups of users. Using queues, we can assign a record to multiple users (so that anyone in the queue can work on it). Additionally, it allows users to customize their views.

• Load balancing is achieved with it
• For Custom objects, as well as for Case, Lead, and Knowledge Article versions, it can be created

Public Group: These users are related to a team or group and are used to share data. Records are not owned by them (like queues), but they can share them (in terms of access).

• It is possible to create public groups across all objects.

90. A can see B data, but B cannot see A data. Why?

The following conditions must be met

• Are both users using the same profile?
• Role Hierarchy of A and B should be checked.
• Sharing rule should be checked

91. How does TOTP work?

One-time passwords that are time-based are called TOTPs. With Salesforce’s two-factor authentication method, we can enhance TOTP authentication with a two-factor authentication flow. Based on a shared secret key and the current time, the TOTP algorithm computes a one-time password.

To generate a TOTP token, users can use a time-based authentication application (such as Salesforce Authenticator or Google Authenticator).

92. In Accounts, User A has the CLONE button visible, but User B does not. Why is that?

The following conditions must be met

• Do both users have the same profile?
• There is no Custom Permission Set assigned to any user
• Do you have record types for the Account Object and associated page layouts for those Record Types
• You have checked the page layout, and the Clone button has been added to the Page Layout.

93. A and B share the same profile and role. Is it possible to restrict records from A to B and vice versa?

Make sure that the view all data permission is set to ‘false’ in the profile. In this way, other users’ data will be restricted from being accessed by the user.

94. The number of users is 100. The records can be read by 90 users, but they cannot be updated by 10 users?

You need to create two profiles:

• Add 90 users to the first profile and give them read permission.
• Add 10 users and give them read and edit permissions in the second profile.

95. OWD types: what are they?

• Private
• Public read-only
• Public read and write
• Public read/write/transfer

96. How does the OWD model differ from other models?

By restricting Access, OWD reduces the number of users. It is not possible to open Access

97. All data is seen by one user under one profile, and there are five users under one profile. The account is private. Why is that?

Permission is set with a view all access to accounts can be created and assigned to specific users.

98. What is OWD, and why it’s needed?

By default, OWD is applied to the entire organization. For securing records at the level of the record, this method is used. This is a basic security measure. The most restrictive access is given to the record, then we can open it up with role hierarchy, sharing rules, and manual sharing.

Public Full Access:

• Only the Campaign Object can be set as a full public action.
• The user can search records, view reports and records, add related records, edit details of the record, and delete the record through public access.

Read/Write/Transfer:

• Only Leads and Cases have the Read/Write/Transfer option.
• Case and lead objects can be set to Private, Public Rad only, Public Read/Write, and Public/Read/Write/Transfer.
• All users can view, edit, transfer, and report on the case and lead records when they are set to public/Read/Write/Transfer.

Public Read/Write:

• Users can view, edit, and report on all records when they are set to Public Read/Write.

Public Read Only:

• Whenever a record is set to public Read-only, the user can search the records and view and report on them, but they cannot edit them.
• Users and owners of records can edit those records.

Private:

• Records set to private can only be viewed, edited, and reported upon by the record owner and users above them in the hierarchy.

No Access, View only, Use:

• The option is only available for Price books. The access level for price book OWD settings can be set to No Access, View Only, or Use.
• The default access level for price book gives users access to price book information and allows them to use that information for opportunities with products.
• It allows users to access price book information but not to use it in product opportunities.
• Information and prices in the price book cannot be accessed by users with No Access.

99. Shield Platform Encryption: What is it?

• With Shield Platform Encryption, you can protect your data while maintaining critical platform functions. You can encrypt sensitive data both at rest and while it is being transmitted.
• Salesforce’s Shield Platform Encryption complements its out-of-the-box data encryption options. Several standard and custom fields, files, and attachments are encrypted using an advanced HSM-based key derivation system, so data is protected even if other defenses have failed.
• Data encryption keys are never stored or shared between organizations. Rather, it is derived on demand from a master secret and your organization’s tenant secret and cached on an application server.

100. What is the best way to track whether a field is encrypted or not?   

A user who is authorized to access the record will see the data normally. In order to find out whether or not the fields are encrypted, we need to track their encryption status. We can check the filed information from Workbench first.

WorkBench:

• Access the Workbench by logging in
• Click on Info-> Standard & Custom Objects -> Select the object you want
• Then expand the Fields folder -> Select the encrypted field. Details will show Encrypted as true.

By Destroying the Tenant Key:   

• As a result of destroying the tenant key, you will be able to view the result of the encrypted fields directly at the record level. The tenant key can be imported to gain access to encrypted fields again.

Encryption Statistics:

• Using Encryption Statistics, you can see how much data has been encrypted by Shield Platform Encryption and how much data has been encrypted by an active tenant secret.
• Settings -> Platform Encryption -> Encryption Statistics

101. What is the difference between Classic Encryption and Shield Encryption?

Shield Platform Encryption allows you to encrypt a wide variety of widely used standard fields, as well as some custom fields and files. Additionally, Shield Platform Encryption supports personal accounts, cases, searches, approval processes, and other Salesforce features. You can protect only a specific type of custom text field with classic encryption.

102. Implicit sharing – what is it?

Automatic sharing occurs implicitly. As it is native to the platform, you cannot turn it off or on.

Parent implicit sharing:

• Provide read-only access to parent records (Account only) if the user has access to children’s records, such as Opportunities, Cases, or Contacts. A child record does not necessarily have to belong to the user who owns the parent record.
• Using a record from another object (other than an opportunity, case, or contract) that has a lookup to an Account, the user will only see the Account Name and will not be able to access the Account detail – such as a lookup to the parent account, where the child account owner will only see the Parent Account Name.

Child Implicit Sharing:

• Account owners can access child records (contacts, opportunities, and cases), even if they do not own them. A child record’s access level is determined by the account owner’s role (read-only or read/write).

103. System.RunAs – what is it?

All Apex code runs in system mode, which ignores the current user’s permissions and record sharing. With runAs, we can write test methods that change the user context to a new or existing user so that the user’s record sharing is enforced.

Only record sharing is enforced by the runAs method, not a user or field permissions. We can only use runAs in test methods.