Interview Questions

Explain Dynamic Dashboard.?

Answer :

Dynamic dashboards in Salesforce displays set of metrics that we want across all levels of your organization.

Dynamic Dashboards in salesforce are Created to provide security settings for the dashboards in salesforce.com. We may have a requirement in an organization to “view all data” by every user in an organization according to their access we have to select Run as Logged-in User. There are two setting option in Dashboards. They are

1.Run as specified User.
2.Run as Logged-in User.

Which Permission Is Required To Set The Running User Other Than You In Dashboard?

Answer :

The user must have “View All Data” permission is required to set the running users.

Can We Schedule Dynamic Dashboards?

Answer :

No, we can not schedule dynamic dashboards for refresh. It must be done manually.

What Is Analytical Snapshot In Salesforce.com ?

Answer :

Analytical Snapshot in Salesforce are used to create reports on historical data.

What Is The Use Of “floating Report Header”?

Answer :

Floating report headers enables us to display the column header visible on each page when we scroll the report page.

1. How To Clear The Time Based Workflow Action Queue?

   Answer :
   We can clear time based workflow action queue in two ways they are
   1.Make the criteria false.
   2.Removing scheduled actions from the queue.

2. We Have “time Based Workflow” And There Is Action Scheduled To Be Executed. Can We Delete That Workflow?

   Answer :
   It is not possible to delete the workflow when the workflow is having any pending time dependent actions.

3. We Have A “time Based Workflow” And There Is Action Scheduled To Be Executed. If We Deactivate The Workflow, Scheduled Actions Will Be Removed From Queue Or Not?

   Answer :
   Even after deactivating the the workflow, its action will not be removed. It’s still active in queue.
   What is the maximum size of the PDF generated on visualforce attribute renderAs?
   15
   What is sharing rule?
   If we want to give the access to other users we use sharing rules.
   How many ways we can share a record?
   Role Hierarchy:
   If we add a user to a role, the user is above in the role hierarchy will have read access.
   Setup -> manage users -> roles -> setup roles -> click on ‘add role’ -> provide name and save.
   OWD:
   Defines the base line setting for the organization.
   Defines the level of access to the user can see the other user’s record
   OWD can be Private, Public Read Only, Public Read and Write.
   Setup -> Security Controls -> sharing settings -> Click on ‘Edit’
   Manual Sharing:
   Manual Sharing is sharing a single record to single user or group of users.
   We can see this button detail page of the record and this is visible only when OWD setting is private.
   Criteria Based Sharing rules:
   If we want to share records based on condition like share records to group of users
    Whose criteria are country is India.
    Setup -> security controls -> sharing settings -> select the object and provide name and
    Conditions and save
   Apex sharing:
   Share object is available for every object(For Account object share object is AccountShare ). If we want to share the records using apex we have to create a record to the share object.
   
   
    
   
   

Custom Settings

    Custom settings are similar to custom objects and enable application developers to create custom sets of data, as well as create and associate custom data for an organization, profile, or specific user. All custom settings data is exposed in the application cache, which enables efficient access without the cost of repeated queries to the database. This data can then be used by formula fields, validation rules, flows, Apex, and the SOAP API.

There are two Types of Custom settings
List Custom Settings : A type of custom setting that provides a reusable set of static data that can be accessed across your organization. If you use a particular set of data frequently within your application, putting that data in a list custom setting streamlines access to it.

Hierarchy Custom Settings :A type of custom setting that uses a built-in hierarchical logic that lets you “personalize” settings for specific profiles or users. The hierarchy logic checks the organization, profile, and user settings for the current user and returns the most specific, or “lowest,” value. In the hierarchy, settings for an organization are overridden by profile settings, which, in turn, are overridden by user settings
More info: http://goo.gl/c7Dv17

   Custom objects are custom database tables that allow you to store information unique to your organization. For custom objects, the custom flag—a Boolean field in the describe results—is true.
Client applications with sufficient permissions can invoke API calls on existing custom objects. You can create new custom objects with the user interface, or by using the metadata WSDL with a client application or using the Force.com IDE.


Difference between Custom Object and Custom Settings 

        In some ways, Custom Settings look very much like Custom Objects. In fact, if you use a tool like the Data Loader to view a list of objects in your org, you’ll see that Custom Settings are listed together with Custom Objects, without any visible distinction between the two. However, while both Custom Objects and Custom Settings allow you to define Custom Fields, there are some important differences.

Limited field types – Custom Settings support only Checkbox, Currency, Date, Date/Time, Email, Number, Percent, Phone, Text, Text Area, and URL field types. Most notably absent are Formula and Picklist, as well as field types that define relationships to other objects, like Lookup and Master/Detail. You can’t create lookups from Custom Objects to Custom Settings either.

No validation rules – You can’t define validation rules on Custom Settings.

No workflow or triggers – You can’t define workflow rules or triggers on a Custom Setting. Any validation of data, update of related records, or other actions that you might use workflow or a trigger to perform for a Custom Object have to be implemented differently for a Custom Setting.

No page layouts or record types – You can’t re-arrange fields on the page layout for Custom Settings. Custom Settings aren’t really intended to be visible to every-day users. If you need them to be, you can create Visualforce pages to allow users to view and manipulate Custom Setting data.

Advantages of Custom Settings over custom object
Avoiding Governor Limits
Hierarchical Access to Data

Use Of Custom Setting Methods:

       All custom settings data is exposed in the application cache, which enables efficient access without the cost of repeated queries to the database. However, querying custom settings data using Standard Object Query Language (SOQL) doesn't make use of the application cache and is similar to querying a custom object. To benefit from caching, use other methods for accessing custom settings data such as the Apex Custom Settings methods. 

 Important Poins:

1. List Custom settings can not be used in Formula field  Validation Rule, Process Builder and Workflow Rules.

2. You can access only Hierarchy type of custom setting in Validations, Formula Fields, Process Builder and Workflow Rules.
3. We can not do DML operations on Custom Settings

Example:

http://www.jitendrazaa.com/blog/salesforce/use-hierarchy-custom-settings-to-avoid-hard-coding-in-formula-field-custom-button-process-builder-or-workflow-rules/

 Custom Setting Examples:

        The following example uses a list custom setting called Games. Games has a field called GameType. This example determines if the value of the first data set is equal to the string PC.

1	List<Games__C> mcs = Games__c.getall().values();

2	boolean textField = null;

3	if (mcs[0].GameType__c == 'PC') {

4	textField = true;

5

}

6	system.assertEquals(textField, true);

The following example uses a custom setting from Country and State Code Custom Settings Example. This example demonstrates that the getValues and getInstance methods list custom setting return identical values.

view sourceprint?

1	Foundation_Countries__c myCS1 = Foundation_Countries__c.getValues('United States');

2	String myCCVal = myCS1.Country_code__c;

3	Foundation_Countries__c myCS2 = Foundation_Countries__c.getInstance('United States');

4	String myCCInst = myCS2.Country_code__c;

5	system.assertEquals(myCCinst, myCCVal);

The following are instance methods for list custom settings.

• getAll()
  Returns a map of the data sets defined for the custom setting.
• getInstance(dataSetName)
  Returns the custom setting data set record for the specified data set name. This method returns the exact same object as getValues(dataSetName).
• getValues(dataSetName)
  Returns the custom setting data set record for the specified data set name. This method returns the exact same object as getInstance(dataSetName).
•  
• The following are instance methods for hierarchy custom settings.
  • getInstance()
    Returns a custom setting data set record for the current user. The fields returned in the custom setting record are merged based on the lowest level fields that are defined in the hierarchy.
  • getInstance(userId)
    Returns the custom setting data set record for the specified user ID. The lowest level custom setting record and fields are returned. Use this when you want to explicitly retrieve data for the custom setting at the user level.
  • getInstance(profileId)
    Returns the custom setting data set record for the specified profile ID. The lowest level custom setting record and fields are returned. Use this when you want to explicitly retrieve data for the custom setting at the profile level.
  • getOrgDefaults()
    Returns the custom setting data set record for the organization.
  • getValues(userId)
    Returns the custom setting data set record for the specified user ID.
  • getValues(profileId)
    Returns the custom setting data set for the specified profile ID.