Im Portal Builder dreht sich alles um zwei Konzepte, die zusammen die Architektur deines Portals bestimmen: Seiten und das Schema, das auf jeder Seite verfügbar ist. Wenn du verstehst, wie diese beiden Bausteine zusammenarbeiten — und wie der Spezialfall Detailseite funktioniert — kannst du das Portal so bauen, dass jede Seite die richtigen Daten anzeigt und Klicks dorthin führen, wo der Nutzer sie braucht. Diese Anleitung erklärt das End-to-End: von der Seitenstruktur über Slugs und URLs bis zur Verlinkung zwischen Listen und Detailseiten.

Seiten im Portal — die zwei Welten

Jedes Portal besteht aus zwei Arten von Seiten:

• Öffentliche Seiten — erreichbar ohne Login. Anmelden, Registrieren, Passwort vergessen, Wartungsseite.
• Geschützte Seiten — nur nach Login erreichbar. Übersicht, Anträge, Verträge, Mein Konto, etc.

Innerhalb der geschützten Welt unterscheidet das System zusätzlich zwischen drei Seiten-Rollen:

Die Seiten-Einstellungen im Überblick

Wenn du im Seitenbaum links eine Seite auswählst, ohne einen Block anzuklicken, erscheint rechts das Panel Seite Einstellungen. Dort steckt die gesamte Konfiguration der Seite.

Slugs und URLs — wie Seiten adressiert werden

Jede Seite hat einen Slug — den Teil der URL nach dem Domainnamen. Aus dem Slug und der Portal-Domain baut das System die finale URL der Seite.

So setzt sich eine URL zusammen

Bei System-Seiten aus dem Best-Practice-Portal (z. B. Anmelden, Registrieren, Passwort vergessen) ist der Slug fest vorgegeben und nicht editierbar — das System erwartet bestimmte Slugs für E-Mail-Links und automatisierte Flows. Bei selbst angelegten Seiten und Detailseiten kannst du den Slug frei wählen.

Das Schema einer Seite — verfügbare Daten

Oben in den Seiten-Einstellungen siehst du den Bereich Verfügbare Daten auf dieser Seite. Bei einer leeren neuen Seite stehen dort typischerweise zwei Einträge: Kontakt und Portal Zugang. Diese Liste ist das Schema der Seite — und sie ist mehr als nur eine Information, sie steuert das tatsächliche Verhalten.

Was ist das Schema?

Das Schema definiert, welche Entitätstypen auf dieser Seite verfügbar sind. „Verfügbar" heißt: Du kannst auf dieser Seite Variablen aus diesen Entitäten in Templates verwenden — etwa {{contact.first_name}}, {{opportunity.status}} oder {{ticket.ticket_number}}.

Warum stehen dort immer Kontakt und Portal Zugang?

Jede geschützte Seite hat automatisch Kontakt und Portal Zugang als verfügbare Daten — ganz ohne Konfiguration. Der Grund: Wer eingeloggt ist, ist immer ein Kontakt mit einem Portal-Zugang. Diese beiden Entitäten sind also auf jeder geschützten Seite garantiert vorhanden.

Damit funktioniert das hier ohne weiteres Setup:

• {{contact.first_name}} — Vorname des eingeloggten Kontakts
• {{contact.company_name}} — Firmenname
• {{portal_user.email}} — E-Mail des Portal-Zugangs

Wann kommen weitere Entitäten ins Schema?

Es gibt zwei Wege, wie zusätzliche Entitäten in der Liste landen:

1. Über eine Detailseite — wenn du eine Seite zur Detailseite machst, wählst du ein Detail-Schema (z. B. „Opportunity"). Damit ist diese Entität automatisch im Schema und ihre Variablen sind in Templates nutzbar.
2. Über das Schema einer Listenseite — auf einer Listenseite (z. B. Anfragen) ist die gelistete Entität (Opportunity) Teil des Schemas, damit Filter, Such-Felder und Templates darauf zugreifen können.

Praktische Bedeutung — was kannst du damit machen?

Die Verfügbarkeits-Liste ist nicht dekorativ, sie entscheidet konkret darüber, was funktioniert:

• Variablen-Picker zeigt nur Felder der verfügbaren Entitäten
• Templates rendern leer oder fehlerhaft, wenn du auf eine Entität referenzierst, die nicht im Schema ist
• Attribute-Gruppen binden sich nur an verfügbare Entitäten
• Filter und Bedingungen in Blöcken können nur auf verfügbare Entitäten zugreifen

Detailseiten — wenn eine Seite eine Entität darstellt

Eine Detailseite zeigt die Detailansicht einer einzelnen Entität — typischerweise nach einem Klick auf einen Eintrag in einer Liste. Beispiel: Auf der Seite Anfragen klickt der Installateur auf einen Antrag, und das Portal öffnet die Detailseite mit allen Informationen zu genau diesem Antrag.

Eine Seite zur Detailseite machen

1. Wähle die Seite im Seitenbaum aus
2. Aktiviere im Einstellungs-Panel den Toggle Als Detailseite verwenden
3. Es erscheint das Feld Schema — wähle den Entitätstyp, den diese Detailseite darstellt (z. B. Opportunity, Order, Ticket)
4. Setze einen Slug, der sprechend ist (z. B. antrag für Opportunity-Detailseiten)
5. Speichere

Sobald der Toggle aktiv ist, ändert sich das Verhalten der Seite:

• Verschwindet aus der Hauptnavigation — der Eintrag wird im Menü nicht mehr angezeigt
• Ist nur über Listen-Klicks erreichbar — über die Seite auswählen-Konfiguration einer Entitätsliste
• Bekommt die gewählte Entität ins Schema — Variablen wie {{opportunity.opportunity_number}} sind nutzbar
• Slug wird zum URL-Teil — z. B. /antrag bei Klick auf einen einzelnen Antrag

Verlinkung Entitätsliste → Detailseite

Listen und Detailseiten gehören zusammen wie Vorder- und Rückseite einer Münze: Die Liste zeigt eine Übersicht, die Detailseite zeigt einen einzelnen Eintrag im Detail. Der Klick auf einen Listen-Eintrag muss zur richtigen Detailseite führen — und das konfigurierst du explizit.

„Seite auswählen" in der Entitätsliste

In jeder Konfiguration einer Entitätsliste findest du das Feld Seite auswählen. Hier wählst du die Detailseite aus, auf die der Klick auf einen Eintrag führen soll.

Schema-Match — die Detailseite muss zum Entitätstyp passen

Damit die Verlinkung Sinn ergibt, muss die ausgewählte Detailseite das passende Schema haben. Listest du Opportunities, sollte die Ziel-Detailseite eine Detailseite mit Schema Opportunity sein. Das System filtert das Dropdown Seite auswählen entsprechend — du siehst dort vorrangig Detailseiten, die zum Entitätstyp deiner Liste passen.

Registerkarten statt Sub-Detailseiten

Auf den ersten Blick wirkt es so, als hätten manche Detailseiten weitere Sub-Detailseiten — etwa eine Vertrags-Detailseite mit Bereichen Übersicht, Zahlungen, Produkte, Dokumente. Tatsächlich sind das aber keine eigenen Seiten, sondern Tabs innerhalb einer einzigen Detailseite.

Praxis-Beispiel: Klickpfad von der Liste zur Detailseite

Lass uns das End-to-End am Beispiel Anfragen durchspielen — genau so, wie es im Best-Practice-Portal eingerichtet ist.

Setup

1. Du legst eine Seite Anfragen an. Sie ist eine Navigationsseite, also Als Detailseite verwenden = aus. Slug: anfragen.
2. Auf dieser Seite platzierst du eine Entitätsliste mit Entität Opportunity. Damit erscheint Opportunity automatisch im Schema der Anfragen-Seite.
3. Du legst eine zweite Seite Antragsdetails an. Aktivierst Als Detailseite verwenden = an, wählst Schema Opportunity. Slug: antrag.
4. Auf der Detailseite platzierst du einen Tabs-Block mit den Tabs Übersicht, Fortschritt, Adresse, Dokumente, Details.
5. In der Entitätsliste auf der Anfragen-Seite gehst du in die Konfiguration und setzt Seite auswählen auf Antragsdetails.

Laufzeit — was passiert beim Klick?

1. Der Installateur ist eingeloggt und navigiert zu /anfragen
2. Die Anfragen-Seite rendert die Entitätsliste mit allen für ihn freigegebenen Opportunities
3. Er klickt auf einen Eintrag
4. Das Portal navigiert zur Detailseite und lädt diese Opportunity in den Kontext
5. Auf der Detailseite sind nun Kontakt, Portal Zugang und Opportunity verfügbar
6. Templates wie {{opportunity.opportunity_number}} werden mit echten Werten gerendert
7. Der Nutzer wechselt zwischen den Tabs — die URL bleibt dabei dieselbe Detailseiten-URL