Explain about “Too Many SOQL Error: 101”

Error: System.LimitException: Too many SOQL queries: 101

Too many SOQL queries: 101

“System.LimitException: Too many SOQL queries: 101” errors occur when you exceed SOQL queries governor limit. Actuval limit is “you can run up to a total 100 SOQL queries in a single call or context”.

Ho to resolve this “Error: System.LimitException: Too many SOQL queries: 101”

  • Change your code by fallowing apex code best practices so that the number of SOQL fired is less than 100.
  • If you need to change the context, you can use @future annotation which will run the code asynchronously.

Apex runs on a multi-tenant platform, the apex run time engine strictly enforces limits to ensure code does not monopolize shared resources.

  • Avoid SOQL queries in for loops.
  • Fallow Apex code key principals while writing Triggers and bulk requests.

Reference for Apex code best practices: https://developer.salesforce.com/page/Apex_Code_Best_Practices

Explain about Asynchronous Apex in Salesforce?

Asynchronous Apex Salesforce

Asynchronous Apex

Asynchronous Apex is used to run process in a separate thread at later time. It is process or function that executes a task “in the back ground” without the user having to wait for the task to finish.

We can typically use asynchronous process for callouts to external systems, operations that require higher limits, and code that needs to run at a certain time.

Benefits of Asynchronous process are User efficiency, Scalability and higher limits.

There different ways to implement Asynchronous process in Apex.

  1. Future methods
  2. Batch Apex
  3. Queueable Apex
  4. Scheduled Apex

To know more about Asynchronous Process refer this URL: https://trailhead.salesforce.com/trails/force_com_dev_intermediate/modules/asynchronous_apex/units/async_apex_introduction

What is Platform Cache in Salesforce?

Platform Cache – Salesforce

What is a Cache? Cache is a temporary storage for frequently accessed data from a database

What is Platform Cache? It is a memory layer that stores Salesforce session and org data for later access. When you use Platform Cache, your applications can run faster because they store reusable data in memory. Applications can quickly access this data; they don’t need to duplicate calculations and requests to the database on subsequent transactions. In short, think of Platform Cache as RAM for your cloud application.

Types of Platform Cache:

  1. Org Cache: Org Cache stores org-wide data that anyone in the org can use. Org Cache is accessible across sessions, requests, and org users and profiles.
  2. Session Cache: Session Cache stores data for an individual user and is tied to that user’s session. The maximum life of a session is 8 hours.

What is Cache Partition? Cache partition allows you to allocate space to balance usage and performance across apps. Caching data to designated partitions ensures that the cache space isn’t overwritten by other apps or by less critical data. Before you can use cache space in your org, you must create partitions to define how much capacity you want for your apps. Each partition capacity is broken down between org cache and session cache.

Cache allocation by edition: Platform Cache is available to customers with Enterprise Edition orgs and above.

Enterprise Edition – 10 MB by default, Unlimited Edition – 30 MB by default, Performance Edition – 30 MB by default.

Future method in salesforce – @future

Explain about future method in salesforce?

Future method in salesforce: Future methods are used to run the process in a separate thread, at later time when system resources are available. We can use future methods for any operation we would like to run asynchronously in its own thread.

Future methods provide the benefits of not blocking the users from performing other operations and providing higher governor and execution limits for the processes.

Future method syntax:

  • Use @future annotation before method declaration.
  • Future methods must be static methods, and can only return a void type.
  • The specified parameters must be primitive data types, arrays of primitive data types, or collections of primitive data types.
  • Future methods can’t take standard or custom objects as arguments.
  • A common pattern is to pass the method a list of record IDs that you want to process asynchronously.

global class YourClassName {


  public static void yourFutureMethodName(List<Id> recordIds) {

    List<Account> acc = [Select Id, Name from Account Where Id IN :recordIds];

    // process account records to do awesome stuff



Best practices to implement future methods:

  • Ensure that future method execute as fast as possible.
  • If using webservice callouts, try to bundle all callouts together from same future method, rather than using a separate future method for each callout.
  • Conduct thorough testing at scale. Test that a trigger enqueuing the @future calls is able to handle a trigger collection of 200 records. This helps determine if delays may occur given the design at current and future volumes.

 Consider using Batch Apex instead of future methods to process large number of records asynchronously. This is more efficient than creating a future request for each record.

To know more,  refer below Salesforce Trailhead URL.


New analysis in Salesforce Optimizer Reports

New analysis in Salesforce Optimizer Reports – Summer’17 release

What is Salesforce Optimizer? Optimizer evaluates your implementation to determine how your company uses certain Salesforce features, then identifies ways that you can improve your implementation for your company.

Optimizer provides analysis report on Storage, Fields, custom code, Custom Layouts for objects, Reports and dashboards, validation rules, sharing rules, workflow rules, User Management and profiles and permission sets.

Below are the additional items added to Salesforce optimizer reporting with summer’17 release.

   – File storage limits

   – Data storage limits

  – New Apex and visualforce code that’s running out-of-date API versions

   – Page Layouts that are not assigned to record types and record types that are not added to profiles

   – Roles that are not assigned to roles.

   – User who access Salesforce on unsupported browsers

   – Checks for reports and dashboards that have not been run more than a year.

Hide Option to Switch to Salesforce classic

Hide Option to Switch to Salesforce classic – Summer’17 feature

Hide Option to Switch to Salesforce classic, Salesforce has provided this feature in Summer’17 to hide Switch to Salesforce classic option in setup menu.

To enable this, go to profiles and permission sets and enable “Hide Option to Switch to Salesforce classic” permission. We can enable this if we are ready to enable lighting version without looking back to salesforce classic version.

Generally, when we enable lightning version, users will get switcher option to switch between two user interfaces (Salesforce classic and lightning). If you want some users or all users stick to lightning version, you can use this feature to remove switcher.

Below are considerations we must keep in mind when we enable this feature.

If users access features that aren’t available in Lightning Experience, they temporarily access Salesforce Classic in a new browser tab, even though the permission is enabled. They use Salesforce Classic only as long as they’re using a feature that’s not available in Lightning Experience.

The permission doesn’t affect the full site link in the Salesforce1 mobile browser app. Salesforce1 users always switch to the Salesforce Classic version of the full site, regardless of the interface they see from desktop devices.

Refer salesforce summer’17 release notes for more details.


Filed history related lists in Lightning experience

Filed history related lists in Lightning experience – Available with Summer 17 release

Filed history related lists in Lightning experience, With Summer’17 release Field history related lists in lightning experience are available. This was not available in lightning experience before summer’17 release.

If Field history related lists are already added in salesforce classic version, those are available in lighting version as well with salesforce summer’17 release. If field history related list is not added, you can add this related list to your layout in lighting version.

If you want to enable field history tracking on lightning version, go to object manager, select an object, click on fields and relationships, click field history tracking and select the fields to track and finally add object history related list to page layout.

For more details on this refer salesforce summer’17 release notes.

VisualforceAccessMetrics object – Summer’17

VisualforceAccessMetrics object – Access visualforce metrics using SOAP API

VisualforceAccessMetrics object, Salesforce providing this object to query metrics on the visualforce pages. We can use this object in salesforce SOAP API.

Example Query:

SELECT ApexPageId,DailyPageViewCount,Id,MetricsDate FROM VisualforceAccessMetrics

About fields of this object:

DailyPageViewCount field: This field is type of integer and it stores daily page view count.

MetricsDate: This field is type of date and the date the metrics were collected.

ApexPageId: ID of the tracked visualforce page.

This object supports count(), query() and retrieve() calls.

Using this we can track,

– Number of views each Visualforce page in your org receives in a 24-hour
time period.

– To find out how many views a page got over the course of multiple days, we can query multiple VisualforceAccessMetrics objects for the same ApexPageId.



WITH SPELL_CORRECTION and WITH HIGHLIGHT clauses in Summer’17 for SOSL (Salesforce Object Search Language): Below are the two more SOSL clauses available in salesforce with Summer’17 release (API version 40).




This is an optional clause that can be added to a SOSL query for business account, campaign, contact, lead, opportunity, quote, user and custom object searches. It highlights the terms matching the search query in search results, making it easier to identity relevant content.

This clause was available for business account, campaign, contact, lead, opportunity, quote, user object with version 39 or later. It is also available for Custom object and fields with version 40 or later.

Highlighted search terms are generated only from the following standard and custom field types:

Auto number, Email, Text, Text Area and Text Area (Long).


FIND {stutorials} IN ALL FIELDS RETURNING Account(Name,Description) WITH HIGHLIGHT

Above SOSL statement returns search results with search item stutorials highlighted.

Important notes about WITH HIGHLIGHT clause:

– Only 25 records per entity per SOSL query are highlighted.

– Search teams that contains a wildcard are not highlighted.

– Other objects that are included in searches that contain WITH HIGHLIGHT don’t return highlighted search terms.

– This clause in SOSL is supported in SOAP API and REST API.


– This is an optional clause that can be added to a SOSL query.

– When it set to true, spell correction is enabled for searches that support spell correction. When it set to false, spell correction is not enabled. Default value is true.

– This clause is available with version 40 or later versions.



– This clause in SOSL is supported in SOAP API, REST API and Apex.