TODO：分析スナップショット、バケット関数、Einsteinリードスコアリング、ChatGPT、CPQ（複数商品に対する価格設定や見積もりを複合的に設定するケース）
https://aismiley.co.jp/ai_news/salesforce-einstein/#cb-h2-n2
TODO：設置作業員の割り当て方（QA中）
https://savepo.com/how_to_serviceresource_object
＝＝＝＝＝＝＝＝＝＝＝
2024/2/10_シナリオ回答
・Canvasの認証：OAuth、Signed Request
・CanvasはESB挟まない。
・Canvasの場合、対向でレポートやビュー、改修などする前提がよい。（画面埋め込みのため）★★重要（SalesforceConnectなど変にソリューション組まないこと。シンプルなアーキに。）
・Field Serviceのモバイルアプリ：地理位置情報を有効化
・割り当てルールとオムニチャネルのサポート起票結果
・NextBestAction：利用者側が画面開いたときに発火（条件に該当するかでクーポン表示したり。Community側のコンポーネントも提供されている。）
・以下は抜粋
https://note.com/nobuyukiwatanabe/n/na7b61d46068d
■ Einstein エンゲージメントスコアリング
顧客のメールエンゲージメントデータを機械学習して、顧客にスコアを割り当て、顧客をいくつかのセグメントに分類します。
■ Einstein エンゲージメント頻度
顧客のメールエンゲージメントデータを機械学習して、送信の頻度を調整すします。つまりメッセージの送り過ぎ、送らな過ぎを判別します。
■ Einstein 送信時間最適化
顧客のメールエンゲージメントデータを機械学習して、連絡先へメッセージを送信するのに最適な時間を決定します。
■ Einstein レコメンデーション
顧客の WEB サイト上での行動を機械学習して、顧客ごとに最も関連性の高いコンテンツで決定し、メールや WEB サイトへ表示します。
2024/1/27_シナリオ回答
・旧システム書き漏れ注意、俯瞰図
・注文レコードにもづく商品（大量データ）のステータス履歴を保持したい。
⇒BigObject（大量に履歴を保持することに向いている。今後項目が変わることも想定しえない場合。）
※ただし、期間が18か月で問題ないなら、Shieldのログでできるケースもあり。
社内メンター相談事項
データのアーカイブについて
業務データやIFが絡んでるデータなどはアーカイブが難しいケースがある。
・背景を伝えて、データアーカイブ対策を伝える。
SalesforceConnect（バシバシ見たり、レポート対象は向かない）
カスタム開発のLWC＋Apex：レポートは向かない。
BigObject：カラムなど変わらない前提で、頻繁にカスタム画面みるなら。業務ユースケース。（ETLで定期的に月次などでバッチで抜く。それをBigObjectに移動後、元のデータを物理削除）
・AWSなどに置いておくだけ：古いデータは見ないけれどもっておきたい。
分析要件
・実態と乖離はするが、試験上、100万件程度であれば標準レポートの選択が適切。
・理由を言って回答。とにかく。
・アーカイブしたデータの分析スナップショットは不可。
決済サービス Chargent ちゃーじぇんと
・決済をSF上の画面から行うAppExchange
Webhook形式のインターフェース
Webhook形式は、プラットフォームイベントに近い。コネクション張りっぱなし。そこに変更があるとPush（PubSubAPIのようなもの）なので、定期的に確認は不要。WebhookからESBをSubScribeして、変更通知もらって、SFを更新する。（デプロイ自動化などでもJenkinsを動かすとき利用）
ServiceCloud系シナリオ
・3. イベントの設営は通常、イベントの1 週間前に開始します。バナーの1 つで問題が発生した場合、会場運営者と顧客は、Eメール、電話、テキストメール、またはチャットを使って技術者に連絡して問題を解決できるようにしたいと考えています。
⇒テキストメール＝SMSなど。
メッセージングとチャット。サポートプロセス系。ServiceCloud
・4. 問題は主にE メールを介して管理され、E メールはOutlook とMS Dynamics が連携しています。Mega Print は社内のサポートプロセスを一元化して標準化したいと考えていますが、E メールを介した通信は現在の運用には不可欠であると見なされ、今後も一般的なサポートチャネルであり続けると考えられます。
⇒メールToケースではないか？
・地理および UST 社が提供する各種装置の専門技術に基づいて、適切なサービス担当者に転送される必要がある
⇒たいがいはオムニチャネル（サービス担当者）、現場に行く場合FSLの可能性あり。
・ERP システムの注文データ詳細は、Salesforce 内から参照またはアクセスできる必要がある
⇒★1レコードの詳細＝LWC、データ量：前提置いて回答してQAで直してもらう。視認性の観点で、LWCコンポーネントを作る。（１：１）地図とか、データ件形成など。
１：N＝SalesforceConnectのほうが言いやすい。
スケジュールトリガフロー VS Apexバッチ
複雑なもの、レコード間の比較や緯度経度、集計などはApexバッチ
チャット
社内のコーディネーターと、顧客のコミュニケーション
