アプリケーションページ、ホームページ、Experience サイト

これらの画面が違う理由

MultiDatePick は、選択した日付を関連オブジェクトのレコードとして保存し、それぞれを親レコードに紐付けます。コンポーネントが知る必要があるのは、どの親かということだけです。

• レコードページ (例: 行事のレコード) では、Salesforce が現在のレコードの Id (recordId) を自動的にコンポーネントに渡します。追加の設定は不要です。
• アプリケーションページ、ホームページ、Experience サイトには「現在のレコード」がありません。Salesforce は何も渡しません。親がなければ保存先がないため、コンポーネントはクリックしても失敗するボタンを表示する代わりに、意図的に保存ボタンを非表示にします。

Lightning App Builder でアプリケーションページやホームページに、または Experience Builder でページに MultiDatePick をドラッグすると、プロパティパネルに Static Parent Record Id が表示されます。

Static Parent Record Id とフローの使い分け

Static Parent Record Id はコンポーネントを固定の 1 つの親に向けるため、すべての訪問者が同じレコードを見ます。これが最適な場合もあれば、そうでない場合もあります。ユーザーや訪問ごとにレコードを変える必要があるなら、代わりに画面フローで制御します。コンポーネントをフロー画面に配置し、その Parent Record Id を、フローが実行時に決める変数に関連付けます。

全員に同じレコードなら Static Parent Record Id

• 公開の予約ページ: ゲスト向けの「予約を申し込む」ページで、すべての予約が同じ親レコード (1 つの事業所、拠点、リソース) に紐付く場合。固定の Id がまさに最適です。
• 組織全体で 1 つのカレンダー: 「会社の休業日」レコード 1 件や、全員が予約する共有リソース 1 つなど、ユーザーによって変わらないもの。
• 固定のダッシュボードの起点: アプリケーションページやホームページで、常に同じマスターレコードを指すもの。

目安: 「これは誰のレコード?」という問いの答えが「全員同じもの」なら、Static Parent Record Id を使います。

実行時にレコードを決めるならフロー

• ユーザーごとのレコード: 各自が自分のレコードだけを見る場合 (例: 各契約者が自分の休暇カレンダーを開く)。フローで所有者または紐付いた取引先責任者が {!$User.Id} と一致する レコードを取得 を行い、Id を保存してコンポーネントに渡します。
• URL で指定: フローの入力変数がリンクの ?id=… を読み取るので、1 つのページで多くのレコードに対応できます。ゲストでもログインなしで使えます。
• 先に選択: 1 つ目の画面でユーザーが対象 (従業員、会議室、顧客) を検索・選択し、2 つ目の画面でそのレコードのカレンダーを表示します。

配置場所

ホームページのヒント: Existing Dates Mode を readonly にすると、参照専用の「予定一覧」として使えます。

レコードページ以外で使う 6 つのパターン

ここにない問題がありますか?

こちらにメールでご質問ください。喜んでお手伝いします。