Power Pages Nutzungsbedingungen einrichten - und der stille Fehler, den fast alle treffen

Das eine Site Setting, das den Dialog steuert

Der wiederkehrende Zustimmungs-Dialog haengt an einem einzigen dokumentierten Setting plus einem Datum:

Beides ist woertlich so in der Microsoft-Doku belegt. Ein Hinweis zur Ehrlichkeit: In aelteren Blogs (und teils in aelteren Portalen) taucht zusaetzlich Authentication/Registration/TermsAndConditionsEnabled auf, ein separates Registrierungs-Setting. In der aktuellen Power-Pages-Doku ist dieses Setting nicht mehr beschrieben. Verlassen Sie sich fuer das wiederkehrende Feature auf TermsAgreementEnabled + TermsPublicationDate.

Das Content Snippet, das jeder vergisst

Hier sitzt die Falle. Der Dialog braucht Inhalt, und der kommt aus Content Snippets:

TermsAndConditionsCopy ist laut Doku standardmaessig leer und muss vom Administrator gefuellt werden. Nur: Bleibt es leer, erscheint der Dialog gar nicht - obwohl alle Site Settings korrekt stehen. Kein Fehler, kein Log, nichts. Microsoft dokumentiert zwar, dass das Snippet gefuellt werden muss, warnt aber an keiner Stelle davor, dass ein leeres Snippet das gesamte Feature still aushebelt.

Genau das habe ich im Demo-Portal nachgestellt: Settings auf true, Datum in der Vergangenheit, Zustimmungsdatum des Kontakts leer - und die Seite laedt ohne jeden Dialog. Erst nach dem Anlegen des Copy-Snippets erscheint er:

Warum der Dialog bei Ihrem Testnutzer trotzdem fehlt

Eine Beobachtung aus dem Hands-on, die viel Debugging-Zeit spart: Der Dialog ist kein Overlay, das bei jedem Seitenaufruf prueft. Er wird als eigene Seite (/Account/Login/TermsAndConditions) waehrend des Sign-in-Flows ausgeliefert, bevor die Anmeldung abgeschlossen ist. Die Doku formuliert es als "the next time they sign in".

Konsequenz: Wenn Sie mit einem Nutzer testen, der bereits angemeldet ist (aus einer Session vor dem Aktivieren), passiert nichts, egal wie oft Sie neu laden. Sie muessen sich ab- und wieder anmelden, damit die Pruefung ueberhaupt laeuft. Das ist der zweite stille Stolperstein neben dem leeren Snippet.

Die Mechanik dahinter

Beim Sign-in vergleicht Power Pages den Stichtag mit dem Zustimmungsdatum des Kontakts. Das Feld am Kontakt heisst msdyn_portaltermsagreementdate (nicht adx_termsagreeddate, wie in aelteren Quellen). Als Mechanik, hergeleitet aus dem dokumentierten Verhalten:

• Zustimmungsdatum leer oder aelter als TermsPublicationDate → Dialog erscheint
• Zustimmungsdatum juenger oder gleich → kein Dialog

Beim Bestaetigen schreibt Power Pages den aktuellen Zeitstempel in dieses Feld.

Bedingungen aktualisieren und erneut abfragen

1. Den Text in Account/Signin/TermsAndConditionsCopy aktualisieren
2. TermsPublicationDate auf das heutige Datum setzen (in der Vergangenheit, nicht in der Zukunft)
3. Cache invalidieren
4. Alle Nutzer, deren msdyn_portaltermsagreementdate aelter ist, werden beim naechsten Sign-in erneut gefragt

Externe Identity Provider

Ein ehrlicher Hinweis: Zum Verhalten dieses klassischen Terms-Features mit externen Identity Providern (Entra External ID, Azure AD B2C) sagt die aktuelle Doku nichts. Wenn der Login-Flow ausserhalb von Power Pages laeuft und die Portal-/signin-Strecke umgeht, ist offen, ob die Pruefung greift. Das gehoert getestet, nicht angenommen. Code-First-Sites haben ausserdem ein separates, eigenes Terms-Feature - nicht mit diesem verwechseln.

Checkliste vor dem Go-Live

Stimmt einer dieser Punkte nicht, bleibt der Dialog aus - lautlos.

Weiterfuehrende Artikel

Quellen

• Microsoft Learn: Implement privacy protections – Agreeing to terms and conditions (Site Settings TermsAgreementEnabled/TermsPublicationDate, die vier Content Snippets, "Copy is empty by default")
• Microsoft Learn: Contact table reference (Feld msdyn_portaltermsagreementdate, Portal Terms Agreement Date)
• Hands-on-Nachstellung im Power-Portals-Demo-Portal (Enhanced Data Model), inkl. Silent-Failure bei leerem Copy-Snippet und Sign-in-Trigger