Overview of some of the most commonly used selectors

Below is a brief overview of some of the most commonly used selectors.

$("*") - Wildcard: selects every element on the page.
$(this) - Current: selects the current element being operated on within a function.
$("p") - Tag: selects every instance of the <p> tag.
$(".example") - Class: selects every element that has the example class applied to it.
$("#example") - Id: selects a single instance of the unique example id.
$("[type='text']") - Attribute: selects any element with text applied to the type attribute.
$("p:first-of-type") - Pseudo Element: selects the first <p>.

Search results always "Search All"

When you search all, you will see the records on the left hand side. Each record type has a little pin on the right hand side. If the user clicks that those objects will always be checked in the regular search. That way they should not need to click search all to find those records when searching. 

Create case comments in Salesforce1 app – with out coding!

https://kksfblog.wordpress.com/2015/07/20/create-case-comments-in-salesforce1-app-with-out-coding/

Get sObject type from the recordId

Map<String,String> keys = new Map<String,String>();
        Map<String,Schema.SobjectType> describe = Schema.getGlobalDescribe();
        for(String s:describe.keyset())
            keys.put(describe.get(s).getDescribe().getKeyPrefix(),s);
     
     
        system.debug('@@@@'+keys.get(String.valueOf(recordId).substring(0,3)));

How to Create Dependent Picklist fields In Lightning Component

http://www.sfdcmonkey.com/2017/02/18/dependent-picklist-fields-lightning-component/

Trigger Best Practices | Sample Trigger Example | Implementing Trigger Framework

1) One Trigger Per Object
A single Apex Trigger is all you need for one particular object. If you develop multiple Triggers for a single object, you have no way of controlling the order of execution if those Triggers can run in the same contexts

2) Logic-less Triggers
If you write methods in your Triggers, those can’t be exposed for test purposes. You also can’t expose logic to be re-used anywhere else in your org. 

3) Context-Specific Handler Methods
Create context-specific handler methods in Trigger handlers


4) Bulkify your Code
Bulkifying Apex code refers to the concept of making sure the code properly handles more than one record at a time.

5) Avoid SOQL Queries or DML statements inside FOR Loops
An individual Apex request gets a maximum of 100 SOQL queries before exceeding that governor limit. So if this trigger is invoked by a batch of more than 100 Account records, the governor limit will throw a runtime exception

6) Using Collections, Streamlining Queries, and Efficient For Loops
It is important to use Apex Collections to efficiently query data and store the data in memory. A combination of using collections and streamlining SOQL queries can substantially help writing efficient Apex code and avoid governor limits

7) Querying Large Data Sets
The total number of records that can be returned by SOQL queries in a request is 50,000. If returning a large set of queries causes you to exceed your heap limit, then a SOQL query for loop must be used instead. It can process multiple batches of records through the use of internal calls to query and queryMore

8) Use @future Appropriately
It is critical to write your Apex code to efficiently handle bulk or many records at a time. This is also true for asynchronous Apex methods (those annotated with the @future keyword). The differences between synchronous and asynchronous Apex can be found

9) Avoid Hardcoding IDs
When deploying Apex code between sandbox and production environments, or installing Force.com AppExchange packages, it is essential to avoid hardcoding IDs in the Apex code. By doing so, if the record IDs change between environments, the logic can dynamically identify the proper data to operate against and not fail

Always remember below points before writing trigger :-
1) Order Of Execution 
2) Recursive Trigger 

Example of Trigger Code :- 

Create one Trigger "AccountTrigger"

trigger AccountTrigger on Account( after insert, after update, before insert, before update)
{

    AccountTriggerHandler handler = new AccountTriggerHandler(Trigger.isExecuting, Trigger.size);
    
    if( Trigger.isInsert )
    {
        if(Trigger.isBefore)
        {
            handler.OnBeforeInsert(trigger.New);
        }
        else
        {
            handler.OnAfterInsert(trigger.New);
        }
    }
    else if ( Trigger.isUpdate )
    {
        if(Trigger.isBefore)
        {
            handler.OnBeforeUpdate(trigger.New ,trigger.Old,Trigger.NewMap,Trigger.OldMap);
        }
        else
        {
            handler.OnAfterUpdate(trigger.New ,trigger.Old,Trigger.NewMap,Trigger.OldMap);
        }
    }
}

Create one Trigger Handler Class

public with sharing class AccountTriggerHandler 
{
    private boolean m_isExecuting = false;
    private integer BatchSize = 0;
    public static boolean IsFromBachJob ;
    public static boolean isFromUploadAPI=false;
    
    public AccountTriggerHandler(boolean isExecuting, integer size)
    {
        m_isExecuting = isExecuting;
        BatchSize = size;
    }
            

    public void OnBeforeInsert(List<Account> newAccount)
    {
        system.debug('Account Trigger On Before Insert');
    }
    public void OnAfterInsert(List<Account> newAccount)
    {
        system.debug('Account Trigger On After Insert');
    }
    public void OnAfterUpdate( List<Account> newAccount, List<Account> oldAccount, Map<ID, Account> newAccountMap , Map<ID, Account> oldAccountMap )
    {
        system.debug('Account Trigger On After Update ');
        AccountActions.updateContact (newAccount);
    }
    public void OnBeforeUpdate( List<Account> newAccount, List<Account> oldAccount, Map<ID, Account> newAccountMap , Map<ID, Account> oldAccountMap )
    {
        system.debug('Account Trigger On Before Update ');
    }

    @future 
    public static void OnAfterUpdateAsync(Set<ID> newAccountIDs)
    {

    }      
    public boolean IsTriggerContext
    {
        get{ return m_isExecuting;}
    }
    
    public boolean IsVisualforcePageContext
    {
        get{ return !IsTriggerContext;}
    }
    
    public boolean IsWebServiceContext
    {
        get{ return !IsTriggerContext;}
    }
    
    public boolean IsExecuteAnonymousContext
    {
        get{ return !IsTriggerContext;}
    }
} 

Create one Trigger Action Class

public without sharing class AccountActions 
{
    public static void updateContact ( List<Account> newAccount)
    {
        // Add your logic here
    }
}

Source of link :-

https://developer.salesforce.com/page/Trigger_Frameworks_and_Apex_Trigger_Best_Practices
https://developer.salesforce.com/page/Apex_Code_Best_Practices

Best Practice for Test classes | Sample Test class

Test Class for Trigger 

@isTest 
public class TriggerTestClass 
{
    static testMethod void testMethod1() 
 {
  // Perform DML here only
 
        }
}

Test Class for Standard Controller

@isTest 
public class ExtensionTestClass 
{
 static testMethod void testMethod1() 
 {
 Account testAccount = new Account();
 testAccount.Name='Test Account' ;
 insert testAccount;

 Test.StartTest(); 
  ApexPages.StandardController sc = new ApexPages.StandardController(testAccount);
  myControllerExtension testAccPlan = new myControllerExtension(sc);

  PageReference pageRef = Page.AccountPlan; // Add your VF page Name here
  pageRef.getParameters().put('id', String.valueOf(testAccount.Id));
  Test.setCurrentPage(pageRef);

  //testAccPlan.save(); call all your function here
 Test.StopTest();
 }
}

Test Class for Controller class

@isTest 
public class ControllerTestClass 
{
 static testMethod void testMethod1() 
 {
 Account testAccount = new Account();
 testAccount.Name='Test Account' ;
 insert testAccount;

 Test.StartTest(); 

  PageReference pageRef = Page.AccountPlan; // Add your VF page Name here
  pageRef.getParameters().put('id', String.valueOf(testAccount.Id));
  Test.setCurrentPage(pageRef);

  myController testAccPlan = new myController();
  
  //testAccPlan.save(); call all your function here
 Test.StopTest();
 }
}

Test Class for StandardSetController

@isTest 
public class TestStandardSetController 
{
 static testMethod void testMethod1() 
 {
 List <Account> lstAccount = new List<Account>();
 
 Account testAccount = new Account();
 testAccount.Name='Test Account' ;
 lstAccount.add(testAccount);
 Account testAccount1 = new Account();
 testAccount1.Name='Test Account1' ;
 lstAccount.add(testAccount1);

 insert  lstAccount;
 
 Test.startTest();
  Test.setCurrentPage(Page.YOUR_PAGE);
  ApexPages.StandardSetController stdSetController = new ApexPages.StandardSetController(lstAccount);
  stdSetController.setSelected(lstAccount);
  YOUR_Extension ext = new YOUR_Extension(stdSetController);
 Test.stopTest();
 }
}

Please follow below salesforce Best Practice for Test Classes :-

1. Test class must start with @isTest annotation if class class version is more than 25
2. Test environment support @testVisible , @testSetUp as well
3. Unit test is to test particular piece of code working properly or not .
4. Unit test method takes no argument ,commit no data to database ,send no email ,flagged with testMethod keyword .
5. To deploy to production at-least 75% code coverage is required
6. System.debug statement are not counted as a part of apex code limit.
7. Test method and test classes are not counted as a part of code limit
9. We should not focus on the  percentage of code coverage ,we should make sure that every use case should covered including positive, negative,bulk and single record .

• Single Action -To verify that the the single record produces the correct an expected result .
• Bulk action -Any apex record trigger ,class or extension must be invoked for 1-200 records .
• Positive behavior : Test every expected behavior occurs through every expected permutation , i,e user filled out every correctly data and not go past the limit .
• Negative Testcase :-Not to add future date , Not to specify negative amount.
• Restricted User :-Test whether a user with restricted access used in your code .

10. Test class should be annotated with @isTest .
11 . @isTest annotation with test method  is equivalent to testMethod keyword .
12. Test method should static and no void return type .
13. Test class and method default access is private ,no matter to add access specifier .
14. classes with @isTest annotation can't be a interface or enum .
15. Test method code can't be invoked by non test request .
16. Stating with salesforce API 28.0 test method can not reside inside non test classes .
17. @Testvisible annotation to make visible private methods inside test classes.
18. Test method can not be used to test web-service call out . Please use call out mock .
19. You can't  send email from test method.
20.User, profile, organization, AsyncApexjob, Corntrigger, RecordType, ApexClass, ApexComponent ,ApexPage we can access without (seeAllData=true) .
21. SeeAllData=true will not work for API 23 version eailer .
22. Accessing static resource test records in test class e,g List<Account> accList=Test.loadData(Account,SobjectType,'ResourceName').
23. Create TestFactory class with @isTest annotation to exclude from organization code size limit .
24. @testSetup to create test records once in a method  and use in every test method in the test class .
25. We can run unit test by using Salesforce Standard UI,Force.com IDE ,Console ,API.
26. Maximum number of test classes run per 24 hour of period is  not grater of 500 or 10 multiplication of test classes of your organization.
27. As apex runs in system mode so the permission and record sharing are not taken into account . So we need to use system.runAs to enforce record sharing .
28. System.runAs will not enforce user permission or field level permission .
29. Every test to runAs count against the total number of DML issued in the process .

Test Utility Classes | TestDataFactory | Util Test in salesforce

Common test utility classes are public test classes that contain reusable code for test data creation.The TestDataFactory/ testutility  class is a special type of class — It is a public class that is annotated with @isTest and and as such, are excluded from the organization code size limit and execute in test context and can be accessed only from a running test.

Test utility classes/TestDataFactory contain methods that can be called by test methods to perform useful tasks, such as setting up test data. 


Step 1:- Create TestDataFactory / Test utility

@isTest
public with sharing class TestDataFactory 
{
    /** 
    * ********************************************************
    * This method is test data for create Lead
    * ********************************************************
    */

    public static Lead createLead(Boolean doInsert)
    {
        Lead newLead = new Lead() ;
        newLead.FirstName = 'Cole';
        newLead.LastName = 'Swain';
        newLead.Company = 'BlueWave';
        newLead.Status = 'contacted';
        if(doInsert){
            insert newLead;
        }
        return newLead;
    }

    public static Void convertLead(Lead newLead )
    {
        database.leadConvert lc = new database.leadConvert();
        lc.setLeadId(newLead.id);
        leadStatus convertStatus = [SELECT Id, MasterLabel FROM LeadStatus WHERE IsConverted=true LIMIT 1];
        lc.setConvertedStatus(convertStatus.MasterLabel);
        
        Database.LeadConvertResult lcr = Database.convertLead(lc);
        System.assert(lcr.isSuccess());
        lc.setOpportunityName('Cole Swain');
        
    }
        
    /** 
    * ******************************************************
    * This method is test data for create Account
    * ******************************************************
    */
    
    public static Account createAccount(Boolean doInsert)
    {
        Account acc = new Account();
        acc.Name = 'Test Account';
        if(doInsert){
            insert acc;
        }
        return acc;
    }
       
     /**
     * *******************************************************
     * This method is test data for create contact object
     * *******************************************************
     */
    public static Contact createContact(Boolean doInsert)
    {
        return createContact(doInsert, createAccount(true).Id);
    }
    
    public static Contact createContact(Boolean doInsert, Id accId)
    {
        Contact con = new Contact();
        con.AccountId = accId;
        con.FirstName = 'FirstName';
        con.LastName = 'LastName';
        con.Email = 'FirstName@test.com' + Math.floor(Math.random() * 1000);
        if(doInsert)
        {
            insert con;
        }
        return con;
    }

    /**
    * ***********************************************************
    * This method is test data for create Opportunity object
    * ***********************************************************
    */
    
    public static Opportunity createOpportunity(Boolean doInsert, Id accId)
    {
        Opportunity oppt = new Opportunity(Name ='New mAWS Deal',
                            AccountID = accId,
                            StageName = 'Customer Won',
                            Amount = 3000,
                            CloseDate = System.today()
                            );
        if(doInsert)
        {
            insert oppt;
        }
        return oppt;
    }   
    
    /**
    * ************************************************************
    * This method is test data for create Case object
    * ************************************************************
    */
        
    public static Case  createCase(Boolean doInsert )
    {
        Case cas = new Case(Status ='New', Priority = 'Medium', Origin = 'Email');
        if(doInsert)
        {
            insert cas ;
        }
        return cas ;
    }    
    
}

Step 2:- How to Use TestDataFactory / Test utility

@isTest
private class MyTestClass 
{
    static testmethod void myUnitTest() 
    {
        Lead leadObj = TestDataFactory.createLead(true);
        Account accObj = TestDataFactory.createAccount(true);
        Contact contObj = TestDataFactory.createContact(true,accObj.id);
        Opportunity oppObj = TestDataFactory.createOpportunity(true,accObj.id);
        Case caseObj = TestDataFactory.createCase(true);
    }
    // If you want to edit data according to apex class then try like below
    static testmethod void myUnitTest1() 
    {
        Lead leadObj = TestDataFactory.createLead(false); // pass false
        leadObj.LastName ='MyName';
        insert leadObj ;
        
        Account accObj = TestDataFactory.createAccount(false);
        accObj.Name ='MyName';
        insert accObj;
        
    }
    
}

Please check below post for Test Class Sample :-

1) Best Practice for Test classes | Sample Test class

2) Code Coverage Report in excel Format | Test Class Result in XLS

3) Salesforce Testing Best Practice Guidelines | Unit Test Mechanism in Salesforce  
4) StartTest and stopTest Method

Some Useful link :-

1) https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_utility_classes.htm
2) https://trailhead.salesforce.com/en/apex_testing/apex_testing_data?id=apex_testing
3) https://github.com/dhoechst/Salesforce-Test-Factory

Capture date/time stamp when case owner changes from queue to user

You need a Workflow with a Field Update Action to do this.
Create a Custom Date/Time field on Case Object
Create a Workflow on Case Object
Evaluation Criteria: Created and everytime its edited (2nd Option)
Rule Criteria: Formula Evaluates to True and the formula is

AND(
ISBLANK(Custom_Date_Time_Field__c),
ISCHANGED( OwnerId ),
LEFT(OwnerId, 3 ) = "005",
LEFT(PRIORVALUE(OwnerId), 3) = "00G"
)

Save and Next
Immediate Acion: Field Update
Field to Update: Custom Date/Time Field
Select formula to update new value and the formula is

NOW()

Save,Done and Activate your workflow Rule.

Set Up the Milestone Tracker | Salesforce

Set Up the Milestone Tracker

The milestone tracker gives support agents a complete view of upcoming and closed milestones, and displays countdowns for active and overdue milestones. Add it to the case feed, work order feed, a custom page, or the service console.

Available in: Salesforce Classic

Available in: Professional, Enterprise, Performance, Unlimited, and Developer Editions with the Service Cloud

User Permissions Needed
To create and edit page layouts:	“Customize Application”
To assign page layouts:	“Manage Users”
To set how time displays in the milestone tracker:	“Manage Entitlements”

Often, support agents’ performance is measured by how often they meet milestones. The milestone tracker helps agents be prepared for support deadlines by showing them:

• The time remaining until an active milestone reaches its Target Date
• The time passed since an overdue milestone’s Target Date
• A list of upcoming milestones
• A list of closed milestones

When a milestone is in progress, the milestone is represented by a green circle. The circle winds down clockwise as time elapses. The remaining time is shown in the center of the circle. When the time to complete the milestone expires, the circle turns red. The amount of time that the milestone is overdue is shown in the center of the circle.

If more than 24 hours remain on a milestone, the countdown displays in days (for example, 1d). When fewer than 24 hours remain, the countdown format switches to hours/minutes/seconds.

1. Expose the milestone tracker to support agents.
   You can expose the tracker in one of three ways:
   

   • Add it to the case feed. If you plan to use milestones on work orders, follow the same steps to add the tracker to the work order feed.
     1. From the object management settings for cases, go to Page Layouts.
     2. In the Case Page Layouts section, click Edit, and then click Feed View in the page layout editor.
     3. In the Other Tools and Components section, select the Milestone Tracker and specify where on the page you want it to appear.
     4. Click Save.
   • Add it to a custom Visualforce page using the <apex:milestoneTracker> component.
   • Add it as a component to the service console.
2. Set how the milestone tracker displays time remaining or time overdue on milestones.
   By default, the tracker uses actual hours. To make it display time remaining or time overdue in business hours, follow these steps.
   1. From Setup, enter Entitlement Settings in the Quick Find box, then select Entitlement Settings.
   2. In the Milestone Tracker section, deselect Show the time remaining in actual hours, not business hours.
   3. Click Save.

Example

Suppose an active milestone’s business hours are 9 a.m. to 5 p.m. Right now, it’s 4:30 p.m. and the milestone’s Target Date is 11:00 a.m. tomorrow.

• If the milestone tracker shows the remaining time in business hours (the default setting), it displays a countdown of 2 hours and 30 minutes (4:30 to 5 p.m. today and 9 to 11 a.m. tomorrow).
• If the milestone tracker shows the remaining time in actual hours, it displays a countdown of 18 hours and 30 minutes (4:30 p.m. today to 11:00 a.m. tomorrow).

Export package.xml manifest from Change Set

This is possible using ANT tool. I am assuming you guys are familiar with ANT. Add below target in build.xml <target name="retrieveChangeSet">    <mkdir dir="changeSet" />       <sf:retrieve username="${sf.username}" password="${sf.password}" serverurl="${sf.serverurl}" maxPoll="${sf.maxPoll}" retrieveTarget="changeSet"       packageNames="Name Of the ChangeHere" /> </target> Execute the Command - ANT retrieveChangeSet you should have all the components retrieved and Package.xml.

ISDTP in salesforce lightning

isdtp url parameter does not allow to switch to lightning. It only allows to show/hide sidebar or header. Below the possible options (got it here (http://salesforce.stackexchange.com/questions/32318/visualforce-embedded-report-isdtp-parameter-options))

• vw - leaves off SF page header and sidebar, supports aloha theme, allows chatter
• lt - leaves off SF formatting, page header, sidebar, and section header
• nv - leaves off SF page header and sidebar (behavior changed Winter 14 - see link)
• mn - leaves off some SF formatting, page header and sidebar