Duplicate detection: proteggere la qualità dei dati

In Dynamics 365 Sales (su piattaforma Dataverse), la duplicate detection individua record potenzialmente duplicati confrontando i valori dei campi secondo criteri definiti. Il sistema si articola su due componenti che vanno tenuti distinti all’esame.

Duplicate detection rules

Una duplicate detection rule definisce, per una specifica table (es. Account, Contact, Lead), quali campi confrontare e con quale operatore di match: Exact Match, Same First Characters, Same Last Characters. Ogni regola:

  • è legata a una base table e a una matching table (di norma la stessa, ma è possibile il cross-table, es. Lead vs Contact);
  • diventa operativa solo dopo essere stata pubblicata (Publish), passaggio che genera i matchcode indicizzati usati per il confronto rapido;
  • può combinare più criteri, opzionalmente ignorando i valori vuoti e la case sensitivity.

Una considerazione architetturale chiave: il confronto avviene sui matchcode, non “live” sui dati. Se modifichi una regola devi unpublish → modifica → republish.

Job sincroni vs bulk

La detection si attiva in due modi con logiche diverse:

  • Sincrona (al salvataggio): quando un utente crea o aggiorna un record da UI o import, se le impostazioni di sistema hanno la detection abilitata “when a record is created or updated”, appare l’avviso di potenziale duplicato prima del commit. È interattiva e blocca l’inserimento in tempo reale.
  • Bulk (Duplicate Detection Job): un job asincrono, schedulabile e ricorrente, che analizza un intero set di record esistenti e produce un report dei duplicati da bonificare. Utile per data cleansing periodico o dopo migrazioni massive.

Nota d’esame: la detection va abilitata a livello di System Settings e la singola regola va pubblicata. Disabilitare l’impostazione globale spegne tutti gli avvisi sincroni, indipendentemente dalle regole.

Multi-currency: base, transaction ed exchange rate

Dataverse supporta scenari multivaluta tramite tre concetti.

  • Base currency: la valuta di riferimento dell’ambiente, scelta alla creazione dell’organization. Ogni campo money mantiene automaticamente una controparte “(Base)” convertita in questa valuta, usata per rollup e reporting aggregato consistente.
  • Transaction currency: la valuta del singolo record (campo transactioncurrencyid). Determina in quale valuta l’utente inserisce gli importi.
  • Exchange rate: il tasso di cambio associato a ciascuna transaction currency rispetto alla base currency.

Come vengono ricalcolati i campi money

Per ogni attributo money esistono due valori: quello nella transaction currency e quello (Base). Il valore base = valore transazione ÷ (o ×, secondo la convenzione) exchange rate registrato al momento del calcolo. Punti critici:

  • l’exchange rate è statico: resta fisso finché un utente/processo non lo aggiorna manualmente. Non esiste un feed automatico di mercato nativo;
  • aggiornare l’exchange rate non ricalcola retroattivamente i record già salvati: i valori base storici restano “congelati” al tasso in vigore quando furono scritti (comportamento voluto per fedeltà contabile);
  • cambiare la transaction currency di un record esistente ne forza il ricalcolo dei campi base.

Configurazioni di base correlate

In fase di setup si definiscono anche decimal precision delle currency, formati regionali e le regole con cui i calculated/rollup field aggregano i valori base. Progettare queste impostazioni prima di caricare dati riduce rilavorazioni.

Trappole tipiche d’esame

  • Scenario: dopo la migrazione servono report aggregati in EUR ma l’ambiente è stato creato con base currency USD → la base currency non è modificabile dopo la creazione; l’unica strada è un nuovo ambiente. Non esiste un pulsante “cambia base currency”.
  • Scenario: il tasso di mercato è cambiato ma le opportunity vecchie mostrano ancora importi base “sbagliati” → comportamento corretto: l’exchange rate è statico e non ricalcola i record storici; solo i nuovi record o quelli modificati usano il tasso aggiornato.
  • Scenario: hai creato una duplicate detection rule ma nessun avviso appare al salvataggio → probabilmente la regola non è stata pubblicata, oppure la detection è disattivata in System Settings (“when a record is created or updated”).
  • Scenario: troppi falsi positivi bloccano gli utenti → progetta regole più selettive: preferisci Exact Match su campi discriminanti (email, VAT) invece di Same First Characters su Name; combina più criteri per restringere il match ed evitare corrispondenze troppo larghe.
  • Scenario: serve bonificare duplicati già presenti in massa senza infastidire gli utenti in inserimento → usa un bulk Duplicate Detection Job schedulato, non la detection sincrona (che agisce solo sul singolo save interattivo).