Community（Experience Cloud）ユーザーに「即時アクセス」とシームレスなエクスペリエンスを提供するには、アーキテクトはユーザー作成をオンザフライで処理する認証およびプロビジョニング戦略を選択する必要があります。SSOにはSAMLとOpenID Connect（OIDC）の両方が利用可能ですが、OpenID ConnectはOAuth 2.0を基盤としているため、消費者向けの「ソーシャル」または外部ID統合における最新の標準となっています。
「セルフサービス」に不可欠なコンポーネントは登録ハンドラです。SalesforceでOpenID Connect認証プロバイダを設定する場合、Auth.RegistrationHandlerインターフェースを実装するApexクラスに関連付ける必要があります。このハンドラは、ユーザーがまだ存在しない場合にSSOフロー中に実行されます。これにより、アーキテクトはプログラムによる完全な制御が可能になり、以下の処理が可能になります。
* 受信した ID を既存の連絡先またはアカウントと照合します。
* 連絡先レコードが存在しない場合は、新しい連絡先レコードを作成します。
* 正しいプロファイル、権限セット、ロケール設定を使用して新しいユーザー レコードをプロビジョニングします。
* ユーザーを正しいアカウント階層にリンクします。これはコミュニティ セキュリティ モデルにとって重要です。
オプションAは、ユーザーを作成するための宣言的な方法であるジャストインタイム（JIT）プロビジョニングを提案しています。しかし、JITは複雑なデータ検索を実行したり、外部ユーザーに必要な連絡先とアカウントの特定のリンク処理を実行したりする能力が限られているため、Experience Cloudの要件には厳格すぎる場合が多くあります。オプションCは、Salesforceの一般的な用語とは技術的に不一致です。SA​​MLはJITを使用しますが、登録ハンドラーは認証プロバイダー（OIDCなど）と連携するように設計されたネイティブの専用メカニズムです。オプションBを使用することで、企業はIAMシステム経由で初めてログインする登録者がSalesforceに瞬時に正確にプロビジョニングされることを保証し、複数のアカウントを管理する必要性を排除します。

従来の環境から Salesforce のような最新のプラットフォームに移行する場合、最も直接的な技術的ハードルは、既存のシステムで使用されるシステム タイプと通信プロトコルの多様性です。
レガシー環境では、統合が標準化されていないことがよくあります。アーキテクトは、最新のREST/SOAP APIを介して通信するシステムに遭遇するかもしれませんが、フラットファイル交換（FTP/SFTP）、メールベースのトリガー、または直接データベース接続に依存する古いシステムに遭遇する可能性もあります。これらの「システムタイプ」は、統合ミドルウェアの選択を左右するため、根本的な制約となります。例えば、Salesforceはネイティブでファイルシステムをポーリングしたり、オンプレミスデータベースを読み込んだりすることはできません。そのため、アーキテクトはこれらの制約を特定し、これらのレガシープロトコルとSalesforceのAPI中心のアーキテクチャを橋渡しするETLまたはESBツールの必要性を正当化する必要があります。
レポート機能（オプションB）とマルチ通貨（オプションC）はSalesforce実装における重要な機能要件ですが、ソースシステムとターゲットシステムの技術インターフェースほど、統合パターン（リクエスト/リプライ方式とバッチ方式など）を決定づけるものではありません。アーキテクトは、既存のAPI、ファイルシステム、メール機能をまず評価することで、選択した統合メカニズム（ストリーミングAPI、バルクAPI、ミドルウェアオーケストレーションなど）が、レガシーシステムと実際に通信できる技術的能力を備えていることを確認します。

Connect REST APIは、Chatterフィードやソーシャルデータ（ユーザー、グループ、フォロワー、ファイルなど）にアクセスするために設計されています。このAPIを使用することで、統合機能は#thanksNTOハッシュタグを含むChatter投稿をクエリし、別のAPIを使用してTwitterに投稿できます。REST API、ストリーミングAPI、Apex RESTはChatterに特化したものではなく、Connect REST API2と同じレベルの機能と使いやすさを提供しません。参考文献：1：Fire and Forgetパターン 2：Connect REST API

説明
BatchApexErrorEvent オブジェクトは、Batch Apex 実行中に発生したエラーを処理できます。このイベントをサブスクライブすることで、統合機能は失敗したレコードの請求書生成を再試行したり、その他のリカバリアクションを実行したりできます。これは、Batch Apex ジョブ自体やミドルウェアにカスタムコードを追加する必要のない、回復力と拡張性に優れたソリューションです。