Apex Test Class

@isTest(SeeAllData=true)
public class A
{

public static testMethod void  A()
{
      //START Execute main apex Instance

                Test.StartTest();
                //Execute a Separate Apex Instance
                Test.StopTest();
             //START Execute a Separate Apex Instance1
                  .....
             //END  Execute a Separate Apex Instance1
             Test.StartTest();
            //START Execute a Separate Apex Instance1
                .....
            //END  Execute a Separate Apex Instance1
             Test.StopTest();

           Test.StartTest();
            //START Execute a Separate Apex Instance1
            .....
          //END  Execute a Separate Apex Instance1
           Test.StopTest();
      //END Execute main apex Instance
  }
}

1. Use SeeAllData=true for  accessing live org data in test class
2. We can write number of   Test.StartTest(); Test.StopTest(); blocks within a test method
3. We can user startTest stopTest Block for test Asynch Classes 

Asynchronous Apex

Apex offers multiple ways for running your Apex code asynchronously.
This table lists the asynchronous Apex features and when to use each.

Asynchronous Apex Feature	When to Use
Future Methods	When you have a long-running method and need to prevent delaying an Apex transaction When you make callouts to external Web services To segregate DML operations and bypass the mixed save DML error
Queueable Apex	To start a long-running operation and get an ID for it To pass complex types to a job To chain jobs
Batch Apex	For long-running jobs with large data volumes that need to be performed in batches, such as database maintenance jobs For jobs that need larger query results than regular transactions allow
Scheduled Apex	To schedule an Apex class to run on a specific schedule

Duplicate Management

1. Matching Rules
2. Duplicate Rules
3. Duplicate Record Sets
4.  Duplicate Error Logs

What Are Matching Rules?

A matching rule compares field values to determine whether a record is similar enough to existing records to be considered a duplicate. 

For example, a matching rule can specify that if the Email and Phone values of two records match exactly, the records might be duplicates. 

Use matching rules with duplicate rules to define what happens when duplicates are identified.

After a matching rule is activated, one or more match keys are automatically created and applied to existing records. (Also known as indexing, this process improves performance and returns a better set of match candidates because the matching rule is only looking for duplicates among records with the same match key.) When the matching rule is run, it compares the record’s match keys against those for existing records. Then, for records that share the same match keys, the matching rule uses matching algorithms to compare fields and determine how closely the fields, and ultimately the records, match. If two records’ don’t share the same match keys, they are not considered duplicates and the matching algorithms will not even be applied to them. 

Standard Matching Rules

We’ve provided several standard matching rules that you can use with Data.com Duplicate Management tools, such as duplicate rules. Each standard matching rule has been carefully designed to return the best possible set of match candidates for accounts, contacts, or leads.

• Standard Account Matching Rule
  Like all matching rules, the standard matching rule used for account records is made up of fields that are arranged into an equation. Each field contains matching criteria that the rule uses to determine how closely the field matches the same field in an existing record, and ultimately whether the record is a match.
• Standard Contact and Lead Matching Rule
  Like all matching rules, the standard matching rule used for contact and lead records is made up of fields that are arranged into an equation. Each field also contains matching criteria that the rule uses to determine how closely the field matches the same field in an existing record, and ultimately whether the record is a match.

When you create a custom matching rule, you need to define certain criteria. For standard matching rules, the criteria are already defined for you.

Rule Name	Matching Equation
Standard Account Matching Rule	(Account Name AND Billing Street) OR (Account Name AND City) OR (Account Name AND ZIP) OR (Account Name AND Phone) OR (Website AND Phone) OR (Website AND Billing Street)

Field	Matching Algorithms	Scoring Method	Threshold	Blank Fields	Special Handling
Account Name	Acronym Edit Distance Exact	Maximum	70	Don’t match	Removes words such as Inc and Corp before comparing fields. Also, company names are normalized. For example, 1st National Bank is normalized to First National Bank.
Phone	Exact	Weighted Average	80	Don’t match on all sections expect Area Code, which ignores blank fields	Phone numbers are broken into sections and compared by those sections. Each section has its own matching method and match score. The section scores are weighted to come up with 1 score for the field. This process works best with North American data. International code (Exact, 10% of field’s match score) Area code (Exact, 50% of field’s match score) Next 3 digits (Exact, 30% of field’s match score Last 4 digits (Exact, 10% of field’s match score) For example, suppose that these two phone numbers are being compared: 1-415-555-1234 and 1-415-555-5678. All sections match exactly except the last 4 digits, so the field has a match score of 90, which is considered a match because it exceeds the threshold of 80.
Billing Street	Edit Distance Exact	Weighted Average	80	Don’t match	Addresses are broken into sections and compared by those sections. Each section has its own matching method and match score. The section scores are weighted to come up with 1 score for the field. This process works best with North American data. Street Number (Exact, 20% of field’s match score) Street Name (Edit Distance, 50% of field’s match score) Street Suffix (Exact, 15% of field’s match score) Suite Number (Exact, 15% of field’s match score) For example, suppose that these two billing streets are being compared: 123 Market Street, Suite 100 and 123 Market Drive, Suite 300. Because only the street number and street name match, the field has a match score of 70, which is not considered a match because it’s less than the threshold of 80.
ZIP	Exact	Weighted Average	80	Don’t match	ZIP codes are broken into sections and compared by those sections. Each section has its own matching method and match score. The section scores are weighted to come up with 1 score for the field. First 5 digits (Exact, 90% of field’s match score) Next 4 digits(Exact, 10% of field’s match score) For example, suppose these 2 ZIP codes are being compared:94104–1001 and 94104. Because only the first 5 digits match, the field has a match score of 90, which is considered a match because it exceeds the threshold of 80.
City	Edit Distance Exact	Maximum	85	Don’t match
Website	Exact	Maximum	100	Don’t match	The prefix “http://” is appended to the website domain. For example, a field value www.salesforce.com becomeshttp://www.salesforce.com for matching purposes. Matching for an account record that has a website without the “http://” prefix identifies the record as a duplicate.

Standard Contact and Lead Matching Rule

Like all matching rules, the standard matching rule used for contact and lead records is made up of fields that are arranged into an equation. Each field also contains matching criteria that the rule uses to determine how closely the field matches the same field in an existing record, and ultimately whether the record is a match.

Matching Equation

Rule Name	Matching Equation
Standard Contact Matching Rule Standard Lead Matching Rule	(First Name AND Last Name AND Title AND Company Name) OR (First Name AND Last Name AND Email) OR (First Name AND Last Name AND Phone AND Company Name) OR (First Name AND Last Name AND Mailing Street AND (City OR ZIP OR Phone) OR (First Name AND Last Name AND Mailing Street AND Title) OR (First Name AND Last Name AND Title AND Email) OR (First Name AND Last Name AND Phone )

Matching Criteria

For a definition of each matching criteria, see Matching Criteria for Matching Rules.

Fields on Contacts	Fields on Leads	Matching Algorithms	Scoring Method	Threshold	Blank Fields	Special Handling
First Name	First Name	Exact Initials Jaro-Winkler Distance Metaphone 3 Name Variant	Maximum	85	Don’t match (Ignores blank fields when Email is included in field grouping)	If record contains a value for the both First Name and Last Name fields, those values will be transposed to account for possible data entry mistakes. For example, if the first name is George and the last name is Michael, the matching rule will also evaluate first name as Michael and the last name as George.
Last Name	Last Name	Exact Keyboard Distance Metaphone 3	Maximum	90	Don’t match (Ignores blank fields when Email is included in field grouping)	If record contains a value for the both First Name and Last Name fields, those values will be transposed to account for possible data entry mistakes. For example, if the first name is George and the last name is Michael, the matching rule will also evaluate first name as Michael and the last name as George.
Title	Title	Acronym Exact Kullback-Liebler Distance	Maximum	50	Don’t match
Account Name	Company	Acronym Edit Distance Exact	Maximum	70	Don’t match
Email	Email	Exact	Maximum	100	Don’t match
Phone	Phone	Exact	Weighted Average	80	Don’t match on all sections expect Area Code, which ignores blank fields	Phone numbers are broken into sections and compared by those sections. Each section has its own matching method and match score. The section scores are weighted to come up with one score for the field. This process works best with North American data. International code (Exact, 10% of field’s match score) Area code (Exact, 50% of field’s match score) Next 3 digits (Exact, 30% of field’s match score Last 4 digits (Exact, 10% of field’s match score) For example, suppose these two phone numbers are being compared: 1-415-555-1234 and1-415-555-5678. All sections match exactly except the last 4 digits, so the field has a match score of 90, which is considered a match because it exceeds the threshold of 80.
Mailing Street	Street	Exact	Weighted Average`	80	Don’t match	Addresses are broken into sections and compared by those sections. Each section has its own matching method and match score. The section scores are weighted to come up with one score for the field. This process works best with North American data. Street Name (Edit Distance, 50% of field’s match score) Street Number (Exact, 20% of field’s match score) Street Suffix (Exact, 15% of field’s match score) Suite Number (Exact, 15% of field’s match score) For example, suppose these two addresses are being compared: 123 Market Street, Suite 100 and 123 Market Drive, Suite 300. Because only the street number and street name match, the field has a match score of 70, which is not considered a match because it’s less than the threshold of 80.
Mailing ZIP/Postal Code	ZIP/Postal Code	Exact	Weighted Average	80		ZIP codes are broken into sections and compared by those sections. Each section has its own matching method and match score. The section scores are weighted to come up with one score for the field. First 5 digits (Exact, 90% of field’s match score) Next 4 digits(Exact, 10% of field’s match score)
Mailing City	City	Edit Distance Exact	Maximum	85	Don’t match

Matching Criteria for Matching Rules

Matching rules use criteria to determine how closely a field on a new or edited record matches the same field on an existing record, and, ultimately, whether the two records are duplicates. When you create a custom matching rule, you need to define certain criteria. For standard matching rules, the criteria are already defined for you.

Available in: Salesforce Classic and Lightning Experience

Available in: Professional, Enterprise, Performance, Unlimited, and Developer Editions

Criterion	Definition	Automatically Defined for Custom Matching Rules
Field	Indicates which field to compare. When selecting fields, keep in mind that: The available fields depend on which object the matching rule applies to and include both standard and custom fields. The supported input field types are email, lookup relationship, master-detail relationship, number, phone, standard picklists, custom picklists (single-select only), text, and URL. An auto-numbered lookup relationship field cannot be used in a matching rule. If you enable State and Country picklists for your organization, we recommend usingState/Province Code and Country Code in your matching rules. These fields yield better duplicate detection results than the state and country text fields.
Matching Method	Defines the method for how the fields are compared. We’ve provided an exact matching method that can be used for almost any field, including custom fields. A fuzzy matching method is available for commonly used standard fields. Each matching method is further defined by normalization and match key definitions, matching algorithms, and other criteria. For more information about matching methods, see Matching Methods Used with Matching Rules.
Match Blank Fields	Specifies how blank fields affect whether the 2 fields being compared are considered matches. If you select the Match Blank Fields checkbox for any field, and that field is blank in bothrecords being compared, the fields are considered matches. If, however, you select the Match Blank Fields checkbox for any field, and that field is blank in only one of the records being compared, the fields are not considered matches. If you don’t select the Match Blank Fields checkbox for any field, and that field is blank inboth records being compared, the fields are not considered matches.
Match Key	A formula that allows the matching rule to quickly return a list of possible duplicates. Once a matching rule is activated, match keys are used to generate match key values for all records. When a matching rule runs, it compares the match key values of the saved record with existing records. If the saved record has the same match key value as an existing record, it’s a potential duplicate and evaluated further. If the saved record has a unique match key value, it’s not considered a duplicate. This process improves the speed and performance of duplicate detection. For more information about match keys, including examples, see Match Keys Used with Matching Rules.
Matching Algorithm	Defines the logic that determines whether 2 fields match. For the Exact matching method, the Exact matching algorithm is automatically used. For the Fuzzy matching method, various fuzzy matching algorithms can be used. Each matching algorithm used is automatically given a match score based on how closely it’s able to match the two fields. For example, if you select Exact matching and the two fields match, the match score is 100. If the 2 fields don’t match, the match score is 0. For more information about matching algorithms, see Matching Algorithms Used with Matching Methods.
Scoring Method	Determines how the matching algorithms’ match scores are calculated to come up with one match score for the field.  Each matching algorithm used is automatically given a match score based on how closely it’s able to match the two fields. Scoring method is used only by the standard matching rules. Average: Uses the average match score. Maximum: Uses the highest match score. Minimum: Uses the lowest match score. Weighted Average Uses the weight of each matching method to determine the average match score.
Threshold	Determines the minimum match score needed for the field to be considered a match. The field is automatically given a match score based on how closely it matches the same field in an existing record.

What Are Duplicate Rules?

Your duplicate rules work together with your matching rules to prevent users from creating duplicate records. 

A matching rule determines whether the record a user is creating or updating is similar enough to other records to be considered a duplicate, whereas a duplicate rule tells Salesforce what action to take when duplicates are identified. 

For example, a duplicate rule can block users from saving records that have been identified as possible duplicates, or simply alert users that they may be creating a duplicate, but allow them to save the record anyway. 
Each duplicate rule requires at least one matching rule to identify which existing records are possible duplicates.

You can configure your duplicate rule to do something when a record is created and edited. However, the rule only runs for edited records if the fields being edited are included in the associated matching rule.

Duplicate Record Sets:

Quickly see a list of duplicate records, grouped into duplicate sets, by clicking the Duplicate Record Sets tab. To do so, your organization needs to use the report action with its duplicate rules. When a user saves a record that’s identified as a duplicate by a duplicate rule with the report action: • The saved record and all its duplicates, up to 100, will be assigned to a new or existing duplicate record set. • The saved record and each of its duplicates will be listed as a duplicate record item within the duplicate record set. • If the duplicate rule is configured to find duplicates across objects, all cross-object duplicates will be listed as duplicate record items within the duplicate record set. Duplicate record sets and duplicate record items can be used to do the following. • Create custom report types • Create custom fields • Write validation rules, triggers, and workflow rules • Modify the fields that can appear on the respective page layouts 

Duplicate Error Logs EDITIONS Available in: 

 If your organization uses Data.com Duplicate Management, you can view any system errors that prevent the duplicate rules or matching rules from running successfully. From Setup, enter Duplicate Error Logs in the Quick Find box, then select Duplicate Error Logs. There, you can see which, if any, errors occurred. Error logs are deleted after 90 days. 

Example: 

Here are some scenarios that could produce an error on the log.

 • The match engine used for fuzzy matching is temporarily unavailable. Therefore, any matching rules that include fuzzy matching methods will not run. 

• The Report action on duplicate rules fails because the system is unable to create a duplicate record set.

Important Headings:

1. Matching Methods Used with Matching Rules
2. Matching Algorithms Used with Matching Methods
3. Match Keys Used with Matching Rules
4. How Match Keys and Match Key Values Are Created
5. Match Key Notation
6. Pre-Defined Match Keys for Standard Matching Rules
7. Normalization Criteria for Matching Rule Match Keys 

Why am I getting an error saying my matching rule uses too many OR operators within groupings? 

A matching rule has a limit of 10 fields that are arranged into an equation. When a matching rule is saved, we rewrite the equation into a standardized format that translates the OR statements to AND statements. The standardized format has a limit of 10 rows.

 Example: If your matching rule includes the following equation...

 (Field 1 OR Field 2) AND 

(Field 3 OR Field 4) AND 

(Field 5 OR Field 6) AND 

(Field 7 OR Field 8) ...

it would be rewritten as

 (Field 1 AND Field 3 AND Field 5 Field AND 7) OR 

(Field 1 AND Field 3 AND Field 5 AND Field 8) OR 

(Field 1 AND Field 3 AND Field 6 AND Field 7) OR 

(Field 1 AND Field 3 AND Field 6 AND Field 8) OR 

(Field 1 AND Field 4 AND Field 5 AND Field 7) OR 

(Field 1 AND Field 4 AND Field 5 AND Field 8) OR 

(Field 1 AND Field 4 AND Field 6 AND Field 7) OR 

(Field 1 AND Field 4 AND Field 6 AND Field 8) OR 

(Field 2 AND Field 3 AND Field 5 AND Field 7) OR 

(Field 2 AND Field 3 AND Field 5 AND Field 8) OR 

(Field 2 AND Field 3 AND Field 6 AND Field 7) OR 

(Field 2 AND Field 3 AND Field 6 AND Field 8)OR 

(Field 2 AND Field 4 AND Field 5 AND Field 7) OR 

(Field 2 AND Field 4 AND Field 5 AND Field 8) OR 

(Field 2 AND Field 4 AND Field 6 AND Field 7) OR

(Field 2 AND Field 4 AND Field 6 AND Field 8) 

Although this matching rule is within the field limit, it exceeds the row limit of 10 when written in the standardized format, and therefore can’t be saved. You need to refine the matching rule so it uses fewer OR operators within groupings.

How does duplicate prevention work with Data.com Prospector and Data.com Clean? 

Adding Records with Data.com Prospector 

It depends on what your organization’s Data.com duplicate preferences are. If your organization does not allow duplicate records to be added to Salesforce from Data.com, then Data.com will block duplicate records from being added to Salesforce and the duplicate rule won’t need to run. The user trying to add records from Data.com will receive an error log detailing which records couldn’t be added because they are duplicates. If your organization allows duplicate records to be added to Salesforce from Data.com, then the duplicate rules will run. The duplicate rule will determine if the duplicate record is allowed or blocked. Records that are blocked by the duplicate rule will appear in the error log.  

Updating Records with Data.com Clean :

It depends on what your organization’s duplicate rules are. If your duplicate rule is set to block duplicates on edit, then a record can’t be cleaned if cleaning creates a duplicate. For Clean jobs, if your duplicate rule is set to block or alert, then a record can’t be cleaned if the cleaning creates a duplicate. An entity error appears in the Clean Jobs History table for any record that can’t be cleaned during a job. If your duplicate rule is set to allow duplicates on edit, then a record can be cleaned even if it creates a duplicate. In addition, no alert displays when manually cleaning records even if your duplicate rule is set to alert.