Business rule: lo stesso designer, due luoghi di esecuzione

Una business rule è logica dichiarativa definita su una tabella Dataverse: una o più condition, e le action che scattano sul ramo vero o su quello falso. Il punto che decide tutto il resto è lo scope. La pagina “Create a business rule in Microsoft Dataverse” lo mette in tabella: Entity significa form delle app model-driven e server, All Forms solo i form delle app model-driven, un form specifico solo quel form. La stessa pagina aggiunge un avviso che conviene imparare a memoria: se stai costruendo una canvas app devi usare la tabella come scope.

Da qui discende la distinzione più insidiosa. Le action Set Field Value, Set Default Value e Show Error Message valgono su tutti gli scope. Lock/Unlock, Set Visibility, Set Business Required e Recommendation sono marcate “Model-driven app”, e la doc dice testualmente che “Actions that only apply to model-driven apps are ignored when the rule is run server-side”. Nascondere o bloccare una colonna non è quindi una misura di sicurezza: è un comportamento di presentazione che sparisce quando la riga arriva al server per un’altra strada. Una business recommendation — la lampadina accanto all’etichetta della colonna — vive solo nelle app model-driven, e non può essere creata sulle table based view pages.

Anche i tipi di colonna pongono un limite. La doc esclude Choices (multi-select), File e Language; la pagina sui form model-driven aggiunge che non sono supportate le colonne unique identifier e le colonne rollup. Esiste infine una soglia di piattaforma: oltre 150 business rule su una singola tabella la doc segnala degrado di performance, e il conteggio include sia la parte client sia quella generata server-side come plug-in sincroni.

Business process flow: stage, step e un numero su cui la doc non concorda

Un business process flow non è automazione: è un’esperienza guidata. Definisci stage e step che compaiono in un controllo in cima al form. Ogni step rappresenta una colonna in cui inserire un dato, e marcandolo Required ottieni lo “stage-gating”, cioè l’impossibilità di avanzare con Next Stage finché il valore manca. Attenzione a un dettaglio che la doc segnala apposta: uno step obbligatorio legato a una colonna Two Option (Yes/No) è considerato vuoto se il valore è No, comportamento diverso da quello dei campi business required sul form.

I limiti dichiarati sono netti: fino a 10 business process flow attivi per tabella, fino a 30 stage per processo, fino a 30 step per stage, e un processo può attraversare al massimo cinque tabelle. Il branching si costruisce con il componente Condition e logica If-Else; la regola di branching deve basarsi sugli step dello stage che la precede, e puoi combinare più condizioni con AND oppure con OR, ma non con entrambi nella stessa regola.

Qui però la documentazione si contraddice. La pagina “Enhance business process flows with branching” scrive che ogni branch non può superare i cinque livelli di profondità; la pagina “Create a business process flow”, nel suo elenco di considerazioni sul branching, scrive dieci. Non memorizzare un numero secco: sappi che un limite di profondità esiste, che si applica al singolo branch e non al processo, e se lo citi nomina la pagina da cui lo prendi.

Calculated, rollup e formula: tre colonne che si somigliano e non si sostituiscono

Una colonna calculated calcola sulla riga corrente e sulle sue righe parent: la doc dice che usa “the columns from the current table or related parent tables”, con funzioni in maiuscolo tipo ADDDAYS, DIFFINDAYS, CONCAT, TRIMLEFT. Non aggrega nulla, può attraversare al massimo due tabelle e la catena di colonne calculated concatenate arriva a cinque.

Una colonna rollup aggrega su righe correlate con SUM, COUNT, MIN, MAX, AVG. Due vincoli che l’esame ama: il calcolo non è immediato, perché “the rollups are calculated by scheduled system jobs that run asynchronously in the background” (i job Mass Calculate Rollup Field e Calculate Rollup Field), e la relazione deve essere 1:N — la doc afferma esplicitamente che un rollup non si può fare su relazioni N:N. Sul form resta il pulsante Recalculate per il ricalcolo online, limitato a 50.000 righe correlate e a una profondità di gerarchia di 10.

Una colonna formula usa Power Fx e produce il valore in lettura, sulla riga. Profondità massima della catena 10, espressione fino a 1.000 caratteri, currency non supportata.

La confusione tipica che l’esame trasforma in domanda è il trattamento dei valori nulli, e la doc lo mette nero su bianco nella pagina delle formula column: se una colonna numerica è null viene considerata 0 nell’operazione intermedia, mentre la colonna calculated propaga il null.

a + b + c   con a = null, b = 2, c = 3
formula column   -> 0 + 2 + 3 = 5
calculated column -> null + 2 + 3 = null

Nota anche uno stato ambiguo: l’articolo “Work with Dataverse formula columns” non porta banner di preview, ma altre pagine — per esempio “Column data types in Microsoft Dataverse” — linkano la stessa funzionalità come “Work with formula columns (preview)”. Se ti serve dichiarare lo stato, dì da quale pagina lo stai leggendo.

Il criterio di scelta

La pagina “Apply business logic in Microsoft Dataverse” elenca le strade disponibili: business rule, processi Dataverse (Real-time workflows e Actions) e i flow di Power Automate, fra cui business process flow e cloud flow. Il criterio pratico che ne discende: usa una business rule per validazioni e default sul dato, e ricorda che le action di sola presentazione non ti proteggono lato server; usa un business process flow quando il problema è guidare le persone attraverso stage, non calcolare; usa un cloud flow quando devi uscire da Dataverse, chiamare un connettore o gestire attese e ramificazioni complesse; usa Power Fx in una formula column quando il valore deve semplicemente derivare dagli altri, senza processo e senza job.