Business rules: validazione e default senza codice
Le business rules applicano logica dichiarativa (no-code) direttamente sulla tabella Dataverse, senza scrivere JavaScript. Sono la prima scelta quando la logica è semplice e riguarda i campi di una singola tabella: impostare default, mostrare o nascondere colonne, rendere obbligatorio un campo in base a un’altra scelta, oppure bloccare l’input.
Scope: dove viene eseguita la regola
Lo scope è la decisione architetturale più importante perché determina dove la regola gira:
- Entity (tabella): valutata lato server, si applica a tutte le operazioni di scrittura — form, importazioni, chiamate Web API, Power Automate. È l’unico scope che garantisce coerenza indipendentemente dal punto di ingresso.
- All Forms: lato client, su tutti i main form della tabella.
- Specific form: lato client, limitata al singolo form selezionato.
Con scope client la regola reagisce in tempo reale mentre l’utente digita (eventi OnLoad/OnChange). Con scope Entity la valutazione avviene al salvataggio, non durante la compilazione.
Condizioni e azioni
Una business rule è composta da un condition (operatori di confronto, raggruppamenti AND/OR, confronto campo-valore o campo-campo) e da una o più azioni:
- Set Field Value (valore fisso, altro campo o formula; utile anche per i default)
- Set Business Required (livello di obbligatorietà)
- Set Visibility (mostra/nascondi)
- Lock/Unlock Field (abilita/disabilita)
- Show Error Message (blocca il salvataggio)
- Recommendation (suggerimento non vincolante all’utente)
Business process flow: guidare l’utente nel processo
Un business process flow (BPF) guida l’utente attraverso un processo ripetibile, mostrando una barra orizzontale in cima al form. Ogni BPF è supportato da una propria tabella Dataverse e può attraversare fino a 5 tabelle collegate.
Stage, step e branching condizionale
- Gli stage rappresentano le fasi del processo (es. Lead → Qualify → Develop → Close).
- Gli step sono i campi da compilare in ciascuno stage; uno step marcato required blocca l’avanzamento finché non è valorizzato (stage gating).
- Il branching condizionale instrada l’utente verso stage diversi in base al valore di un campo (es. se Budget > 50k → stage “Approvazione manager”).
Su una stessa tabella possono coesistere più BPF ordinati; le security role determinano quale processo vede ciascun utente e l’ordine stabilisce quello di default. Le transizioni di stage possono innescare Power Automate (trigger Dataverse sulla tabella del BPF), utile per automazioni allo scatto di fase.
Business rules vs client scripting vs plug-in
Per validazione e default esistono tre approcci; la scelta dipende dalla complessità e da dove deve valere la logica:
- Business rules — no-code, ideali per logica semplice su una singola tabella. Con scope Entity valgono anche server-side, ma con azioni limitate.
- Client scripting (JavaScript) — logica client complessa: gestione eventi OnLoad/OnChange/OnSave, chiamate alla Web API, manipolazione dei controlli. Non protegge le scritture che non passano dal form.
- Plug-in — codice server-side nell’event pipeline (pre/post operation). Da usare quando la validazione deve essere inviolabile a prescindere dal canale (UI, API, import massivo), o quando serve logica cross-table, transazionale o accesso ad altri record.
Regola pratica: se la validazione deve valere ovunque e la logica è banale → business rule scope Entity; se è complessa o non aggirabile → plug-in.
Trappole tipiche d’esame
- Regola con scope Entity che non aggiorna il form in tempo reale → è il comportamento atteso: gira server-side al salvataggio, non riflette le modifiche mentre l’utente digita. Per feedback immediato serve scope All Forms/Specific form o client scripting.
- Scope Entity + azione Set Visibility o Lock/Unlock → non applicate: server-side valgono solo Set Field Value, Set Business Required e Show Error Message; visibilità e lock sono azioni solo-client.
- Validazione che deve reggere anche su import o Web API → non basta una business rule client né JavaScript: usa scope Entity o, per logica complessa/non aggirabile, un plug-in.
- Serve instradare il processo su fasi diverse in base a un dato → è il branching condizionale del BPF, non un secondo BPF né una business rule.
- Condizione su un tipo di campo non supportato → le business rules non coprono tutti i tipi/operatori; per confronti o logica non esprimibili ripiega su JavaScript o plug-in.