Managing Duplicates in Salesforce

Part 31: Managing Duplicates in Salesforce

Duplicate records are one of the most common data quality issues in any CRM. A single customer represented by three different Account records, a Contact that appears twice with slightly different email addresses, a Lead that already exists as a Contact — these problems erode trust in your data, confuse sales reps, skew reports, and create friction across every business process that relies on accurate information.

Salesforce provides a built-in framework for managing duplicates that consists of two main components: Matching Rules and Duplicate Rules. Together, they allow you to detect potential duplicates at the point of entry (when a user creates or edits a record) and take action — whether that means alerting the user, blocking the save, or logging the duplicate for later review.

In this part of the Salesforce series, we will cover both tools end to end — how they work under the hood, the standard rules that come out of the box, how to create custom rules, the fuzzy matching algorithms Salesforce uses, duplicate jobs for bulk detection, and the best practices that keep your org clean.

Why Duplicate Management Matters

Before diving into the mechanics, it is worth understanding why duplicates are such a big deal.

The Cost of Duplicates

Where Duplicates Come From

Duplicates rarely appear because someone intentionally creates a second record. They typically arise from:

• Manual data entry — different users create records for the same entity using slightly different names or spellings (“Acme Corp” vs. “ACME Corporation” vs. “Acme, Inc.”)
• Data imports — bulk imports from spreadsheets, marketing tools, or legacy systems often contain records that already exist in Salesforce
• Web-to-Lead or Web-to-Case — form submissions create new records without checking for existing matches
• Lead conversion — converting a Lead without properly matching it to an existing Contact or Account
• Integrations — external systems push records into Salesforce without deduplication logic

Salesforce’s duplicate management framework is designed to catch these scenarios before they pollute your data.

The Duplicate Management Framework

Salesforce’s approach to duplicate management involves two distinct but tightly connected components:

┌──────────────────────────────────────────────────┐
│              Duplicate Management                │
│                                                  │
│   ┌──────────────────┐   ┌───────────────────┐   │
│   │  Matching Rules  │   │  Duplicate Rules  │   │
│   │                  │   │                   │   │
│   │  Define HOW to   │   │  Define WHAT to   │   │
│   │  compare records │──▶│  do when matches  │   │
│   │  (the algorithm) │   │  are found        │   │
│   │                  │   │  (the action)     │   │
│   └──────────────────┘   └───────────────────┘   │
│                                                  │
└──────────────────────────────────────────────────┘

• Matching Rules answer the question: “How do we determine that two records are the same entity?” They define which fields to compare and what algorithms to use for comparison.
• Duplicate Rules answer the question: “What should happen when a match is found?” They define the action — alert the user, block the record from being saved, or log the duplicate for review.

A Duplicate Rule always references one or more Matching Rules. The Matching Rule does the detection; the Duplicate Rule decides the response.

Matching Rules

A matching rule tells Salesforce how to identify potential duplicate records by specifying which fields to compare and how strictly to compare them.

Standard Matching Rules

Salesforce comes with several standard matching rules out of the box. These are pre-configured and cannot be edited, but they can be activated or deactivated.

These standard rules use Salesforce’s built-in fuzzy matching algorithms (more on those below) and are a good starting point for most orgs. However, many organizations need custom matching rules tailored to their specific data patterns.

How Matching Rules Work

When a matching rule is evaluated, Salesforce does the following:

1. Takes the field values from the new or edited record (the record being saved).
2. Searches existing records in the database for potential matches using the matching criteria.
3. Applies matching algorithms to each field comparison (exact match, fuzzy match, etc.).
4. Calculates a confidence score for each potential match based on how many fields matched and the matching method used.
5. Returns records that exceed the confidence threshold as potential duplicates.

The matching rule defines the equation that determines the confidence score. Each field comparison contributes to the overall score, and a record must meet or exceed the threshold to be flagged as a potential duplicate.

Matching Methods

Salesforce supports several matching methods for each field in a matching rule. Understanding these is essential for building effective custom rules.

Fuzzy Matching Algorithms Deep Dive

The “fuzzy” matching methods deserve special attention because they are what makes Salesforce’s duplicate detection genuinely useful. Without fuzzy matching, you would only catch exact duplicates — and in the real world, duplicates are rarely exact.

How Fuzzy Name Matching Works

The Fuzzy: Name algorithm applies multiple techniques:

• Nickname matching — “Bob” matches “Robert,” “Bill” matches “William,” “Mike” matches “Michael.” Salesforce maintains an internal nickname table.
• Initial matching — “J. Smith” can match “John Smith” or “James Smith.”
• Prefix/suffix handling — “Dr. Jane Doe” matches “Jane Doe.” Common prefixes (Mr., Mrs., Dr.) and suffixes (Jr., Sr., III) are stripped before comparison.
• Phonetic matching — Names that sound similar but are spelled differently may still match (e.g., “Schmidt” and “Schmitt”).
• Transposition tolerance — Swapped characters are tolerated to a degree (“Jonh” may match “John”).

How Fuzzy Company Name Matching Works

The Fuzzy: Company Name algorithm handles:

• Legal suffix stripping — “Acme Corporation,” “Acme Corp.,” “Acme Corp,” and “Acme Inc.” are all normalized before comparison.
• Common abbreviation expansion — “Intl” matches “International,” “Assoc” matches “Associates.”
• Word order flexibility — “Global Tech Solutions” may match “Tech Solutions Global” depending on the overall confidence score.
• The, A, An removal — articles at the start of names are ignored (“The Acme Company” matches “Acme Company”).

How Fuzzy Phone Matching Works

The Fuzzy: Phone algorithm normalizes phone numbers by:

• Stripping all non-numeric characters (parentheses, dashes, spaces, dots).
• Ignoring country codes and leading digits when comparing.
• Comparing the core digit sequence.

So “(415) 555-1234,” “415.555.1234,” “4155551234,” and “+1-415-555-1234” would all be considered matches.

Creating a Custom Matching Rule

While the standard matching rules work well for many scenarios, you will often need custom rules. Common reasons include:

• You want to match on custom fields (e.g., a custom “Tax ID” or “External ID” field).
• You want different matching logic than the standard rules provide.
• You want to match across objects (e.g., matching a Lead against existing Contacts).
• The standard rules are too broad or too narrow for your data.

Step-by-Step: Create a Custom Matching Rule

1. Navigate to Setup and search for Matching Rules in the Quick Find box.
2. Click New Rule.
3. Select the object — choose Account, Contact, Lead, or Person Account.
4. Enter a Rule Name and Description. Use a descriptive name like “Custom Account Match - Name and Tax ID.”
5. Configure the matching equation:
   • Click Add Filter Logic if you need AND/OR combinations.
   • For each row (matching criteria), select:
     • Field — the field to compare (e.g., Account Name).
     • Matching Method — Exact or one of the Fuzzy methods.
     • Match Blank Fields — whether blank fields should be considered matches or ignored.
6. Set the filter logic — by default, all criteria use AND logic (all must match). You can change this to OR or a custom combination like “(1 AND 2) OR 3.”
7. Click Save to create the rule in an Inactive state.
8. Click Activate to make the rule available for use in Duplicate Rules.

Example: Custom Matching Rule for Tax ID

Suppose your organization tracks a custom field called Tax_ID__c on the Account object and you want to use it as a primary matching criterion alongside the Account Name.

Filter Logic: 1 AND 2

This rule will flag an account as a potential duplicate only when both the company name is a fuzzy match AND the Tax ID is an exact match. Setting “Match Blank Fields” to “No” for Tax ID ensures that records without a Tax ID are not incorrectly flagged.

Example: Custom Matching Rule for Email-Only Match

For Leads and Contacts, email is often the single most reliable identifier:

Filter Logic: 1

This simple rule catches any Lead or Contact with the same email address, regardless of name differences.

Matching Rule Limits and Considerations

Keep these constraints in mind when working with matching rules:

• You can have a maximum of 5 active matching rules per object (across standard and custom rules combined).
• Each matching rule can have up to 10 matching criteria (field comparisons).
• Standard matching rules cannot be edited — only activated or deactivated.
• Custom matching rules must be deactivated before they can be edited.
• Once activated, a matching rule enters a processing state while Salesforce indexes the data. This can take time in large orgs.
• Matching rules work on Accounts, Contacts, Leads, and Person Accounts only. They do not support custom objects or other standard objects.
• The matching process is subject to governor limits — in a single duplicate rule evaluation, Salesforce compares the incoming record against a maximum of approximately 100 potential matches returned by the matching index.

Duplicate Rules

Once you have matching rules that can detect potential duplicates, you need duplicate rules to decide what happens when a match is found. A duplicate rule connects a matching rule to an action.

Standard Duplicate Rules

Just like matching rules, Salesforce includes standard duplicate rules:

By default, the standard duplicate rules are configured to alert the user — they show a warning message listing potential duplicates but still allow the user to save the record. They do not block the save.

Anatomy of a Duplicate Rule

Every duplicate rule consists of these components:

1. Record-Level Security

This setting controls whether the duplicate rule respects sharing rules when searching for matches:

• Enforce sharing rules — the rule only shows potential duplicates that the current user has access to. This is more privacy-friendly but may miss duplicates the user cannot see.
• Bypass sharing rules — the rule searches all records regardless of the user’s access. This provides more comprehensive detection but may reveal that a record exists even if the user should not know about it.

2. Action on Create

What happens when a user creates a new record that matches an existing record:

3. Action on Edit

What happens when a user edits an existing record in a way that makes it match another record:

4. Matching Rules Assignment

A single duplicate rule can reference up to three matching rules. This is where cross-object matching becomes possible. For example, a duplicate rule on the Lead object could reference:

• A Lead-to-Lead matching rule (check if the new Lead matches existing Leads).
• A Lead-to-Contact matching rule (check if the new Lead already exists as a Contact).
• A Lead-to-Account matching rule (check if the new Lead’s company already exists as an Account).

This cross-object capability is one of the most powerful features of the duplicate management framework.

5. Alert Text

You can customize the message shown to users when duplicates are detected. This is useful for providing context-specific instructions, such as “A lead with this email already exists. Please check the existing leads below before saving.”

6. Report Options

You can configure the duplicate rule to log potential duplicates to Duplicate Record Sets and Duplicate Record Items even when the user proceeds with the save. This creates a paper trail that data stewards can review later.

Creating a Custom Duplicate Rule

Step-by-Step: Create a Custom Duplicate Rule

1. Navigate to Setup and search for Duplicate Rules in the Quick Find box.
2. Click New Rule.
3. Select the object — Account, Contact, Lead, or Person Account.
4. Enter a Rule Name and Description.
5. Record-Level Security — choose whether to enforce or bypass sharing rules.
6. Action on Create — select Allow, Alert, or Block. If you choose Alert or Block, optionally customize the alert text.
7. Action on Edit — select Allow, Alert, or Block.
8. Matching Rules — click Add Matching Rule and select one or more matching rules. For each matching rule, you specify:
   • The matching rule to use.
   • The object to compare against (same object or a different object for cross-object matching).
   • A field mapping if you are doing cross-object matching (e.g., mapping the Lead’s Email field to the Contact’s Email field).
9. Report options — check the boxes to log duplicate record sets and items.
10. Click Save to create the rule in an Inactive state.
11. Click Activate to turn it on.

Example: Block Duplicate Leads, Alert for Lead-to-Contact Matches

Suppose you want to prevent duplicate Leads entirely but only warn users when a Lead matches an existing Contact (since converting the Lead might be the right action):

Duplicate Rule: Lead Duplicate Prevention

Matching Rules:

Note: When a duplicate rule has Block as the action, it blocks saves when the same-object matching rule finds matches. Cross-object matches typically result in alerts regardless, since the user may need to proceed with a different action (like Lead conversion).

Duplicate Rule Behavior in Different Contexts

Duplicate rules do not behave identically in every context. Understanding where they fire and where they do not is critical.

The last two rows are especially important. Web-to-Lead does not invoke duplicate rules, which means duplicates can still enter your org through web forms. This is a common gap that organizations address with post-processing flows or scheduled deduplication jobs.

Duplicate Rules and the API

When records are created or updated through the API (including Data Loader, integrations, and Apex), duplicate rule behavior is controlled by the allowSave and includeRecordDetails settings in the DuplicateRuleHeader.

For Apex, you control this through Database.DMLOptions:

Database.DMLOptions dml = new Database.DMLOptions();
dml.DuplicateRuleHeader.allowSave = true;
dml.DuplicateRuleHeader.runAsCurrentUser = true;

Account acc = new Account(Name = 'Acme Corp');
Database.SaveResult sr = Database.insert(acc, dml);

if (!sr.isSuccess()) {
    for (Database.Error err : sr.getErrors()) {
        if (err instanceof Database.DuplicateError) {
            Database.DuplicateError dupErr = (Database.DuplicateError) err;
            Datacloud.DuplicateResult dupResult = dupErr.getDuplicateResult();
            // Handle duplicate detection
        }
    }
}

When allowSave is set to true, the record is saved even if duplicates are found, but the duplicate information is still returned in the SaveResult so your code can log or process it. When set to false, the save is blocked and you receive a DuplicateError.

Duplicate Record Sets and Duplicate Record Items

When a duplicate rule is configured with reporting enabled and a user saves a record despite a duplicate warning, Salesforce creates two types of records:

Duplicate Record Sets

A Duplicate Record Set is a standard Salesforce object that groups together records that have been identified as potential duplicates of each other. Think of it as a “cluster” of records that likely represent the same entity.

Key fields on a Duplicate Record Set:

Duplicate Record Items

Each record within a Duplicate Record Set is represented by a Duplicate Record Item. This is the junction object that links individual records to the set.

Key fields on a Duplicate Record Item:

Using Duplicate Record Sets for Data Cleanup

The real power of Duplicate Record Sets is that they give your data stewards a centralized place to review and resolve duplicates:

1. Create a List View on the Duplicate Record Set object to see all identified duplicate clusters.
2. Create a Report using the “Duplicate Record Sets” or “Duplicate Record Items” report type to analyze the scope of the problem.
3. Merge or resolve duplicates from the list. Salesforce supports merging up to three Accounts, Contacts, or Leads at a time from the record detail page.
4. Track resolution progress by creating dashboards that show the number of open duplicate record sets over time.

Duplicate Jobs

Matching rules and duplicate rules catch duplicates at the point of entry — when records are created or edited. But what about the duplicates that already exist in your org? That is where Duplicate Jobs come in.

What Are Duplicate Jobs?

A duplicate job is a batch process that scans your existing data against one or more matching rules and identifies potential duplicates that are already in the database. It does not merge or delete any records — it only populates Duplicate Record Sets and Duplicate Record Items so you can review and resolve them.

Running a Duplicate Job

1. Navigate to Setup and search for Duplicate Jobs in the Quick Find box.
2. Click New Job.
3. Select the object to scan (Account, Contact, Lead, or Person Account).
4. Select the matching rule(s) to use for detection. You can select up to five matching rules for a single job.
5. Optionally, add field filters to narrow the scope of the scan (e.g., only scan Accounts created in the last 90 days).
6. Click Run.

Duplicate Job Considerations

• Duplicate jobs can take a significant amount of time depending on the volume of data. A job scanning millions of records may run for hours.
• Results are written to Duplicate Record Sets and Duplicate Record Items, just like real-time duplicate detection.
• You can schedule duplicate jobs to run on a recurring basis (e.g., weekly) to continuously monitor data quality.
• Duplicate jobs do not merge records. They only identify potential duplicates. The actual resolution is a manual or automated follow-up step.
• There is a limit on the number of duplicate jobs that can run concurrently and the total number of records processed per job. These limits vary by edition.

Merging Duplicate Records

Once duplicates are identified — whether through real-time rules or duplicate jobs — the next step is resolution. Salesforce provides a built-in merge function for Accounts, Contacts, and Leads.

How to Merge Records

1. Navigate to the record you want to keep as the “master.”
2. Click the dropdown arrow next to the record name (or use the action menu) and select Merge Accounts, Merge Contacts, or Find Duplicates (depending on the object and your interface).
3. Search for duplicates — Salesforce will search for potential matches.
4. Select the records to merge — you can merge up to three records at a time.
5. Choose field values — for each field, select which record’s value to retain in the merged record.
6. Click Merge.

What Happens During a Merge

• The master record survives. The other records are deleted.
• Related records (child records like Opportunities, Cases, Activities, etc.) from the deleted records are reparented to the master record.
• Chatter feeds from all merged records are combined into the master record’s feed.
• The deleted records are moved to the Recycle Bin for 15 days, during which the merge can be undone.
• If the merged records were in different Duplicate Record Sets, those sets are updated or removed as appropriate.

Merge Limitations

• You can merge a maximum of 3 records at a time.
• Merging is available for Accounts, Contacts, Leads, Cases, and Person Accounts. It is not available for custom objects.
• Some related records may not be reparented automatically (e.g., certain types of junction object records).
• Field history tracking records are not moved — they stay associated with the deleted record.
• Merge operations fire triggers, validation rules, and workflow rules, which can cause unexpected failures if not accounted for.

Cross-Object Duplicate Detection

One of the most valuable capabilities of the duplicate management framework is cross-object matching. This allows you to detect duplicates across different objects — most commonly, matching Leads against Contacts or Accounts.

Why Cross-Object Matching Matters

Consider this scenario: A marketing campaign generates 500 new Leads through a web form. Of those 500 Leads, 200 are people who already exist as Contacts in your Salesforce org. Without cross-object matching, those 200 Leads would be created as new records, and your sales team would waste time working leads that are already customers.

Cross-object matching catches this by comparing the incoming Lead against existing Contact records using a matching rule that maps fields between the two objects.

Setting Up Cross-Object Matching

To set up cross-object matching, you create a duplicate rule on the source object (e.g., Lead) and add a matching rule that compares against the target object (e.g., Contact):

1. Create or select a matching rule on the target object (e.g., a Contact matching rule that uses Email and Last Name).
2. Create a duplicate rule on the source object (e.g., Lead).
3. In the duplicate rule, add the matching rule and specify the object mapping:
   • Lead.Email maps to Contact.Email
   • Lead.LastName maps to Contact.LastName
   • Lead.FirstName maps to Contact.FirstName
4. Configure the action (Alert or Block) and activate the rule.

Now, when a user creates a Lead, Salesforce checks it against both existing Leads (if you also have a Lead-to-Lead matching rule) and existing Contacts.

Third-Party Duplicate Management Tools

While Salesforce’s built-in duplicate management handles many common scenarios, some organizations require more advanced capabilities. It is worth knowing what the AppExchange ecosystem offers:

If your org’s needs exceed what the standard tools provide — especially if you need automated merging with survivorship rules or duplicate detection on custom objects — evaluating AppExchange solutions like Cloudingo, DemandTools, or Duplicate Check is worthwhile.

Best Practices

1. Start with Standard Rules

Activate the standard matching rules and standard duplicate rules before building custom ones. They cover the most common scenarios and give you a baseline to evaluate. Review the results for a few weeks before deciding whether custom rules are needed.

2. Use Alert Before Block

Start with the Alert action rather than Block. Blocking can frustrate users, especially if your matching rules produce false positives. Use Alert to let users see potential duplicates and make informed decisions. Once you have confidence in your matching rules’ accuracy, selectively switch high-confidence scenarios to Block.

3. Enable Reporting on All Rules

Always enable the reporting options (Duplicate Record Sets and Duplicate Record Items) on your duplicate rules. Even if you start with Alert or Allow, the reporting gives your data team visibility into the scope of the duplicate problem and the effectiveness of your rules.

4. Handle the Gaps

Remember that duplicate rules do not fire for Web-to-Lead, Web-to-Case, or certain API contexts by default. Plan for these gaps:

• Use after-save record-triggered flows to check for duplicates on records created through Web-to-Lead.
• Configure API settings appropriately for integrations and data loads.
• Run duplicate jobs on a regular schedule to catch anything that slips through.

5. Be Strategic with Field Matching

Do not create matching rules that are too broad (many false positives) or too narrow (many misses):

• Too broad: Matching on Last Name alone will flag thousands of “Smith” records as duplicates.
• Too narrow: Requiring an exact match on Name, Email, Phone, and Address will miss legitimate duplicates where one field is slightly different.
• Just right: Combine a fuzzy name match with an exact email match, or a fuzzy company name with an exact Tax ID.

6. Account for Data Quality

Your matching rules are only as good as your data. If your org has inconsistent data entry (e.g., phone numbers stored in different formats, addresses entered in different ways), fuzzy matching will help — but it cannot solve everything. Consider:

• Using validation rules to enforce consistent data formats at entry.
• Implementing Apex triggers or flows that normalize data before save (e.g., stripping phone formatting, standardizing state abbreviations).
• Running periodic data cleanup initiatives to standardize existing records.

7. Communicate with Users

When you implement duplicate rules, especially with Block actions, communicate the change to your users:

• Explain why duplicate prevention matters.
• Show them how to handle the duplicate warning (review existing records, merge if needed, or proceed if it is a false positive).
• Provide a process for reporting false positives so you can refine your matching rules.

8. Monitor and Iterate

Duplicate management is not a “set it and forget it” feature. Regularly review:

• Duplicate Record Sets — are they growing or shrinking? Are users resolving them?
• False positive rate — are users frequently saving despite Alert warnings? That may indicate the rules are too aggressive.
• False negative rate — are duplicates still entering the system? That may indicate the rules are too lenient.
• User feedback — are users frustrated by the duplicate warnings? Adjust the rules or the alert text.

Common Pitfalls and Limitations

Limitations to Be Aware Of

1. Object support is limited — matching rules and duplicate rules only work on Accounts, Contacts, Leads, and Person Accounts. No custom objects.
2. Five active matching rules per object — this is a hard limit. Plan your rules carefully.
3. Three matching rules per duplicate rule — you cannot reference more than three matching rules in a single duplicate rule.
4. Web-to-Lead blind spot — duplicate rules do not fire on Web-to-Lead submissions.
5. Merge limit of three records — you can only merge three records at a time, which can be tedious when many duplicates exist.
6. No automated merging — Salesforce does not provide a declarative way to auto-merge duplicates. Merging is always manual (unless you build custom Apex or use a third-party tool).
7. Matching rule activation time — after activating a new matching rule, it enters a processing state while Salesforce builds the matching index. In large orgs, this can take hours.
8. Cross-object matching is one-directional — a duplicate rule on Leads can check against Contacts, but the reverse (a duplicate rule on Contacts checking against Leads) requires a separate rule.
9. Encrypted fields — matching rules cannot use encrypted fields (Shield Platform Encryption) for fuzzy matching.
10. Person Account complexity — if your org uses Person Accounts, you need separate matching and duplicate rules for them, and the interaction between Account rules and Person Account rules can be confusing.

Troubleshooting Common Issues

Putting It All Together: A Complete Implementation Example

Let us walk through a complete implementation scenario to tie everything together.

Scenario

Your company has an org with 50,000 Accounts, 150,000 Contacts, and 30,000 Leads. Duplicate data is a known problem. You need to:

1. Prevent new duplicates from being created.
2. Identify existing duplicates for cleanup.
3. Catch Leads that already exist as Contacts.

Implementation Plan

Step 1: Activate Standard Rules

1. Go to Setup > Matching Rules. Activate the Standard Account, Contact, and Lead matching rules.
2. Go to Setup > Duplicate Rules. Activate the Standard Account, Contact, and Lead duplicate rules.
3. Set all rules to Alert on create and edit. Enable reporting.

Step 2: Create Custom Matching Rules

Create a custom matching rule for Contacts that emphasizes email:

Create a cross-object matching rule for Lead-to-Contact matching:

Filter Logic: 1 OR 2

Step 3: Create Custom Duplicate Rules

Create a duplicate rule on the Lead object:

Add matching rules:

• Standard Lead Matching Rule (compare against Leads)
• Custom Lead-to-Contact Matching Rule (compare against Contacts)

Step 4: Run Duplicate Jobs

1. Go to Setup > Duplicate Jobs.
2. Run a job for Accounts using the Standard Account Matching Rule.
3. Run a job for Contacts using both the Standard Contact Matching Rule and the custom Email matching rule.
4. Run a job for Leads using the Standard Lead Matching Rule.

Step 5: Review and Resolve

1. Create a report on Duplicate Record Sets grouped by Duplicate Rule.
2. Assign data stewards to review and merge duplicates.
3. Schedule weekly duplicate jobs to catch any new duplicates that slip through.

Step 6: Tighten the Rules

After two to four weeks of monitoring:

• Review the false positive rate. If it is low, consider switching high-confidence scenarios from Alert to Block.
• Review the false negative rate. If duplicates are still entering, add additional matching criteria or create new matching rules.
• Adjust alert text based on user feedback.

Summary

Duplicate management is not glamorous, but it is one of the highest-impact things an admin can do. Clean data drives accurate reports, efficient sales processes, and reliable automation. The time you invest in setting up and maintaining matching rules and duplicate rules pays dividends across the entire organization.

In Part 32, we will cover Managing Salesforce Releases — how to stay on top of Salesforce’s three annual releases, understand release notes, evaluate release updates in Setup, and prepare your org for new features without surprises. See you there.