Cos’è Power Pages e quando lo usi
Power Pages è la soluzione low-code per costruire siti web esterni (rivolti a clienti, partner o cittadini) che leggono e scrivono direttamente su Microsoft Dataverse. A differenza di una Canvas o Model-driven app, l’utente finale non ha bisogno di una licenza Power Apps: accede via browser, in forma anonima (sito pubblico) oppure autenticata.
Come Functional Consultant devi saper scegliere la modalità corretta:
- Sito pubblico/anonimo: contenuti aperti a chiunque (cataloghi, FAQ, moduli di contatto). L’identità è gestita dal ruolo speciale Anonymous Users.
- Sito autenticato: l’utente esegue il sign-in tramite un identity provider (tipicamente Microsoft Entra External ID, Azure AD B2C in via di deprecazione, o provider OpenID Connect/local). Al sign-in, l’utente viene mappato a un record Contact in Dataverse.
Il punto chiave d’esame è che la pagina esiste, ma i dati Dataverse restano invisibili finché la sicurezza non li autorizza esplicitamente. La sicurezza si costruisce con due elementi combinati: web role e table permission.
Web role
Un web role è il contenitore di sicurezza assegnato ai contatti autenticati (o, tramite ruoli di default, agli anonimi). Ogni sito ha due web role automatici:
- Authenticated Users: assegnato di default a ogni utente che effettua il login.
- Anonymous Users: applicato ai visitatori non autenticati. Non essendoci un Contact, questo ruolo può usare solo permessi con accesso Global.
Puoi creare web role aggiuntivi (es. “Fornitore”, “Cliente Premium”) e assegnarli ai contatti. Un utente può avere più web role contemporaneamente: i privilegi risultanti sono l’unione di tutti i permessi collegati a quei ruoli.
Table permission e access type
Una table permission definisce quali record di una tabella Dataverse un web role può vedere e cosa può farci. Ogni permesso specifica un access type che determina l’ambito dei record visibili:
- Global: tutti i record della tabella, senza relazione. Ambito più ampio, da usare con cautela (unico tipo valido per gli anonimi).
- Contact: solo i record collegati al contatto loggato tramite una relazione (1:N o N:N) che devi indicare esplicitamente.
- Account: i record collegati all’account padre del contatto (scenario B2B: un utente vede i dati della propria azienda).
- Self: il solo record Contact dell’utente (per far modificare il proprio profilo).
- Parent: eredità gerarchica tramite una parent table permission più una relazione, per propagare l’accesso da una tabella padre alle sue figlie.
A ciascun access type associ i privilegi: Read, Write, Create, Delete, più Append e Append To (necessari quando colleghi record correlati, es. aggiungere una riga figlia a un record padre).
Come web role + table permission determinano la visibilità
La regola è: un table permission non produce alcun effetto finché non è associato ad almeno un web role. La logica di runtime è:
- L’utente autenticato riceve i suoi web role.
- Il sito raccoglie tutte le table permission collegate a quei ruoli.
- I privilegi si sommano (union): se un permesso Global-Read e uno Contact-Write insistono sulla stessa tabella, l’utente legge tutto ma scrive solo i propri record.
Componenti come lists e forms (basic/advanced) rispettano sempre questo strato: anche con una query corretta, mostreranno record solo se il web role dell’utente ha la table permission adeguata. Nei siti Power Pages moderni le table permission sono attive per impostazione predefinita.
Trappole tipiche d’esame
- La lista è configurata e la view esiste, ma il portale non mostra nessun record → manca una table permission associata al web role dell’utente. La pagina/query non basta: senza permesso, zero righe.
- Utenti anonimi devono vedere un catalogo pubblico → crea una table permission con access type Global (Read) e collegala al ruolo Anonymous Users; gli access type Contact/Account/Self non funzionano senza un Contact loggato.
- Ogni cliente deve vedere solo i propri ticket → access type Contact con la relazione contatto→ticket, non Global.
- Un referente deve vedere gli ordini di tutta la sua azienda (B2B) → access type Account, che sfrutta l’account padre del contatto.
- L’utente può leggere il record padre ma non aggiungervi righe figlie → mancano i privilegi Append/Append To (e spesso una Parent table permission sulla tabella figlia).