A sandbox is a copy of the production environment/ org, used for testing and development purposes. It’s useful because it allows development on Apex programming without disturbing the production environment.

Sharing rules are written to give edit access (public read and write) or public read only access to certain individuals in Salesforce org. A classic example is when: – only your managers or superiors need to be given extra credentials to your records in objects as compared to your peers.

By default, all users in your organization will have organization-wide-default sharing settings of either Public Read Only or Private.

To give access to more records, which users do not own, we write sharing rules.

Example: Sharing rules are used to extend sharing access to users in public groups or roles. Hence, sharing rules are not as strict as organization-wide default settings. They allow greater access for those users.

As far as the second part of the question is concerned, the answer is no. We cannot use sharing rules to restrict data access. It is only used for allowing greater access to records.

A bucket field lets you group related records together by ranges and segments, without the use of complex formulas and custom fields. Bucketing can thus be used to group, filter, or arrange report data. When you create a bucket field, you need to define multiple categories (buckets) that are used to group report values.

The advantage is that earlier, we had to create custom fields to group or segment certain data.

Before we understand dynamic dashboards, let us first understand static dashboards. Static dashboards are the basic dashboard types that will be visible to any user who has made a report out of his data. An example of this is what a Sales manager/ Marketing manager would be able to see on his Salesforce org. In other words, a normal dashboard shows data only from a single user’s perspective. Now comes the concept of dynamic dashboards.

Dynamic dashboards are used to display information which is tailored to a specific user. Let us consider the same example as above. In case the Sales manager wants to view the report generated specific to only one of his team members, then he can use dynamic dashboards.

You can use dynamic dashboards when you want to show user-specific data of a particular user, such as their personal quotas and sales, or number of case closures, or leads converted etc.

You can also use a normal/ static dashboard when you want to show regional or organization-wide data to a set of users, such as a particular region’s sales number, or a particular support team’s performance on case closures.

As far as the second part of the question is concerned, no we cannot schedule a dynamic dashboard. That is because whenever we open the dashboard, it will show the data generated in real-time.

No list of Salesforce interview questions is complete without involving relationships between objects in Salesforce. Relationships in Salesforce can be used to establish links between two or more objects.

The different types of object relationships in Salesforce are:

Master-Detail Relationship (1:n): It is a parent-child relationship in which the master object controls the behavior of the dependent child object. It is a 1:n relationship, in which there can be only one parent, but many children.The main concept you need to be know is that, being the controlling object, the master field cannot be empty. If a record/ field in master object is deleted, the corresponding fields in the dependent object are also deleted. This is called a cascade delete. Dependent fields will inherit the owner, sharing and security settings from its master.You can define master-detail relationships between two custom objects, or between a custom object and standard object as long as the standard object is the master in the relationship.

Lookup Relationship (1:n): Lookup relationships are used when you want to create a link between two objects, but without the dependency on the parent object. Similar to Master-Detail relationship, you can think of this as a form of parent-child relationship where there is only one parent, but many children i.e. 1:n relationship.

The difference here is that despite being controlling field, deleting a record will not result in automatic deletion of the lookup field in the child object. Thus the records in the child object will not be affected and there is no cascade delete here. Neither will the child fields inherit the owner, sharing or security settings of its parent.

Junction Relationship (Many-To-Many): This kind of a relationship can exist when there is a need to create two master-detail relationships. Two master-detail relationships can be created by linking 3 custom objects. Here, two objects will be master objects and the third object will be dependent on both the objects. In simpler words, it will be a child object for both the master objects.

Yes. You can have a roll-up summary in case of a master-detail relationship. But not in case of a lookup relationship.A roll-up summary field is used to display a value in a master record based on the values of a set of fields in a detail record. The detail record must be related to the master through a master-detail relationship.

There are 4 calculations that you can do using roll-up summary field. You can count the number of detail records related to a master record. Or, you can calculate the sum, minimum value, or maximum value of a field in the detail records.

“Data skew” is a condition which you will encounter when working for a big client where there are over 10,000 records. When one single user owns that many records we call that condition ‘ownership data skew’.

When such users perform updates, performance issues will be encountered because of “data skew”. This happens when a single user/ members of a single role own most of the records for a particular object.

As mentioned in one of the previous Salesforce interview questions, a profile will ultimately control access to which records a user has in a Salesforce org. No user can work on the Salesforce org without being assigned a profile. The Profile is therefore mandatory for every user.

Role however is not mandatory for every user. The primary function of the Role/ Role hierarchy is that it allows higher level users in hierarchy get access to records owned by lower level users in the hierarchy. An example of that is Sales Managers getting access to records owned by Sales Reps while their peers do not get access to it.

Before I mention some of the examples, let me give you an introduction to deterministic and non-deterministic formula fields. Formula fields whose value will be static are referred to as deterministic fields. Whereas, formula fields whose value will be changed dynamically or whose values will have to be calculated on the fly, they are referred to as non-deterministic formula fields. A classic example of that is a formula returning the current date and time.

An external ID is a custom field which can be used as a unique identifier in a record. External IDs are mainly used while importing records/ data. When importing records, one among the many fields in those records need to be marked as an external ID (unique identifier).

An important point to note is that only custom fields can be used as External IDs. The fields that can be marked as external IDs are: Text, Number, E-Mail and Auto-Number.

Standard controller in Apex, inherits all the standard object properties and standard button functionality directly. It contains the same functionality and logic that are used for standard Salesforce pages.

Custom controller is an Apex class that implements all of the logic for a page without leveraging a standard controller. Custom Controllers are associated with Visualforce pages through the controller attribute.