Business rules e business process flow

Due strumenti dichiarativi, due scopi diversi

In una model-driven app costruita su Dataverse, gran parte della logica di validazione e del flusso di lavoro guidato si realizza senza scrivere codice. Le due leve principali sono le business rule e i business process flow (BPF): il consulente funzionale deve saperle distinguere e scegliere quella giusta per lo scenario.

Business rule

Una business rule è logica dichiarativa applicata a una table e alle sue form, costruita con il pattern Condition → Action. Le azioni disponibili sono:

• Set field value — imposta il valore di un campo.
• Set default value — valore iniziale su un nuovo record.
• Set field requirement — rende un campo business required o opzionale.
• Show / hide fields — mostra o nasconde un campo.
• Enable / disable (lock/unlock) — rende un campo editabile o in sola lettura.
• Validate data — mostra un error message e blocca il salvataggio.
• Business recommendation — suggerimento non vincolante che l’utente può applicare.

La business rule agisce su una sola table e non attraversa relazioni: per leggere/scrivere su altre table serve un Power Automate cloud flow o un plug-in.

Lo scope della business rule

Lo scope determina dove e quando la regola viene eseguita:

• Specific form (es. “Information”) — vale solo su quella form, lato client.
• All Forms — tutte le form della table, sempre lato client.
• Entity (Table) — vale su tutte le form e anche server-side.

Con scope Entity, le azioni che rappresentano dati (set value, set default, set business required, validation/error) vengono valutate anche quando il record è creato o aggiornato via API, importazione o flow — non solo dalla UI. Le azioni puramente UI (show/hide, lock/unlock, business recommendation) restano invece solo lato client anche con scope Entity, perché non hanno significato senza un’interfaccia.

Business process flow (BPF)

Un business process flow guida l’utente lungo un processo strutturato in stage (fasi) e step (campi da compilare). Caratteristiche chiave:

• È cross-table: un singolo BPF può attraversare fino a 5 table, spostando l’utente tra record collegati (es. Lead → Opportunity → Quote).
• Supporta il branching condizionale: la fase successiva cambia in base ai dati inseriti.
• Ogni BPF è memorizzato come una table dedicata, quindi si possono avere più istanze attive e riportarle nei report.
• Uno step può essere reso obbligatorio per avanzare di stage, garantendo la completezza dei dati.

Il BPF non esegue automazioni in background: se serve reagire a un evento (inviare mail, aggiornare altri record, chiamare un servizio) si usa un Power Automate flow, eventualmente innescato dai cambi di stage del BPF stesso.

BPF o flow? Criterio di scelta

• Scegli il BPF quando l’obiettivo è guidare visivamente una persona attraverso fasi con un ordine e criteri di uscita, mostrando l’avanzamento nella model-driven app.
• Scegli il cloud flow quando serve automazione senza interazione, logica complessa, integrazioni o operazioni multi-record.
• Scegli la business rule quando la logica riguarda una sola form/table ed è semplice e immediata (default, obbligatorietà condizionale, validazione).

I due strumenti sono complementari: BPF per l’esperienza guidata, business rule per la coerenza dei singoli campi, flow per l’automazione.

Trappole tipiche d’esame

• Scenario: una validazione deve valere anche per record importati via data import o creati da un’integrazione, non solo dalla UI → risposta: business rule con scope Entity (le azioni sui dati girano server-side), non scope su form specifico.
• Scenario: una business rule con scope Entity deve nascondere un campo in tutti i canali → trappola: show/hide è UI-only, gira solo lato client anche con scope Entity; server-side non ha effetto.
• Scenario: serve logica che legge dati da un’altra table → risposta: non una business rule (single-table), ma un Power Automate flow o un BPF cross-table.
• Scenario: guidare i venditori attraverso fasi Lead → Opportunity con criteri per avanzare → risposta: business process flow (multi-table, stage/step), non un cloud flow.
• Scenario: al cambio di stage del BPF deve partire un’email automatica → risposta: cloud flow innescato dall’aggiornamento del record BPF; il BPF da solo non automatizza azioni.