アプリケーションビルダー3

Salesforceのユーザで、承認された他のサービスにアクセスすることができる機能 もしくは、他のサービスからセールスフォースにアクセスできる機能

アプリケーションランチャーから外部のサービスを利用できる機能、SSOと一緒につかうと、誰がどのアプリケーションを利用できるかの制御ができる。

外部プロバイダのソーシャルアカウントを利用してSalesforceにログインできる機能。

Salesforce外で、ユーザ管理ができる機能、MicrosoftのActive DirectoryなどをSalesForceのユーザ情報と同期できる。

SAMLプロトコル

サービスプロパイダーはIdプロパイダーへ問い合わせを行い、応答(アサーション)を得ることができる やりとりはxmlベース

アプリケーション間のセキュアなデータ共有を可能にするためのプロトコル アプリケーションでSalesforceにアクセスするための要求と認可ができる。

OpenId Connect

idプロパイダー

アプリケーションビルダーのページプロパティからアクションを追加できる 追加できるアクションは、グローバルアクションに限られます。これには、活動の記録、新規取引先、新規商談などが含まれます。 上のアプリケーション名が書いてあるヘッダーのとこにボタンが追加される

投稿、アンケート、質問、お知らせ(グループが設定されてる場合)

グループが90日間活動がないと、アーカイブ化される。 アーカイブ化されると、凍結みたいな感じで投稿などができなくなる。

Charter設定のグループ内のレコードを許可を設定し、グループページからレコード追加アクションを実行する ※該当オブジェクトに対してもchatterグループ内で許可が設定されていること 共有すると、グループ内で追加したレコードが関連リストとしてみえるようになる https://sf.forum.circlace.com/articles/556578234775375872

公開グループ、非公開グループ、リストに追加しないグループ、ブロードキャストのみ

Chatter設定の不在通知のところをチェックし、ユーザのページから不在通知アクションを実行

Chatter設定の承認を投稿を許可する。 もちろん、承認申請プロセスを該当オブジェクトに対して作成する必要もあり、Chatter投稿のテンプレートはそこで設定できる。 https://milkteaa.com/approve-records-from-chatter-feeds/

[Chatter設定]で、[同僚の招待を許可]、[顧客の招待を許可]が有効化されていることを確認する。 グループの設定（詳細）で「アクセス種別」を「非公開」に、かつ、「顧客を許可」にチェックを入れる。※戻せない グループページのアクションから、「ユーザを招待する」でメールアドレスを指定して社外関係者を招待する。※ユーザを招待するためには権限が必要 また、ライセンスは 顧客であればChatter Externalとなる。 同僚であればChatter Free。 https://www.sunbit.co.jp/blog/2021/04/21890/

グループの活動を可視化するダッシュボードのようなもの

リストに記載しないグループ

グループの所有者か、グループに設定したマネージャー権限を持つユーザー

グループレイアウト

フィード追跡で、そのオブジェクトをオンにする。 レコードページを編集し、chatterコンポーネントを追加する

そのオブジェクトとその項目のフィード追跡を有効にし、レコードページのChatterコンポーネントを利用して追跡ができる。

オブジェクトに対して30項目まで追跡可能

まとめて表示されるようになり、うっとおしくならない

Salesforceにプロファイルベースのリリースを有効化してもらうように依頼し、Chatterを有効化の権限をユーザのプロファイルや権限セットに付与してChatterを有効化する その権限があるユーザーだけチャターが使える。 https://help.salesforce.com/s/articleView?id=sf.collab_pbr_profiles.htm&type=5

システム管理者が指定したドメインに対して、 招待メールを送った(グループページから送れる)場合は、 Chatter Freeライセンスとなる。 指定したドメインでない場合は Chatter Extarnalライセンスとなる。 Chatter Freeライセンス　社内の同僚向け Chatter Extarnalライセンス　外部ユーザ向け

標準salesforceライセンス

リストページやレポートなどで、名前全体が収まらない場合にユーザを識別する短縮名で、デフォルトではユーザ名の最初の文字と姓の4文字。

組織、オブジェクト、項目、レコード

ユーザの組織へのアクセスできるかの制御 として、組織の信頼済みのIP範囲を設定などができる あとログイン時間帯とか

プロファイルごとに、ログインIPアドレスの制御を設定可能 プロファイルごとに、ログイン時間帯の制限が設定可能

プロファイルや権限セットでオブジェクトに対してアクセス制限が設定できる。 参照、作成、編集、削除の設定ができる。

全ての標準オブジェクトに対して、作成や編集ができる。

オブジェクトの権限をもたない Salesforce プラットフォームで最も低い権限を付与します。「活動にアクセス」権限、「Chatter 内部ユーザ」権限、「Lightning コンソールユーザ」権限、「ヘルプリンクを参照」権限が含まれます 「Minimum Access - Salesforce」のプロファイルを指すようです。一部「最小アクセス - Salesforce」と記載されているページもある https://sf.forum.circlace.com/articles/622483605121142784

すべてのデータの参照、すべてのデータの編集

すべての標準オブジェクトとカスタムオブジェクトに対する「参照」、「作成」、「編集」、「削除」、「すべての参照」、および「すべての編集」が有効化される

不可能 すべてのデータの編集権限では項目へのアクセス権は取得できない

組織の共有設定、ロール階層、共有ルール、共有の直接設定

非公開、公開/参照のみ、公開/参照・更新可能、親レコードに連動

非公開、公開/参照のみ

すべてのユーザは対象オブジェクトの全レコードを参照可能だが、更新はレコードの所有者と別の共有設定で許可されたユーザのみに限られる

プロファイルや権限セットで、オブジェクト権限のすべて表示、すべて変更をチェックする

そのオブジェクトへのアクセス制限で、一番きびしいユーザにあわせる。 一番厳しいアクセス権が参照までなら、公開/参照のみを設定 逆に一番厳しいユーザ以外のアクセスに関しては権限セットやプロファイルとかでアクセス許可する

組織の共有設定で該当オブジェクトの外部アクセス権を非公開に設定し、内部アクセス権では公開/参照•更新可能と設定する

組織の共有設定で、該当オブジェクトに対し、階層を使用したアクセスを許可のチェックを外す (標準オブジェクトはこれできない)

Apexトリガーなどから、CustomObject_shareに対してレコードを作成することで、そのオブジェクトの指定したレコードに対して、とあるユーザのアクセス決定を行えるというもの

レコードアクセスの権限は主オブジェクトに従うため、存在しない。

Shareオブジェクトへレコード挿入する際のラベル付けとして利用できる。 Manualなどが既定で用意されているが、 自分で用意する場合は、オブジェクト設定画面からApex共有の理由を追加する必要がある https://www.google.com/amp/s/savepo.com/reasons_for_sharing_apex/amp デフォルトではManualですが、Manual以外に置き換えると、所有者変更を行なった際に、所有者変更前に行なった共有の直接設定が削除されないというメリットがあります。 ※共有の直接設定にて、所有者変更を行うと事前に設定していた共有の直接設定が削除されてしまうので、Apex共有では、Apex共有の理由をManual以外にすると、良い場合がある。 https://qiita.com/sho7650/items/08367ee3ba49078e7567

そのオブジェクトの共有設定が非公開になっている必要があるらしい ちょっとわからん

組織が大規模で共有ルールの作成が手間である場合など。 例として、同一ロールのユーザにも共有したいが、そのロールの数分、共有ルールを作成する必要があり、メンテが大変である場合などに使う。 非同期でシェアオブジェクトのレコードが作成されるので、同期的にやりたい場合などにも利用できる

されない。上だけ。

レコード条件(所有者に基づく、条件に基づく)、共有先、アクセス権

ロール(下位ロール)、テリトリー(下位テリトリー)、公開グループ 公開グループでは全ての内部ユーザも選択可能

ロールなどの共有モデルと似ており、 郵便番号を利用して地域毎にユーザを管理したい場合に使う。 東京テリトリーなど 現在は廃止されエンタープライズテリトリー管理だけが存在している エンタープライズテリトリー管理は地域別や会社規模別に「取引先」を割り当てるユーザを管理できます。 対象となるオブジェクトは「取引先」ですが、関連する「商談」「ケース」についてもエンタープライズテリトリー管理で参照・編集などの権限を設定可能です。 https://fact-marketing.jp/salesforce/salesforce-territory/

共有設定ページの下らへん

所有者ベースの共有ルール、条件に基づく共有ルール

共有ルールの再適用 共有ルールの再適用とは、Salesforceなどのシステムで、共有設定、グループ、ロール、またはテリトリーに変更を加えた際に、それらの変更を反映させるために共有ルールを再評価し、必要に応じてアクセス権を追加または削除するプロセスです。共有ルールの更新が失敗したり、期待通りに動作しない場合に、手動で共有ルールを再適用することができます

レコードページのクイックアクション「共有」を利用する

活動タイムライン Todo、行動

Chatter

商談に紐づく取引先の取引先責任者に対して役割を設定することができる。関連リストとして確認できる

商談チームの設定で、チームセリングを有効化し、レイアウトで関連リストに商談チームを反映することで、商談レコードページから商談チームを設定できる。

商談、取引先、ケース

商談チームに設定されたユーザーとレコードを共有することができる。 所有者、上位ロールの人、および管理者のみがチームメンバーを追加し、メンバーへのより多くのアクセス権限を提供することができます。

商談分割設定で商談分割を有効化し、レイアウト(収益、オーバーレイ)を決め、ページレイアウトに設定する。 商談のレコードページの商談の分割関連リストにて、収益や、オーバーレイの配分を決めて分割できる。 収益タブでは成果としての利益を分配、 オーバレイでは収益には直接関与してないもののサポートしてくれたチームメンバーにクレジットを提供する https://blog.tanebox.com/archives/1115/

Kanbanビュー(グループ化単位の変更も可能)

レコードページの配置でき、そのレコードのフェーズ(進捗状況) ※設定時に選択リストを指定可能 と、そのフェーズにおける重要な項目やガイダンスを表示させたりできる機能

商談、リード、注文、キャンペーン、契約、カスタムオブジェクト

商談、ケース

データエクスポートサービス、データローダー

一週間や、1ヶ月間隔でデータを自動的にエクスポートができる

カスタマイズする前の Salesforce 組織に含まれている選択リストです。 たとえば、リードオブジェクトの [リードソース] 選択リストや商談オブジェクトの [商談フェーズ] 選択リストなどです。 また、リードソースに関しては、 標準オブジェクトの『取引先』『取引先責任者』『リード』『商談』にも存在しており、選択値を共有している 項目のリスト値は共通ですが、レコードの値は独立しています。そのため取引先レコードのリードソースの値が取引先責任者レコードのレコードソースの値に自動でセットされたりというようなことはありません。

セミコロン区切りで保持している

ない。そのまま変換可能

変換した際、項目がクリアされてしまう

選択リストのプロパティで値セットで定義された値に選択リストを制限しますをチェックする

--なし-- api参照名はnullになるとおもう

デフォルト値の設定のみ可能

無効化はレコードの値は削除されず保持されたままとなる。

置換を利用すると、 既存レコードに設定された値を任意の値へ置換することができる。 そのため既存の値にたいして、 空白になるように置換することができる。

連動項目にすることはできない 制御はおけ

制御項目にはなれない

項目の連動関係にて、レコードタイプ、制御項目の値ごとに連動選択リストの値設定ができる

デフォルトの値に数式を使用する。 TODAYとMONTHとCASEを利用できる TodayからMonthをとってきて、 1月ならこの値、二月ならこの値 ってかんじでCASEできめてく

グローバル値セットを利用する、 もしくは、すでに定義した値はグローバル値セットに昇格できる

制限付き選択リストとなるため、別の値を入れることができない

重複レコードを判別する方法を定義したルール。 これを設定しておくことで、 項目の値を比較してあるレコードと既存のレコードが重複しているか判別することができる。 デフォルトで、取引先、取引先責任者、リードのための「標準一致ルール」があらかじめ用意されています。

一致条件の空白項目をマッチングにチェックを入れる。 これで空白項目同士でも一致しているとみなされるようになる。

重複ルールを利用するレコード条件を定義し、 使用する一致ルールを決め、一致したレコードに対して重複作成をブロックさせたり、重複時にだすアラートを定義できる。

3、5 条件指定することで、レコードタイプごとに重複ルールを設定可能

その一致ルールを利用する重複ルールで共有ルールを適用をチェックする これにより、ユーザにアクセス権があるレコードのみを見て、重複レコードかどうか判定します。

重複ルールにて、作成、編集時のアクションで、レポートをチェックすると、 レポートタイプの副オブジェクトに重複レコード項目というオブジェクトが選択可能になる。それでみれる カスタムレポートタイプから作る必要はない。 ちなみにいままでの重複レコードはそれではみれない。 作成、編集時に重複レコード項目オブジェクトにレコードが作成されるため

重複ルールの条件を定義、 とあるレコードタイプの場合は重複チェックするみたいなことができる

{User.Manager} こんなかんじ

承認申請設定画面の承認ステップで、ステップ条件を指定する ステップ条件の指定にて、条件が一致しない場合は、自動で承認、却下が行われる

承認ステップではどういう条件でどのユーザが承認者に割り当てられるか定義します。 また、承認ステップごとに承認アクション、却下アクションを定義することができる。 各承認ステップの却下アクションでは、最終却下アクションを動くようにに設定できる。 1番最後の承認がおわったら 最終承認アクションが動く。 https://go.dx.business/dev/salesforce/24536#Action1

不可能、フローを実行　権限が必要

フローの編集アクセス権の設定で、 許可したいユーザのプロファイルを有効にする これでこのフローを実行できるのは有効にされたプロファイルまたは権限セットを割り当てられたユーザだけになります。