Due tipi di relazione, tre voci nel designer
La pagina About table relationships di Dataverse è netta su un punto che l’esame ama: i tipi di table relationship sono due, one-to-many (1:N) e many-to-many (N:N). La voce many-to-one (N:1) esiste soltanto perché il designer raggruppa le relazioni per tabella — “A N:1 relationship is just a 1:N relationship viewed from the related table”, scrive la documentazione. Se in una domanda leggi “tre tipi di relazione”, stai guardando l’interfaccia, non il modello.
In una 1:N molte righe della related table (il child) puntano a una singola riga della primary table (il parent, che il portale chiama Current table) attraverso una lookup column. Il rapporto è talmente diretto che aggiungere una lookup column è creare una 1:N: puoi farlo dall’area Relationships della tabella con New relationship, ma anche creando una colonna di tipo Lookup dall’elenco Columns o dall’editor di form di una model-driven app. Nel pannello configuri Lookup column display name, Lookup column name, Lookup column requirement (Optional, Business Recommended, Business Required), Searchable e Relationship name.
Attenzione al verso, perché è un classico errore d’esame: con Many-to-one la lookup nasce sulla tabella da cui stai partendo, con One-to-many nasce sulla related table. Se ti serve la lookup sulla tabella corrente, la scelta giusta è Many-to-one.
La N:N è un’altra bestia. Non ha lookup column e non ha comportamenti da configurare: le associazioni vivono in una relationship table (detta anche intersect table) che non accetta colonne custom, non è mai visibile nell’interfaccia e viene distrutta — con tutti i legami — se cancelli la relazione. Non tutte le tabelle sono eleggibili: se non compare nell’elenco del designer, con quella tabella non puoi creare una N:N. Per una N:N verso se stessa servono i Custom label sotto Advanced options, altrimenti l’utente vede due elenchi con lo stesso nome.
Che cosa decide il comportamento della relazione
Solo le 1:N portano dei comportamenti. Le azioni configurabili sono Assign, Reparent, Share, Unshare, Delete, Merge e Rollup View, e a ciascuna assegni un behavior fra Cascade All, Cascade Active, Cascade User Owned, Cascade None, Remove Link e Restrict. Nel pannello della lookup trovi le combinazioni preconfezionate: Referential, Remove Link, Referential, Restrict Delete, Parental e Custom.
Una relazione parental propaga assegnazioni, condivisioni e cancellazioni ai figli. Da qui il limite che vale la pena ricordare: una tabella non può essere la related table di due relazioni che cascano, perché la piattaforma impedisce le situazioni multi-parent. Restrict Delete, invece, non propaga nulla ma impedisce di cancellare il parent finché esistono figli.
Prompt column: il valore AI che resta scritto sulla riga
La prima delle due funzionalità AI che vivono sul modello dati è la prompt column: un data type di nome Prompt che memorizza in modo persistente il risultato generativo dentro la riga. La crei con New > Column, scegli Prompt come Data type, deselezioni Allow form fill assistance e poi +Add new prompt. Gli input si aggiungono con +Add content scegliendo le colonne della tabella; formula column, file, image e altre prompt column non sono ammesse come input e il loro valore viene ignorato. Il tetto documentato è di cinque prompt column per tabella.
Il prompt si esegue alla creazione della riga o quando cambia una delle colonne che il prompt referenzia — e solo allora. Non esiste un backfill, e la documentazione è esplicita sul fatto che l’esecuzione on-demand non è supportata: modificare la definizione del prompt non ricalcola i valori già presenti finché non arriva un aggiornamento successivo su una colonna referenziata. Non aspettarti nemmeno una traccia di audit, perché le prompt column non sono auditate.
Per capire cosa è successo ci sono due colonne di sistema create automaticamente accanto a ogni prompt column:
(columnName)_PromptColumnStatus
(columnName)_PromptColumnDetailsI codici di stato distinguono NotStarted, InProgress, Completed, Failed e due esiti “completato ma non eseguito”: uno perché la riga non soddisfaceva le filter conditions, l’altro perché nessuna colonna di input era stata aggiornata. Puoi spegnere la generazione con la casella Allow prompt column execution, e servono le impostazioni d’ambiente Copilot e AI prompts attive.
Row summary: il riassunto che vive nell’interfaccia
Il row summary è l’altra faccia della medaglia. Si configura per tabella, sotto Customizations > Row summary: scrivi un prompt indicando le colonne da includere, provi con Test prompt e concludi con Apply to main forms. La configurazione vale per tutte le view e tutti i main form della tabella — non per un singolo form, ed è un dettaglio che le domande sanno sfruttare. Dipende dal setting d’ambiente AI insight cards, l’opzione resta disabilitata se la tabella non ha almeno una riga di dati, e su alcune tabelle standard come Case, Lead e Opportunity non è disponibile perché il riassunto arriva dalle app Dynamics 365. Chi usa l’app lo trova nella barra Insights in cima al main form o con l’azione inline Summary dalla view, con un pulsante Refresh per rigenerarlo.
La confusione da evitare è esattamente qui: la prompt column è un valore memorizzato sulla riga, quindi filtrabile in una view, leggibile da un flow e ricalcolato solo in scrittura; il row summary è testo generato al momento della lettura e mostrato nell’interfaccia, non una colonna. Se lo scenario chiede un dato riutilizzabile a valle, la risposta è la prompt column; se chiede di far orientare un utente che apre un record, è il row summary.