要暗記マーク＝

暗記事項

代理管理者　

社内でも外部でも定義可能。

・社内：ユーザロック解除ができる、指定されたロールやその配下のユーザ作成や編集、公開グループの作成、代理ログイン、カスタムオブジェクトの管理（リレーション作成や共有設定の変更は不可）、
https://savepo.com/how_to_delegated_administrator

・社外：CCP以上、他ユーザのPWリセット、有効化、無効化、ユーザ追加
https://tyoshikawa1106.hatenablog.com/entry/2014/01/18/002610
https://help.salesforce.com/s/articleView?id=sf.networks_DPUA.htm&type=5

【商品スケジュールの概要、設定方法】

https://daigirin.com/forecasts/
※商品を定期的に購入するユースケースが該当
・組織設定でONにする。
・商談→商談商品→スケジュール設定すると、スケジュールが自動生成される。

【BigObjectの特徴】

・インデックスは最大5個、すべて合わせて100文字以内
・BigObjectにデータが作成された後、Triggerなど定義不可。
・一度リリースした後、インデックスを貼りなおしたい場合など、BigObject自体作り直す必要がある。
　→この性質により、履歴データなど項目定義が変わらない情報を保持するのに適切。バックアップ目的の場合、項目定義など変わることがあるか検討必要。

【SalesforceConnectの特徴】

・ODataプロトコルを使い、外部のデータを、Salesforce上で参照できる。（データ自体をコピーするのではなく、仮想的に見える）
　→なので、当然Chatterやロジックは使えない。（仮想だから）
・1時間あたり2万回のCallOut制限、1時間あたり10万行のデータ取得制限があることから、頻繁／大量データの参照は向いていない。
　※高データボリュームの設定もあるが、レポートが使えないなどの制約も出る。

【ミドルウェアの特徴・メリット】

・ETL＝大量データ、バッチ、初期データ移行に適切
・ESB＝少量データ、ニアリアル＝システム連携に適切
・ESBを使うメリットは？
システム間が疎結合になる、ログが詳細に取れる（SFより）、エラハンができる点。
加えて、プロトコル変換機能、認証情報をまとめて管理、キューイング、ルーティング、再利用向上（APIのラップ）、一定の加工処理、ポータリングなど
・冪等性（べきとうせい）＝連続して実行した場合でも結果が一緒であることの保証。ESBでReplyIdをもとに制御

【レポートスナップショットの特徴】

・1レポート2,000件まで。100項目まで。
【オブジェクト構成】

【テリトリの特徴】

・Accuount、Opp,Caseで利用可能
・ロールに加え、もう1つ軸が必要なケースの時に利用。テリトリの単位で集計ができる。
・条件に応じて、Accountの割り当てを行う。
　例）住所が千葉ならば、「関東」テリトリの社員に参照権限付与/割り当て、など。
・メリット：人事異動が楽。テリトリ別の集計、売上予測。取引先の属性に応じた権限コントロール。ロールだと1つだが、テリトリを使うことにより複数の所属を実現。

【売上予測は何ベースで表示可能？】

・ロールやテリトリベースで表示可能

【ServiceCloudVoice】　★もう少し加筆必要

・オムニチャネルやCTI（AmazonConnect）を内包。AmazonConnectの中にはIVRの設定可能。自動文字おこし、オムニチャネルスーパーバイザーで担当者の状況を一覧で確認、担当者の入力状況を見れるなど
※通常はCTIを使う場合、別途AppExchangeからOpenCTIをインストールなど必要だったが、ServiceCloudVoiceなど、コンフィグでAmazonConnectとの連携が可能。

【オムニチャネルとは？】

・メールや電話など複数のチャネルからの問い合わせを一元管理し、各担当者の持っているレコード数（業務量）やスキルに応じて割り当てる機能。

【Salesforceメッセージングで何が配信可能？制約は？】

・FacebookメッセージやWhatsApp、SMSなどの配信
　※SMSは、アメリカの電話番号は対応しているが、日本は対応してないので、日本の場合はTwilioなど

【FieldServiceの特徴】

・担当者：受け付けてケース/作業指示を作成
・ディスパッチャー：ディスパッチ：サービス予定
・Filedテクニシャン：実際に工事など実行
・メンテナンス計画にて、生成期間など指定し、自動で作業指示を作れる。（例：生成期間2か月、繰り返し毎月1日、バッチ実行日9/21なら、10/1,11/1ノ2件など）

【Flowの発火するテーブル】

・ToDoや商談チームなど特殊なテーブルのInsert後でも発火する。

【非同期のメリット・プラットフォームイベント選定理由】

・非同期だと疎結合（どっかがダメになってももう片方が動く）。よりスケールする。（待たないで並列実行）
・非同期の連携の中でも、コンフィグで構築できるものがプラットフォームイベント。そして財務システムなどとのIFにおいては、データの欠落はまずいのでそういう意味でもプラットフォームイベントのバスにデータが残る点がよい。

【外部サービスの設定方法】

・OpenAPIを読み込み、コンフィグで定義。

【Org基準メモ】

・マルチの場合、共通資材は二重になる。（修正が生じた場合にも二重）

【CRMAnakytics利用可能ライセンスやゲストへの公開方法、外部データの持ち方】

・外部はCCP以上でないと利用できない。
・外部公開したい場合、上述の通りでゲストユーザなど無理なので、その時はtableauPublicにするなど。
・CRMAnalyticsの外部の連携は、コネクトがない場合、ETLでデータを取得し、データフローでCRMAnalytics側のDBにデータを入れる。

【その他メモ】

・チャットやEinsteinBotは、オムニチャネル必須

②オムニチャネルとは？ServiceCloudVoiceとは？

ServiceCloudVoiceは、設定ベースで開発ができ、機能としてはオムニチャネルやCTI（=AmazonConnect、IVRなども対応）、音声テキスト化による作業時間短縮、Einsteinの奨励回答による応答時間短縮、オムニチャネルスーパーバイザーなど機能を内包している。

ServiceCloudVoiceを適応する場合、設定ベースでCTI（=AmazonConnect）と連携可能。以前はAppExchangeなどからOpenCTIを落としてSalesforceのコールセンターに読み込むなどの対応が必要だった。（ちなみにServiceCloudVoiceは、AmazonConnect以外のCTIを使うことも勿論可能。）

・ServiceCloudVoiceの設定
https://base.terrasky.co.jp/articles/KRS2u
https://www.salesforce.com/jp/products/service-cloud/solutions/call-center-management/
オムニチャネル自体は、複数のチャネル（メールやチャットなど）からの問い合わせを一元管理し、各担当者のプレゼンスやスキル、業務量に応じたルーティングを行う機能。

・オムニチャネルの設定方法（スキルベース）
→スキルベースがコーディングになっているので少し古い。
今は設定ベースでオブジェクトと項目値に応じたスキルの優先度策定が可能。

・履歴トレンドの概要

経時的な項目値の変化を追跡できます。
前月以前の過去 3 か月間と現在の月の現在日付までの、最大 5 つの時点のデータ (スナップショット) を比較できます。
最大 500 万レコードの容量があります。

・Einsteinディスカバリーはどういうときに使う？

Einstein Discovery は、ビジネスデータに関するインサイトを識別し、表面化して視覚化するための統計モデリングと機械学習により、ビジネスインテリジェンスを増強するものです。Einstein Discovery は Salesforce 環境に統合されているため、コードを使用することなく、クリックするだけですばやくデータ分析、予測、改善を実行できます。
　①ビジネスデータに対するインサイトを特定して表示し、視覚化する。
　②ワークフローで将来の結果を予測し、予測される結果を改善する方法を提案する。

・アプリケーション内ガイダンスの概要

★WalkMe

【ログインフロー】

・実行者のIPなど取得/判断可能
・Visualforceや画面フローの呼び出し可能。

【FileConnectの設定方法】
・OneDriveなど外部ストレージとSalesforceを接続する際のソリューション
・FileConnectの有効化をし、権限セットの付与、認証プロバイダの設定、外部データソースの追加など必要

【＜LDV対策＞スキニーテーブルの特徴】
どんな仕組みか？：元のテーブルから検索対象の項目など特定列に限定し、検索速度を上げる施策。レポート、リストビューなどSOQLのquery。
・大量データのパフォーマンス対策として有効
・1テーブルに限定、100項目まで。
・Account、Contact、Opp、Case、Leadで使える。
・FillSandのみコピー可能。
・サポートに問い合わせて有効化する。何か定義変えた際にもサポートに連絡が必要なのがデメリット

【＜LDV対策＞インデックスの特徴】
・作成者やNameなどは最初からインデックスついている。
・外部ID（テキスト、自動採番、メール）を指定すると、1テーブル25つ迄インデックス付与可能。※25
・上記で対処できない場合、サポートに連絡してカスタムインデックスの依頼が必要。
・必ずユニークである必要はないが、ユニークでないのは非奨励

【効率化を求め、テスト自動化】
・Apexテスト実行、ドキュメント自動生成、ソースコードチェック、画面自動キャプチャ取得などの自動テストツールなど

【認証】
・1つのIDストア（AD）, 1つのIdp（AzureADなど）、複数のSP（Salesforceなど）の構成の場合、AzureADで振り分けをする。
・Salesforce上のユーザの無効/有効ベースで認証コントロールしたい。→SalesforceをIdpとする。

【データスキューの対処】
データスキュー＝例えば、1データに1万以上レコードが紐づく場合
・選択リストにする。
・支社で分けるなど

【暗黙共有】
・Accuountに権限がつくと、自動でOpp・Case側に権限がつくなど

【ロール】
・パフォーマンスが悪くなるので、極力わけない事。
・無理に国などで分ける必要はない（要件次第）

【IF】
・外部からSalesforceのAPIをCallする場合、接続アプリケーションの設定。
　接続アプリケーション・・・許可リソースの指定、コンシューマ鍵、セキュリティトークンなど　　
・Salesforceから外部APICallする場合、リモートサイトや指定ログイン情報、TLS/SSLなどでセキュリティ向上

【SDKのデメリット】
・SDKはNFCとかブルートゥースとかの時に使う。
・バージョンアップなどの際に影響確認必要、モバイルのテストが大変
・SDKを使う＝ネイティブアプリになるので、ストアに上げたり大変。

【セキュリティ】
Shiled（HerokuだとHerokuShiledなど）で対処できるが、そもそもSalesforceなどに持たない方が好ましい。クレカならAppExchange活用など
PCI・・・クレカ（PaymentCard）
PII・・・個人情報
HIPAA・・・健康状況