Blog

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.

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.

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.

Only the following fields are automatically indexed in Salesforce:

• Primary keys (Id, Name and Owner fields).
• Foreign keys (lookup or master-detail relationship fields).
• Audit dates (such as SystemModStamp).
• Custom fields marked as an External ID or a unique field.

Their benefit is that they enable developers to create multilingual applications which automatically presents information in a user’s native language.

You can create up to 5,000 custom labels for your organization, and they can be up to 1,000 characters in length.

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.

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.

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.

• Primitive types
• Collections
• sObjects
• User-defined types
• Built-in Apex types