How to Prevent Duplicates in Power Apps Forms (Dataverse and Dynamics 365)

Every Power Apps form is a door into your database. A canvas app on a tablet, a model-driven form in Dynamics 365, a Power Pages form on your website: each one lets a person type a name and an email address and press Save. If nothing checks whether that person already exists, you have just built a duplicate factory with a friendly user interface. This guide walks through every layer of prevention Microsoft gives you, what each layer actually blocks, and where all of them stop.

Why forms create duplicates in the first place

Duplicates rarely come from carelessness. They come from speed. A field seller adds a contact from the car before the meeting. A support agent creates a new case contact because the search returned nothing for “Jon Petersen” when the record was saved as “John Pedersen”. An event app imports 400 registrations, half of them people who already exist. In every case the form did exactly what it was asked, and nobody was looking for a match.

Prevention therefore has to happen at the point of entry, inside the form or in the data platform underneath it. Anything that runs later is cleanup, not prevention.

Layer 1: alternate keys in Dataverse

An alternate key tells Dataverse that a column, or a combination of columns, must be unique. Define an alternate key on the email column of the Contact table and the platform refuses a second record with the same email, whoever creates it: a canvas app, a model-driven form, an integration, a bulk import. This is the only mechanism in the stack that blocks at the database level, and for hard identifiers like customer numbers, VAT numbers or employee IDs it is the right tool.

Two limitations matter. Alternate keys compare exact values, so a trailing space or a capital letter in the email creates a “different” value that passes. And they only work for columns that are genuinely unique in your business. A key on last name plus city would reject a second Jensen in Aarhus, which is not a duplicate at all.

Layer 2: duplicate detection rules in model-driven apps

For Dynamics 365 and model-driven Power Apps, the native duplicate detection rules run when a record is saved through a form and show a dialog listing the potential matches. They support exact matching on one or more columns, with same-first-characters and same-last-characters variants. Configuring them is simple; keeping them running is not. Rules unpublish themselves whenever they are edited, there is a limit of five published rules per table, and the dialog warns rather than blocks, so a user under time pressure clicks Ignore and save. If your rules seem to do nothing, the full checklist is in duplicate detection rules not working in Dynamics 365.

Layer 3: lookups before you patch in canvas apps

Canvas apps do not trigger the duplicate detection dialog at all. A Patch or SubmitForm call writes straight to Dataverse, and unless an alternate key rejects it, the record lands. The pattern that fixes this is search first, create second.

Before saving, look up the table with the values the user typed, normalized the same way they are stored:

Set(varExisting,
    LookUp(Contacts,
        Lower(Trim('Email')) = Lower(Trim(txtEmail.Text))
    )
);

If varExisting is not blank, show the existing record and offer to open it instead of creating a new one. Bind the Save button’s DisplayMode to that check so the create path is disabled while a match exists. For accounts, replace free-text company fields with a combo box over the Account table so users select an existing record rather than typing a new spelling of it. If you use alternate keys, wrap the save in IfError and turn the platform’s rejection into a clear message instead of a red banner.

Layer 4: business rules and required fields

Many duplicates are only possible because the first record was incomplete. A contact with no email cannot be matched on email later. Business rules and required columns close that gap: require at least one of email or mobile phone, enforce formats, and make the fields that identify a person mandatory. Clean input today is what makes matching possible tomorrow.

Where all four layers stop

Put the layers together and you block exact repeats through every channel. What you still do not catch is the duplicate that is not spelled the same. Kristensen and Christensen. A mobile number stored with and without the country code. “Novo Nordisk A/S” and “Novo Nordisk”. None of the native mechanisms do fuzzy or phonetic matching, so this whole class of records walks through unchallenged; we cover why in the duplicate you cannot see.

The second gap is history. Prevention starts on the day you switch it on. The duplicates already in the table stay where they are, and every new record has a chance of matching one of them rather than the clean version.

The third gap is visibility. Nothing in the native stack tells you whether the duplicate rate is going up or down, so you find out when a customer receives two invoices.

What a complete approach looks like

The Data Quality App works on any Dataverse table, so it protects canvas apps, model-driven apps and Dynamics 365 forms alike. Live duplicate monitoring checks new records as they are created and flags matches on the record itself, using exact, fuzzy and phonetic matching rather than exact matchcodes. Data quality rules enforce completeness and formats at the point of entry across every table. Background detection scans the whole database for the historical duplicates and resolves them with bulk merge, and Data Health Studio measures the result over 30, 60 and 90 days so you can see the trend rather than guess it. For the wider picture of governance on the platform, see the Dataverse data quality guide.

If you want to know how many duplicates your forms have already let in, the free 15-day trial runs across your full environment and reports every match the native rules missed.

Frequently asked questions

Does Power Apps have built-in duplicate detection?

Model-driven Power Apps and Dynamics 365 use the Dataverse duplicate detection rules, which warn on exact matches when a record is saved through a form. Canvas apps do not trigger those rules; you prevent duplicates there with alternate keys in Dataverse and a lookup in the app before you create the record.

What is the difference between an alternate key and a duplicate detection rule?

An alternate key is a uniqueness constraint enforced by Dataverse for every channel, including integrations and imports, and it blocks the save. A duplicate detection rule only runs for form saves and imports, matches on exact values, and shows a warning the user can ignore.

Can I stop fuzzy or misspelled duplicates in Power Apps forms?

Not with native features. Alternate keys, duplicate rules and canvas lookups all compare exact values. Catching spelling variants and sound-alike names requires fuzzy and phonetic matching, which is what the Data Quality App adds on top of Dataverse, together with bulk merge for the duplicates that already exist.