Warum diese Seiten anders sind

MultiDatePick speichert die gewählten Termine als Datensätze auf einem verknüpften Objekt, jeden mit Verweis auf einen übergeordneten Datensatz. Die Komponente muss nur wissen, welchen.

Auf einer Datensatzseite (z. B. einem Event-Datensatz) übergibt Salesforce der Komponente automatisch die Id des aktuellen Datensatzes (die recordId). Sie müssen nichts weiter konfigurieren.
Auf einer App-Seite, Startseite oder Experience Cloud-Site gibt es keinen „aktuellen Datensatz“. Salesforce übergibt nichts. Ohne übergeordneten Datensatz weiß die Komponente nicht, wohin sie speichern soll, und blendet die Schaltfläche Speichern bewusst aus, statt eine anzuzeigen, die beim Klick scheitert.

Die Lösung ist die Eigenschaft Static Parent Record Id. Fügen Sie die Id eines bestimmten übergeordneten Datensatzes ein, und die Komponente verhält sich genau so, als stünde sie auf der Seite dieses Datensatzes. Es ist eine Eigenschaft, die Sie im Builder setzen. Mit einer statischen Ressource (Static Resource) in Salesforce, einer eigenen Funktion für hochgeladene Dateien, hat sie nichts zu tun.

Sie finden Static Parent Record Id im Eigenschaftenbereich, nachdem Sie MultiDatePick im Lightning App Builder auf eine App-Seite oder Startseite oder im Experience Builder auf eine Seite gezogen haben.

Static Parent Record Id oder Flow: Was wann passt

Static Parent Record Id richtet die Komponente auf einen festen übergeordneten Datensatz aus, also sieht jeder Besucher denselben Datensatz. Für manche Fälle ist das perfekt, für andere falsch. Wenn der Datensatz je Benutzer oder Besuch wechseln soll, steuern Sie ihn stattdessen über einen Bildschirm-Flow (Screen Flow). Ziehen Sie die Komponente auf einen Flow-Bildschirm und binden Sie ihre Parent Record Id an eine Variable, die der Flow zur Laufzeit ermittelt.

Static Parent Record Id, wenn der Datensatz für alle derselbe ist

Eine öffentliche Buchungsseite: eine Seite für Gäste zum „Termin anfragen“, auf der jede Buchung am selben übergeordneten Datensatz hängt (ein Büro, ein Standort oder eine Ressource). Eine feste Id ist genau richtig.
Ein Kalender für die ganze Org: ein einzelner Datensatz „Betriebsschließungen“ oder eine gemeinsame Ressource, die alle buchen und die sich nie je Benutzer ändert.
Ein fester Dashboard-Anker auf einer App- oder Startseite, der immer auf denselben Hauptdatensatz zeigt.

Faustregel: Nehmen Sie Static Parent Record Id, wenn die Antwort auf „Wessen Datensatz ist das?“ lautet: „Für alle derselbe.“

Ein Flow, wenn der Datensatz zur Laufzeit gewählt wird

Datensätze pro Benutzer: Jede Person sieht nur ihre eigenen (zum Beispiel landet jeder Auftragnehmer in seinem eigenen Urlaubskalender). Der Flow macht ein Get Records, bei dem der Inhaber oder ein verknüpfter Kontakt = {!$User.Id} ist, speichert die Id und gibt sie an die Komponente weiter.
Per URL gesteuert: Eine Eingabevariable des Flows liest ?id=… aus dem Link, sodass eine Seite viele Datensätze bedient. Das funktioniert auch für Gäste, ohne Anmeldung.
Erst auswählen: Auf Bildschirm 1 sucht oder wählt der Benutzer (einen Mitarbeitenden, einen Raum, einen Kunden); Bildschirm 2 zeigt den Kalender dieses Datensatzes.

Gast-Sites: Auf einer öffentlichen Site ohne Anmeldung ist der „Benutzer“ ein einziger gemeinsamer Gast, eine Auflösung pro Benutzer ($User) greift also nicht. Teilen Sie entweder einen Datensatz über Static Parent Record Id, oder steuern Sie ihn über einen URL-Parameter in einem Flow. Echte Kalender pro Benutzer brauchen angemeldete Benutzer.

Einrichtung in einer Minute

Animierte Demo der Einrichtung per Config Name: im MultiDatePick-Einrichtungsassistenten einen Konfigurationsnamen kopieren, die Komponente Resource Booking im Lightning App Builder auf eine Seite ziehen, Config Name einfügen und Static Parent Record Id eingeben, und der Buchungskalender erscheint mit allen Einstellungen der Konfiguration — Kopieren Sie den Konfigurationsnamen im Einrichtungsassistenten, fügen Sie ihn zusammen mit der Id des übergeordneten Datensatzes ein, und der Kalender ist bereit. Alle anderen Einstellungen liefert die Konfiguration.

Wann die Schaltfläche Speichern erscheint

Alle vier, sonst bleibt Speichern ausgeblendet:

#	Eigenschaft (Bezeichnung im Builder)	Datensatzseite	App / Start / Experience
1	Übergeordneter Datensatz	Automatisch (`recordId`)	Static Parent Record Id
2	Verwandtes Objekt (Child Object API Name)	Erforderlich	Erforderlich
3	Datumsfeld (Date Field API Name)	Erforderlich	Erforderlich
4	Beziehungsfeld (Relationship Field API Name)	Erforderlich	Erforderlich

Setzen Sie Config Name auf eine Konfiguration aus dem Einrichtungsassistenten, und 2 bis 4 werden für Sie ausgefüllt.

Wo Sie sie platzieren

Seitentyp	Erstellen in	Live schalten	Wer Zugriff braucht
App-Seite	Lightning App Builder, Neu, App-Seite	Aktivieren und einer oder mehreren Apps hinzufügen (sie wird zur Registerkarte)	Berechtigungssatz MultiDatePick - User
Startseite	Lightning App Builder, Neu, Startseite	Als Org-Standard aktivieren oder pro App im App-Manager unter Seiten	Berechtigungssatz MultiDatePick - User
Experience Site	Experience Builder, unter Custom Components	Site veröffentlichen	Mitgliederprofil (oder Gastbenutzer): Lesen und Erstellen auf Objekt und Felder, plus eine Freigaberegel. Öffentliche Sites: Gast-Checkliste

Tipp für die Startseite: Setzen Sie Existing Dates Mode (Vorlademodus) auf readonly, für eine schreibgeschützte Ansicht „Was ist geplant“.

Öffentliche Gast-Sites: die Checkliste in fünf Schritten

Auf einer öffentlichen Experience Cloud-Seite kann jeder ohne Anmeldung buchen. Erledigen Sie alle fünf Schritte, bevor Sie als Gast testen. Die Schritte 4 und 5 werden am häufigsten vergessen. Sehen Sie es in der Live-Demo, einer öffentlichen Gast-Site, in Aktion.

#	Schritt	Was Sie einstellen
1	Objektberechtigungen	Geben Sie dem Gastbenutzer der Site Lesen, und Erstellen, wenn Gäste etwas absenden, auf jedes Objekt, das die Komponente nutzt. Gäste können nie bearbeiten oder löschen. Das ist eine Regel der Salesforce-Gastlizenz für jede App, behalten Sie Bearbeiten und Stornieren also Seiten hinter einer Anmeldung vor.
2	Sicherheit auf Feldebene	Lesen auf jedes Feld, das der Kalender anzeigt. Bearbeiten auf jedes Feld, das er schreibt, einschließlich Status-, Zeit- und Beziehungsfeldern. Denken Sie auch an die Felder für Geschäftszeiten und Schließtage der Ressource.
3	Freigaberegel für Gäste	Eine Freigaberegel mit Lesezugriff für den Gastbenutzer, damit Gäste die Datensätze sehen. Die externe organisationsweite Standardeinstellung des Objekts muss Privat sein, damit die Regel greift. Eine als Metadaten bereitgestellte Regel braucht unter Freigabeeinstellungen einen Klick auf Neu berechnen.
4	Berechtigungssatz für Gäste	Weisen Sie MultiDatePick - Guest dem Gastbenutzer der Site zu. Er enthält den Zugriff auf die Apex-Klassen, über die der Kalender seine Daten lädt, plus die Lese- und Erstellrechte, die ein Gast auf den MultiDatePick-Objekten haben darf.
5	Veröffentlichen und aktivieren	Veröffentlichen und Aktivieren sind getrennte Schritte. Gäste sehen nur eine aktivierte Site.

Zwei Org-Einstellungen, die Gäste außerdem brauchen

Einstellung	Warum
Standardinhaber für Datensätze	Gäste können keine Datensätze besitzen, deshalb weist Salesforce jede Gastbuchung einem Standardinhaber zu. Sie legen ihn in den Experience-Arbeitsbereichen unter Verwaltung, Voreinstellungen fest.
Lesezugriff auf referenzierte Datensätze	Eine Buchung, die auf eine Ressource oder einen übergeordneten Datensatz verweist, braucht Gast-Lesezugriff auf diesen Datensatz, sonst scheitert das Speichern mit einem Cross-Reference-Fehler. Verwenden Sie ein benutzerdefiniertes Objekt für alles, worauf Gäste buchen: Der Gastzugriff auf Kontakte und Accounts ist stark eingeschränkt.

Planen Sie eine öffentliche Buchungsseite? Self-Service-Buchung auf einer Salesforce Experience Cloud-Site zeigt, was Gäste tun können und welche Ansicht Sie ihnen zeigen sollten.

Sechs Muster abseits der Datensatzseite

Muster	Seitentyp	Komponente	Hinzufügen
Interner Buchungs-Hub („Raum buchen“)	App-Seite	Booking	Kapazitätsfeld für die Live-Verfügbarkeit „3/10“
Terminbuchung im Kunden-Self-Service	Experience Site	Booking oder Date Time	Ein Flow, wenn der eigene Fall oder Auftrag jedes Kunden der übergeordnete Datensatz ist
Persönliche Verfügbarkeit / Urlaub	Startseite	Dates	Statusfarben: Pending oder Approved auf einen Blick
Veranstaltungs- & Kursanmeldung	Experience Cloud-Site oder App-Seite	Date Time	Maximale Auswahlen begrenzt die Sitzungen pro Person
Ehrenamt & Schichtanmeldung	Experience Site	Booking	Kapazitätsfeld für „freie Plätze“, Statusfarben für Open und Full
Projektmeilensteine	App-Seite	Dates oder Date Time	Statusfarben (Planned, In Progress, Done) und Zweimonatsansicht

Fehlerbehebung

Symptom	Lösung
Speichern erscheint nie	Eine der vier ist leer. Abseits einer Datensatzseite ist es meist Static Parent Record Id.
Kalender lädt, Speichern schlägt fehl	Kein Objektzugriff. Weisen Sie den Berechtigungssatz MultiDatePick - User zu; auf einer Site geben Sie dem Mitglieder- oder Gastprofil Lesen und Erstellen.
„Field does not exist“ beim Speichern	Tippfehler im API-Namen. Kopieren Sie ihn aus Setup, Objekt-Manager. Ein Namespace-Präfix gehört nur zu Objekten eines anderen Pakets (z. B. `acme__Visit_Date__c`).
Site-Mitglieder sehen ihre Datensätze nicht	Legen Sie eine Freigaberegel auf dem untergeordneten Objekt an (oder lockern Sie die organisationsweiten Standardeinstellungen).
Gespeicherte Termine verschwinden beim Neuladen	Lassen Sie Load Existing Dates (Vorhandene Daten vorladen) eingeschaltet (standardmäßig an).
Static Parent Record Id „isn't valid“	Verwenden Sie eine echte 15- oder 18-stellige Id des übergeordneten Objekts, also des Objekts, auf das das Beziehungsfeld zeigt.

Etwas anderes? Unter Fehlerbehebung finden Sie jede Einrichtungsmeldung mit Screenshot und Lösung.

Ein anderes Problem, das hier nicht behandelt wird?

Schicken Sie uns Ihre Fragen per E-Mail. Wir helfen gern.

E-Mail an Support@MultiDatePick.com Zurück zu Erste Schritte Live-Demo testen