Study guide
2.3 Duplicate Detection Rules & Settings
Microsoft Power Platform Functional Consultant PL-200
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Dataverse Tables, Relationships & Core Columns
1.1 Dataverse Table Types, Properties & Ownership 1.2 Table Relationships & Cascading Rules 1.3 Column Types, Formats, Primary Keys & Alternate Keys 1.4 Rollup, Calculated & Formula Columns with Power Fx
2 Chapter 2: Dataverse Data Management & Governance
2.1 Dataverse Search, Quick Find & Relevance Indexing 2.2 Auditing Configuration & Log Management 2.3 Duplicate Detection Rules & Settings 2.4 Bulk Record Operations, Data Import, Export & Templates
3 Chapter 3: Dataverse Security Model & Access Control
3.1 Business Units, Ownership Models & Modern BU Matrix 3.2 Security Roles, Privileges & Depth Levels 3.3 Teams Architecture: Owner, Access, and Microsoft Entra (AAD) Group Teams 3.4 Column-Level Security & Hierarchy Security Models
4 Chapter 4: Model-Driven App Fundamentals & Information Architecture
4.1 Model-Driven App Design, Site Map Navigation & Modern App Designer 4.2 Form Types: Main, Quick Create, Quick View & Card Forms 4.3 View Configuration, System Views, Personal Views & Filters
5 Chapter 5: Advanced Model-Driven App Components & Custom Pages
5.1 Custom Pages & Modern Commanding with Power Fx 5.2 Form Component Controls & Specialized UX Elements 5.3 Embedding Canvas Apps in Model-Driven Forms 5.4 Embedding Power BI Reports, Dashboards & Tiles
6 Chapter 6: Canvas Apps Structure, Formulas & Data Operations
6.1 Canvas App Architecture, Screens, Containers & Controls 6.2 Power Fx Formulas, Delegation & Data Source Limits 6.3 Variables (Context, Global), Collections & State Management 6.4 Triggering Power Automate Cloud Flows from Canvas Apps
7 Chapter 7: Power Pages Site Design, Navigation & Content
7.1 Power Pages Design Studio & Site Structure 7.2 Power Pages Templates, Styling & Responsive Layouts 7.3 Web Pages, Navigation Menus & Content Snippets
8 Chapter 8: Power Pages Data Integration, Forms & Web Roles
8.1 Power Pages Lists, Basic Forms & Advanced Forms 8.2 Table Permissions, Web Roles & Page Access Security 8.3 External Identity Providers & Authentication Configuration
9 Chapter 9: Power Automate Cloud Flow Fundamentals & Triggers
9.1 Cloud Flow Types: Automated, Instant, Scheduled & Desktop Overview 9.2 Dataverse Connector Triggers & Operational Filters 9.3 Standard Connectors, Custom Connectors & Connection References
10 Chapter 10: Cloud Flow Actions, Expressions & Logic Controls
10.1 Logic Controls: Conditions, Switches, Apply to Each & Do Until Loops 10.2 Variables, Data Operations & Dynamic Content Manipulation 10.3 Power Automate Expression Language (WDL / Functions) 10.4 Error Handling, Configure Run After & Scope Controls
11 Chapter 11: Business Process Flows & Guided Processes
11.1 Business Process Flow Architecture, Stages, Steps & Data Steps 11.2 Branching Rules & Multi-Entity Business Process Flows 11.3 BPF Action Steps, Workflows & Cloud Flow Execution 11.4 BPF Security Roles, Order & Process Lifecycle
12 Chapter 12: Classic Workflows, Business Rules & Modern Logic Extensibility
12.1 Classic Dataverse Workflows: Real-Time vs. Background (Async) 12.2 Business Rules: Scope & Actions 12.3 Low-Code Plug-ins in Dataverse: Automated vs. Instant 12.4 Troubleshooting Automations, Run History & Analytics
13 Chapter 13: Power Platform Environment Architecture & Security
13.1 Environment Types: Default, Sandbox, Production, Trial, Developer 13.2 Environment Governance, Groups, Routing & Capacity Management 13.3 Data Loss Prevention (DLP) Policies & Connector Classifications
14 Chapter 14: Application Lifecycle Management (ALM) & Solutions
14.1 Unmanaged vs. Managed Solutions & Solution Layering Mechanics 14.2 Solution Components, Dependencies, Publishers & Prefixes 14.3 Exporting, Importing, Upgrading & Patches 14.4 Solution Checker, App Checker & ALM Best Practices
15 Chapter 15: Enterprise Interoperability & Service Integration
15.1 Exchange / Server-Side Synchronization & Email Integration 15.2 SharePoint & OneDrive Document Management Integration 15.3 Microsoft Word & Excel Document Templates
16 Chapter 16: Copilot, AI Capabilities & Exam Strategy
16.1 Copilot Studio & Generative AI across Power Platform 16.2 AI Builder Prebuilt & Custom Models in Apps and Flows 16.3 PL-200 Exam Strategy, Time Management & Question Analysis
2.3 Duplicate Detection Rules & Settings
Key Takeaways Explain This Topic AI
Duplicate detection rules evaluate records based on defined matching criteria between a Base Table and a Matching Table (which can be the same table or two distinct tables like Lead and Contact).
Matching criteria options include Exact Match, Same First N Characters, Same Last N Characters, Same Date, and Same Date and Time, with modifiers to ignore blank values and enforce case sensitivity.
A maximum of 5 active (published) duplicate detection rules can be enabled per table at any given time.
Duplicate detection triggers interactively during model-driven form saves (modal warning dialog), during Data Import wizard execution, during mobile offline synchronization, and via scheduled Bulk Duplicate Detection jobs.
Automated API and Power Automate transactions bypass duplicate detection by default unless explicitly configured via the MSCRM.SuppressDuplicateDetection header.
Last updated: August 2026
Duplicate Detection Rules & Settings
Data integrity is vital for accurate analytics, customer relationship management, and automated business processes. Duplicate records lead to fragmented histories, inaccurate reporting, and wasted marketing spend. Microsoft Dataverse provides a robust, configurable Duplicate Detection Engine that detects potential duplicates before or after records are created.
For the PL-200 exam, functional consultants must master duplicate detection rule construction, matching operators, cross-table comparison mechanics, trigger events, and bulk deduplication jobs.
1. Duplicate Detection Settings & Architecture
Duplicate detection operates at two layers: Environment-level settings that control when the engine executes, and Table-level rules that define the matching logic. +-----------------------------------------------------------------------------------+
- | DUPLICATE DETECTION ENGINE ARCHITECTURE |
- | |
- | [GLOBAL SETTINGS (PPAC / Data Management)] |
- | [x] Enable Duplicate Detection across Environment |
- | | |
- | +---> [x] When a record is created or updated |
- | +---> [x] When Dataverse for Outlook / Mobile goes offline to online |
- | +---> [x] During data import |
- | |
- | [PUBLISHED RULES (Max 5 Active Rules per Table)] |
- | - Generates match codes / hash indexes upon publishing |
- | - Compares Base Table against Matching Table |
- +-----------------------------------------------------------------------------------+
- Global Trigger Configuration
In PPAC or the classic settings area ( Settings > Data Management > Duplicate Detection Settings ), administrators configure the global trigger points:
When a record is created or updated: Evaluates rules in real time when a user saves a form.
When Dataverse for Outlook/Mobile transitions from offline to online: Catches duplicates created on mobile devices while disconnected.
During data import: Evaluates incoming records against existing data during Data Import Wizard runs.
2. Anatomy of a Duplicate Detection Rule
A duplicate detection rule specifies how Dataverse compares records. +-----------------------------------------------------------------------------------+
- | DUPLICATE DETECTION RULE CONFIGURATION |
- | |
- | RULE NAME: [Lead to Contact Email & Name Match] |
- | BASE TABLE: [Lead] MATCHING TABLE: [Contact] |
- | |
- | CRITERIA TABLE: |
- | +-------------------+----------------------+-------------------+--------------+ |
- | | Base Table Field | Matching Table Field | Operator | Ignore Blank | |
- | +-------------------+----------------------+-------------------+--------------+ |
- | | Email | Email Address 1 | Exact Match | [x] Yes | |
- | | First Name | First Name | Same First 3 Chars| [x] Yes | |
- | | Last Name | Last Name | Exact Match | [ ] No | |
- | +-------------------+----------------------+-------------------+--------------+ |
- +-----------------------------------------------------------------------------------+
Key Components of a Rule:
Base Table: The primary table on which the rule is defined (the record being created or updated).
Matching Table: The target table against which the Base record is compared. The Matching Table can be identical to the Base Table (e.g., Contact to Contact for intra-table deduplication) or a different table (e.g., Lead to Contact or Lead to Account for cross-table matching).
Matching Criteria Operators:
Exact Match : String or value must match character-for-character.
Same First Characters : Matches the first N characters (e.g., first 5 characters of Postal Code or first 3 of First Name).
Same Last Characters : Matches the trailing N characters (e.g., last 7 digits of a Phone Number, ignoring country/area codes).
Same Date : Matches calendar date while ignoring time components.
Same Date and Time : Matches both date and timestamp exactly.
Modifiers:
Ignore Blank Values: When checked, records with null/empty values in that field will not be considered duplicates. Always enable this for optional fields to prevent matching thousands of records with empty values.
Case-Sensitive: Enforces exact casing (e.g., "Contoso" vs "contoso"). Typically left disabled.
The 5-Rule Limit & Matchcode Generation
Important
Rule Ceiling: Dataverse allows you to define unlimited duplicate detection rules, but no more than 5 rules can be in a Published (Active) state per table at any time. When a rule is published, Dataverse creates an internal matchcode (hash index) for each record. Publishing takes time depending on table record volume.
3. Trigger Scenarios & User Experiences
Dataverse handles duplicate detection differently depending on the context in which data is entered or processed. +-----------------------------------------------------------------------------------+
- | DUPLICATE DETECTION TRIGGER SCENARIOS |
- | |
- | +-----------------------------------------------------------------------------+ |
- | | 1. MODEL-DRIVEN FORM SAVE (Interactive User Experience) | |
- | | User enters duplicate data ---> Clicks 'Save' ---> Warning Modal Appears | |
- | | Modal lists matching records ---> Options: [Ignore and save] or [Cancel] | |
- | +-----------------------------------------------------------------------------+ |
- | | 2. DATA IMPORT WIZARD (Batch Ingestion) | |
- | | Import setting: 'Enable Duplicate Detection: Yes/No' | |
- | | Duplicates logged as errors/warnings or excluded based on settings | |
- | +-----------------------------------------------------------------------------+ |
- | | 3. BULK DUPLICATE DETECTION SYSTEM JOBS (Asynchronous Scans) | |
- | | Scheduled query scan across entire table ---> Generates duplicate report | |
- | +-----------------------------------------------------------------------------+ |
- | | 4. WEBSERVICE / API / POWER AUTOMATE (Automated Flows) | |
- | | Default: Bypasses duplicate detection silently | |
- | | Enforce via HTTP Header: 'MSCRM.SuppressDuplicateDetection: false' | |
- | +-----------------------------------------------------------------------------+ |
- +-----------------------------------------------------------------------------------+
Trigger Scenarios Detailed:
Model-Driven Interactive Save: When a user creates or updates a record via a form, Dataverse checks active matchcodes. If a match is detected, an interactive Duplicates detected modal displays the existing matching records. The user can review the records and click Ignore and save to create the record anyway, or Cancel to abort and merge.
Data Import Wizard: During data import, the wizard prompts Enable Duplicate Detection . If set to No , all records import regardless of duplicates. If set to Yes , imported records matching existing records are rejected and reported in the import failure log.
Bulk Duplicate Detection Jobs: Administrators can schedule background system jobs that run FetchXML queries against active tables. The job scans records, identifies duplicates, and presents them in a dedicated review list where administrators can inspect and merge records.
4. Merging Records in Dataverse
When duplicate records exist, Dataverse provides native Merge capabilities for standard entities: Account , Contact , Lead , and Incident (Case) . +-----------------------------------------------------------------------------------+
- | RECORD MERGING WORKFLOW |
- | |
- | [Select 2 Records] ---> Click [Merge] on Command Bar |
- | | |
- | v |
- | [Select Master Record] ---> Choose which record retains the Primary ID |
- | | |
- | v |
- | [Field-by-Field Selection] ---> Choose surviving attribute values |
- | | |
- | v |
- | [Merge Execution] ---> Dataverse performs 3 automated actions: |
- | 1. Updates Master Record with selected surviving values |
- | 2. Reparents all subordinate Child Records (Activities, Orders, Cases) |
- | 3. Deactivates (Sets to Inactive) the Subordinate Record |
- +-----------------------------------------------------------------------------------+
Core Rules for Merging:
You can merge up to 2 records at a time in the standard user interface.
The subordinate record is deactivated (soft-deleted) , never permanently deleted, preserving historical references and audit trails.
All related child records (appointments, tasks, emails, child cases, invoices) are automatically reparented to the master record.
5. API & Power Automate Considerations
In modern automated architectures involving Power Automate cloud flows, Azure Functions, or custom web services, developers frequently encounter unexpected duplicate behavior:
Default API Behavior: Programmatic Create and Update requests through the Dataverse Web API and standard Power Automate connectors suppress duplicate detection by default to maximize ingestion performance.
Enforcing Duplicate Detection in APIs: To enforce rules, the calling client must pass the following HTTP header: MSCRM.SuppressDuplicateDetection: false
If a duplicate is detected when this header is present, the API throws an HTTP 412 Precondition Failed error containing the GUIDs of matching duplicate records.