App designer e site map: l’involucro dell’esperienza

La Sales Hub è una model-driven app costruita su Dataverse. La sua struttura si governa dall’app designer moderno, dove decidi quali tabelle, form, view, dashboard e chart includere nell’app. La navigazione è definita dalla site map, organizzata in Area → Group → Subarea: ogni subarea punta a una tabella, a un dashboard o a un URL. Aggiungere una tabella all’app non la rende automaticamente raggiungibile: serve un nodo nella site map (o una relazione che la esponga).

Scelta architetturale chiave: personalizza sempre dentro una unmanaged solution dedicata (con un publisher e prefisso custom), non “al volo” dall’app. Le modifiche fatte fuori da una solution finiscono nella Default solution, difficili da trasportare. Il pattern ALM corretto è sviluppare in una solution unmanaged, esportare managed e importare negli ambienti a valle.

Tipi di form

Dataverse offre quattro tipi principali:

  • Main form: la scheda completa del record (es. Account, Opportunity), con tab, sezioni, sotto-griglie e business process flow.
  • Quick Create form: form ridotto per creare rapidamente un record dal “+” globale o da una lookup; solo i campi essenziali (va abilitato sulla tabella).
  • Quick View form: sola lettura, embedded in un main form per mostrare campi di un record correlato (es. i dettagli dell’Account dentro l’Opportunity). Si aggiorna cambiando il parent nella lookup.
  • Card form: layout compatto usato nelle editable/read-only grid e nell’app mobile.

Il form order e le security role assegnate al form (role-based forms) determinano quale main form vede l’utente.

View

Le view definiscono colonne, ordinamento e filtri (FetchXML) di una lista. Tipi chiave:

  • Public view: condivise, selezionabili dal view selector.
  • System view speciali: Quick Find (ricerca), Lookup view (risultati di una lookup), Associated view (griglia di record correlati).
  • Personal view: create dall’utente via Advanced Find/griglia, condivisibili.

Business rules e lo scope

Le business rules applicano logica dichiarativa no-code su una tabella: condizioni + azioni (set field value, set default value, set business required, show/hide, lock/unlock, show error message, recommendation).

Il concetto cruciale è lo scope:

  • Specific form oppure All Forms: la regola gira solo client-side, quando l’utente apre quel form (o tutti i main form).
  • Entity (Table): la regola gira sia client-side sia server-side. Lato server valgono solo le azioni “dati” (set value, business required, validation/error message); le azioni puramente UI (show/hide, lock/unlock, recommendation) vengono ignorate dal server.

Business rule vs JavaScript / Power Fx

  • Business rule: rapida e manutenibile, ma limitata a una singola tabella, senza chiamate asincrone né logica cross-table complessa.
  • JavaScript (Client API): eventi OnLoad/OnChange/OnSave, chiamate Web API, logica avanzata; richiede pro-dev.
  • Power Fx: low-code per formula columns e modern commanding (bottoni della command bar).

Regola pratica: per validazioni server-side garantite → business rule scope Entity; per UI dinamica ricca → JavaScript; per calcoli o comandi low-code → Power Fx.

Trappole tipiche d’esame

  • La validazione deve bloccare anche import bulk e chiamate API, non solo il form → business rule con scope Entity (gira server-side); una regola scoped al singolo form viene bypassata da import/SDK.
  • Regola con scope Entity che “non nasconde” il campo durante un import → corretto: show/hide e lock/unlock sono azioni UI, ignorate server-side; solo set value e validation valgono ovunque.
  • Mostrare i dettagli in sola lettura di un record correlato dentro un altro form → Quick View form, non una sotto-griglia né un main form.
  • Form snello per la creazione rapida da una lookup → Quick Create form (ricordati di abilitarlo sulla tabella).
  • Le modifiche al form vanno portate in un altro ambiente → lavora in una unmanaged solution ed esporta managed; non affidarti alla Default solution.