TODO
・標準テーブルのＥＲ図、チェック
・インテグレーションパターンなどガイドブック確認
要暗記マーク＝
暗記事項
【BigObjectの特徴】
・インデックスは最大5個、すべて合わせて100文字以内
・BigObjectにデータが作成された後、Triggerなど定義不可。
・一度リリースした後、インデックスを貼りなおしたい場合など、BigObject自体作り直す必要がある。
→この性質により、履歴データなど項目定義が変わらない情報を保持するのに適切。バックアップ目的の場合、項目定義など変わることがあるか検討必要。
【SalesforceConnectの特徴】
・ODataプロトコルを使い、外部のデータを、Salesforce上で参照できる。（データ自体をコピーするのではなく、仮想的に見える）
→なので、当然Chatterやロジックは使えない。（仮想だから）
・1時間あたり2万回のCallOut制限、1時間あたり10万行のデータ取得制限があることから、頻繁／大量データの参照は向いていない。
※高データボリュームの設定もあるが、レポートが使えないなどの制約も出る。
【FileConnectの設定方法】
・OneDriveなど外部ストレージとSalesforceを接続する際のソリューション
・FileConnectの有効化をし、権限セットの付与、認証プロバイダの設定、外部データソースの追加など必要
【＜LDV対策＞スキニーテーブルの特徴】
どんな仕組みか？：元のテーブルから検索対象の項目など特定列に限定し、検索速度を上げる施策。レポート、リストビューなどSOQLのquery。
・大量データのパフォーマンス対策として有効
・1テーブルに限定、100項目まで。
・Account、Contact、Opp、Case、Leadで使える。
・FillSandのみコピー可能。
・サポートに問い合わせて有効化する。何か定義変えた際にもサポートに連絡が必要なのがデメリット
【＜LDV対策＞インデックスの特徴】
・作成者やNameなどは最初からインデックスついている。
・外部ID（テキスト、自動採番、メール）を指定すると、1テーブル25つ迄インデックス付与可能。※25
・上記で対処できない場合、サポートに連絡してカスタムインデックスの依頼が必要。
・必ずユニークである必要はないが、ユニークでないのは非奨励
【ミドルウェア】
・ETL＝大量データ、バッチ、初期データ移行に適切
・ESB＝少量データ、ニアリアル＝システム連携に適切
・ESBを使うメリットは？
システム間が疎結合になる、ログが詳細に取れる（SFより）、エラハンができる点。
加えて、プロトコル変換機能、認証情報をまとめて管理、キューイング、ルーティング、再利用向上（APIのラップ）、一定の加工処理、ポータリングなど
・冪等性（べきとうせい）＝連続して実行した場合でも結果が一緒であることの保証。ESBでReplyIdをもとに制御
【効率化を求め、テスト自動化】
・Apexテスト実行、ドキュメント自動生成、ソースコードチェック、画面自動キャプチャ取得などの自動テストツールなど
【レポートスナップショット】
・1レポート2,000件まで。100項目まで。
【認証】
・1つのIDストア（AD）, 1つのIdp（AzureADなど）、複数のSP（Salesforceなど）の構成の場合、AzureADで振り分けをする。
・Salesforce上のユーザの無効/有効ベースで認証コントロールしたい。→SalesforceをIdpとする。
【ログインフロー】
・実行者のIPなど取得/判断可能
・Visualforceや画面フローの呼び出し可能。
【オブジェクト構成】
【テリトリ】
・Accuount、Opp,Caseで利用可能
・ロールに加え、もう1つ軸が必要なケースの時に利用。テリトリの単位で集計ができる。
・条件に応じて、Accountの割り当てを行う。
例）住所が千葉ならば、「関東」テリトリの社員に参照権限付与/割り当て、など。
・メリット：人事異動が楽。テリトリ別の集計、売上予測。取引先の属性に応じた権限コントロール。ロールだと1つだが、テリトリを使うことにより複数の所属を実現。
【売上予測】
・ロールやテリトリベースで表示可能
【ServiceCloudVoice】 ★もう少し加筆必要
・オムニチャネルやCTI（AmazonConnect）を内包。AmazonConnectの中にはIVRの設定可能。自動文字おこし、オムニチャネルスーパーバイザーで担当者の状況を一覧で確認、担当者の入力状況を見れるなど
※通常はCTIを使う場合、別途AppExchangeからOpenCTIをインストールなど必要だったが、ServiceCloudVoiceなど、コンフィグでAmazonConnectとの連携が可能。
【オムニチャネルとは？】
・メールや電話など複数のチャネルからの問い合わせを一元管理し、各担当者の持っているレコード数（業務量）やスキルに応じて割り当てる機能。
【Salesforceメッセージ】
・FacebookメッセージやWhatsApp、SMSなどの配信
※SMSは、アメリカの電話番号は対応しているが、日本は対応してないので、日本の場合はTwilioなど
【データスキューの対処】
データスキュー＝例えば、1データに1万以上レコードが紐づく場合
・選択リストにする。
・支社で分けるなど
【暗黙共有】
・Accuountに権限がつくと、自動でOpp・Case側に権限がつくなど
【FieldService】
・担当者：受け付けてケース/作業指示を作成
・ディスパッチャー：ディスパッチ：サービス予定
・Filedテクニシャン：実際に工事など実行
・メンテナンス計画にて、生成期間など指定し、自動で作業指示を作れる。（例：生成期間2か月、繰り返し毎月1日、バッチ実行日9/21なら、10/1,11/1ノ2件など）
【商品スケジュール】
https://daigirin.com/forecasts/
・組織設定でONにする。
・商談→商談商品→スケジュール設定すると、スケジュールが自動生成される。
【Flowの発火】
・ToDoや商談チームなど特殊なテーブルのInsert後でも発火する。
【ロール】
・パフォーマンスが悪くなるので、極力わけない事。
・無理に国などで分ける必要はない（要件次第）
【IF】
・外部からSalesforceのAPIをCallする場合、接続アプリケーションの設定。
接続アプリケーション・・・許可リソースの指定、コンシューマ鍵、セキュリティトークンなど
・Salesforceから外部APICallする場合、リモートサイトや指定ログイン情報、TLS/SSLなどでセキュリティ向上
【SDKのデメリット】
・SDKはNFCとかブルートゥースとかの時に使う。
・バージョンアップなどの際に影響確認必要、モバイルのテストが大変
・SDKを使う＝ネイティブアプリになるので、ストアに上げたり大変。
【非同期のメリット/PFイベント選定理由】
・非同期だと疎結合（どっかがダメになってももう片方が動く）。よりスケールする。（待たないで並列実行）
・非同期の連携の中でも、コンフィグで構築できるものがプラットフォームイベント。そして財務システムなどとのIFにおいては、データの欠落はまずいのでそういう意味でもプラットフォームイベントのバスにデータが残る点がよい。
【外部サービス】
・OpenAPIを読み込み、コンフィグで定義。
ーーーーその他メモーーーー
【セキュリティ】
Shiled（HerokuだとHerokuShiledなど）で対処できるが、そもそもSalesforceなどに持たない方が好ましい。クレカならAppExchange活用など
PCI・・・クレカ（PaymentCard）
PII・・・個人情報
HIPAA・・・健康状況
【Org】
・マルチの場合、共通資材は二重になる。（修正が生じた場合にも二重）
【CRMAnakytics】
・外部はCCP以上でないと利用できない。
・外部公開したい場合、上述の通りでゲストユーザなど無理なので、その時はtableauPublicにするなど。
・CRMAnalyticsの外部の連携は、コネクトがない場合、ETLでデータを取得し、データフローでCRMAnalytics側のDBにデータを入れる。
【その他】
・チャットやEinsteinBotは、オムニチャネル必須