現場で役に立つ Salesforceの設計・実装テクニック！

本編では、Salesforce導入プロジェクトにおける「開発」、ここではプログラムを書いてカスタマイズをすることを指しますが、その良し悪しについてご説明いたします。

【本レクチャーで分かること】

• 本講座における「開発」の定義

• 実装の心得（＆失敗事例）

• 本講座で目指すSalesforce導入の姿

• 「標準機能」を選択すべき理由

• 「開発」を選択すべき状況（よい「開発」の条件）

本編では、どのような要件であれば開発者は工数・リスクの少ない開発を行えるか、業務の中で高い対コスト効果を発揮できるか、について、幾つか例を挙げてご説明いたします。

【本レクチャーで分かること】

• リスクが「高くなる」要件／状況

• 実装の心得（＆失敗事例）

• 本講座で目指すSalesforce導入の姿

• 「標準機能」を選択すべき理由

• 「開発」を選択すべき状況（よい「開発」の条件）

• リスクを高める何気ない変更要件

• 開発の心得（開発における「リスク」の考え方）

【デモ】

• （Chart.jsを用いた）グラフ表示画面部品（AccountChart（LWC））

• 複雑な割引率を計算するための画面部品（DiscountCalculator（LWC））

  • 商談新規作成を上書きするカスタム画面開発で利用（OpportunityForm（Aura））

  • 商談詳細ページに配置

本稿では、Salesforceプロジェクトにおける要件定義工程の進め方についてご説明します。

【本レクチャーで分かること】

• 要件定義工程前後で起こりうる判断イベント

• 要件定義工程で実際にプロトタイプを作り確認する意義

• プロトタイプ開発の心得

• お薦めの要件定義工程の進め方

• 要件定義工程の秘訣

【デモ】

• 割引率を変更しながらそれが反映されたインセンティブを確認できる画面部品（DiscountCalculator（LWC））

  • 保存前に確認しながら入力できる画面開発で利用（OpportunityForm（Aura））

  • 一旦保存してから詳細画面上で確認しながら入力できるよう詳細画面に配置して利用

本編では、画面を開いたユーザに何かを伝える・警告したい、という要件を実現する幾つかのテクニックをご紹介いたします。

【本レクチャーで分かること】

• 画面系の要件を定義する際に特に気を付けたいこと（有名なSEの逸話）

• 表示系でありがちな要件（注意・対応の必要性を訴えたい）

  • レコードタイプで分けている場合

    • ページレイアウト

    • 条件に基づくコンポーネントの表示

  • レコードタイプで分けていない場合

    • 条件に基づくコンポーネントの表示

  • リストビュー等でも表示したい場合

    • 数式とIMAGE関数を用いたアイコン表示

      • シグナルアイコン

      • プログレスバー

  • もっと凝った表示をしたい場合

    • 汎用バナー表示画面部品

  • 編集画面に表示したい場合

    • インラインヘルプ

    • ページレイアウト／動的フォームのセクションヘッダー

【デモ】

• 「条件に基づくコンポーネントの表示」を用いたバナー画像による強調表示

• 数式とIMAGE関数を用いたアイコン表示（シグナルアイコン、プログレスバー）

• 汎用バナー表示画面部品（HTMLBanner（LWC））

• 編集画面で固定メッセージを表示する方法

  • インラインヘルプを用いた方法

  • ページレイアウト／動的フォームのセクションヘッダーを用いた方法

本編では、特定のユーザ、特定の状態の場合にのみある項目を表示したい、といった要件の実現方法についてご説明します。

【本レクチャーで分かること】

• 「表示したい」「隠したい」という要件の分類

• セキュリティに関する表示要件の考え方

  • Salesforceにおける「共有」の考え方

  • 例

    • 基本的に商談は全ユーザが参照してよいが、「政府案件」フラグがTRUEの場合は「政府案件対応グループ」のユーザだけが参照・編集できるようにしたい

    • 商談は同じ部（ロール）のユーザが所有する商談だけ参照でき、他の部のユーザが所有する商談は参照できない

  • 「同じ部にだけ」という要件のリスク

  • 特定の項目を表示・非表示したい要件の考え方

• UI/UXの観点で表示・非表示を制御したい要件の考え方

【デモ】

• 共有機能を使ってレコードのアクセス権限を制御する

  • 基本的に商談は全ユーザが参照してよいが、「政府案件」フラグがTRUEの場合は「政府案件対応グループ」のユーザだけが参照・編集できるようにする

  • 商談は同じ部（ロール）のユーザが所有する商談だけ参照でき、他の部のユーザが所有する商談は参照できないようにする

• 条件に応じて項目を表示・非表示にする

  • 数式を用いる

  • 画面部品を開発して用いる（PublisedRateViewer（LWC））

• UI/UXのために表示・非表示を制御する

  • 動的フォーム・コンポーネントの表示条件を使って不要なレコードを非表示にする

  • Salesforceのセキュリティ機能を使って古い不要なレコードを非表示にする

本編では、状況に応じて画面遷移先を制御する方法をご説明します。
【本レクチャーで分かること】

• 画面遷移先を制御したい要件の考え方

  • クリックしたら画面に行ける便利なリンクやボタンが欲しい場合

  • 標準機能の画面遷移が気にいらないので変えたい場合

  • 入力フォームなどの遷移先に特定の値を事前設定したい場合

【デモ】

• クリックしたら画面に行ける便利なリンクやボタンが欲しい場合

  • 会社紹介資料の固定リンクを作る（カスタムリンク）

  • 2つ上の親レコードへのリンクを作る（数式項目・HYPERLINK関数）

  • Boxに置いた取引先ごとのフォルダ・ファイルを開くボタンを作る（カスタムボタン）

• 標準機能の画面遷移が気にいらないので変えたい場合

  • 関連リストから新規作成した場合でも、作成後には作成したレコードの画面に飛ぶようにする

• 入力フォームなどの遷移先に特定の値を事前設定したい場合

  • 取引先の詳細ページにその取引先の売り上げを示すレポートのボタンを作る（カスタムボタン）

  • 関連リストから新規作成する場合に親項目の値を事前設定した形で入力フォームを表示するボタンを作る（カスタムボタン、defaultFieldValuesパラメータ）

本編では、１ページに大量の情報を効率よく掲載する方法をご説明します。

【本レクチャーで分かること】

• 大量の情報を掲載する要件の考え方

• 「関連レコード」コンポーネントの活用方法

• 詳細ページに大量の情報を掲載する要件の注意点

【デモ】

• レコードの詳細ページに３列で情報を掲載する

  • Lightningページテンプレートと動的フォームを使った方法

  • タブコンポーネントを使った方法

• グラフ画面部品を開発して効率的に情報を掲載する

• 「関連レコード」コンポーネントを使って親レコードの情報を表示・編集する

• モバイル用レイアウトの確認方法

本編では、ユーザの入力データを少し複雑なロジックでチェックするための方法をご説明します。

【本レクチャーで分かること】

• 少し複雑なチェックロジック要件の考え方

  • 入力規則を用いて実現できないか考える

  • ルックアップ検索条件を用いて実現できないか考える

  • 最終手段としてApex/フローを用いる

【デモ】

• 入力規則を用いたチェック方法

  • 特定のユーザだけが編集できるようにする（システム管理者にも編集できなくする）

  • メンテナンスモード中にだけ編集できるようにする

  • 積み上げ集計項目を用いたチェック

• ルックアップ検索条件を用いて検索結果を制御する方法

• 標準商品レコード検索時の制御方法

  • 価格表エントリを用いる

  • 共有機能を用いる

• フローを用いて入力チェックを行う方法

• Apexを用いて入力チェックを行う方法

本編では、Salesforce上における一括処理の実装方法についてご説明します。

【本レクチャーで分かること】

• 一括処理要件はなぜ出てくるのか？どう向き合うべきか？

  • システム管理者用の一括処理機能

  • 業務ユーザ用の一括処理機能

• 更に高度な一括処理が必要な場合の考え方

  • Excelを用いた実現方法

  • そもそも何故一括機能が必要なのか確認する

【デモ】

• データローダー

  • インストール・利用方法

  • Upsertと外部IDを用いて18桁のレコードIDを用いず関連情報を登録する方法

  • コマンドラインバッチモードを用いた方法（レクチャー28で詳しく説明）

• データインポートウィザード機能・Dataloader.io機能

• ウィークリーエクスポートサービス機能

• リストビューの一括編集機能

• レポートの一括編集機能

• 一般ユーザが使える標準インポート機能

本編では、「開発が必要かもしれない」という要件が利用者からあがってきたときに、開発者とのコミュニケーションでありがちなすれ違いと、それぞれの想いについてご説明します。

【本レクチャーで分かること】

• 「利用者」と「開発者」の立場

  • 「利用者」の言い分

  • 「開発者」の言い分

本編では、「～するボタンを設置して欲しい」など、ちょっとした便利機能で工数・リスクが少ない開発で実現できそうな開発要件について、開発者の方々に向けてテクニックをご紹介したいと思います。

【本レクチャーで分かること】

• ボタン要件の考え方

• ボタンの実装方法

• 画面配置可能なLC・LWCとしてボタンを作る要件の考え方

• ボタン実装のポイント

  • ボタンに業務ロジックを実装しない

  • 汎用的なボタン部品を作る

  • モバイルでの利用を意識・確認する

【デモ】

• レコードの新規作成・更新画面を表示するボタン（クイックアクション）

• レコードの特定項目に固定値を設定するボタン（クイックアクション＆定義済み項目値）

• 開発者が作った画面部品を呼び出す標準ボタン（カスタムボタン、クイックアクション）

• 見積書をPDFで出力する画面部品（QuotationPrinter（VF））

• 画面ありクイックアクション画面部品（ScreenQuickActionSample（LWC））

• 画面なし（ヘッドレス）クイックアクション画面部品（HeadlessQuickActionSample（LWC））

• 標準のグローバルアクション（メール送信）を呼び出すクイックアクション画面部品（SendEmailQuickActionSample（LWC））

• レコードの特定項目に固定値を設定する汎用ボタン画面部品（UpdateButton（LWC））

  • 上記のクイックアクションとは異なり、画面を出さずに値を更新するボタンとして利用

  • Account.Owner.Nameのようにドットを使って多段階層の参照項目を指定されても値をクエリして取得する方法

  • 上記の際に項目へのアクセス権をチェックする方法

  • 上記の際に対象レコードへのアクセス権をチェックする方法

  • モバイル上でも利用できるLWCにする方法

• 任意の画面に遷移する汎用画面遷移ボタン画面部品（JumpButton（LWC））

  • PageReferenceを使って画面遷移を実装する方法

  • 新規作成・更新画面に任意の値を事前設定する方法

  • プレースホルダで動的に値を埋め込めるようにする方法

• 商談に配置する、請求レコードを作成するボタン画面部品

  • UpdateButton（LWC）で項目を更新してApexトリガー（OpportunityTrigger、OpportunityTriggerHandlerForInvoice）で新規作成

  • Refresh APIで関連リストをリロード

• 2つのレコードを選んで紐づけるためのボタン画面部品（MatchingMaker（LWC））

  • URLパラメータを利用していろいろな導線を考慮した作りにする

    • 専用画面（タブ）にして２つのレコードを順番に選ばせるモード

    • レコードの詳細画面に配置して、もう片方のレコードを選ばせるモード

本編では、標準の承認プロセスを用いた実装テクニックをいくつかご説明します。

【本レクチャーで分かること】

• 標準承認プロセスにおける承認者の指定方法

• 多段階承認プロセスの承認者を動的に自動設定する方法

• 承認プロセス関連におけるリスクの高い要件とその対処方法

  • 標準承認レイアウトに対する開発要件

  • 一括承認申請＆承認

  • 承認ステップの「スキップ」

【デモ】

• 承認者を申請者が自分で指定する承認プロセス（商談承認プロセス：価格交渉承認）

  • フェーズが「予算／決定者の確認」で価格が設定されていないと申請できないようにする

  • 申請者が自分で承認者を設定するようにする

  • 承認されたらフェーズを自動的に「価格交渉」にする

  • 価格交渉承認されていなければその先のフェーズに進めないようにする

• 条件に応じて承認プロセスを変える（マッチング承認プロセス：標準承認、重要承認）

  • グループ（キュー）を承認者として事前に設定する

  • 複数人の承認者を事前に設定し、１名もしくは全員が承認したら先に進むように設定する

  • ステップの開始条件を用いた多段階承認プロセスにおける承認者のスキップ（自動承認扱いになる）

• 承認者を動的に自動設定する方法（商談承認プロセス：提案承認、OpportunityTrigger（Apexトリガー）、OpportunityTriggerHandlerForApproval（Apexクラス））

  • 多段階承認プロセスの承認者を動的に設定する

  • グループメンバーをラウンドロビン方式で分散して選択する

  • 承認申請ボタンを押す前に承認申請条件を満たしていないことをエラーとして表示する

• 承認者レイアウトに関連リストなど追加情報を表示させる画面部品（ApprovalPageSupporter（LWC））

  • ProcessInstanceWorkItem（未承認申請）の詳細ページに配置するため、承認対象のオブジェクトや承認プロセスを認識し、その内容ごとに表示内容を切り替える

  • 添付ファイルをクエリしてリスト表示する

  • datatableにてアイコンを表示する列を作る

  • ファイルのプレビュー画面を表示する

• 特定の承認プロセスに対して申請するボタン画面部品（MatchingSpecialApprovalButton（LWC）、SubmitForSpecialApproval（マッチング承認プロセス））

  • Apexにて承認プロセスを開始できる

  • Apexによる承認プロセス申請では、設定による承認プロセス開始条件を無視して開始できる

  • 複数承認者の設定など、承認者の設定をApexで上書きすることはできない（無理やり複数回承認者をApexで設定しようとするとどうなるか？）

  • グループの中からランダムに承認者を選ぶ（Apexでグループメンバーをランダムに選ぶ）

• 未承認申請一覧を表示する画面部品（MyApprovalList（LWC））

  • 承認プロセス関連の標準オブジェクト構造

  • ログインユーザが承認できる未承認申請（自分が承認者、代理承認者）を一覧表示する

  • 一括承認・却下する

  • 自分が行った承認に関する履歴を表示する

  • datatableでメニューアクション列を表示する

  • SOQLを書くために標準オブジェクトのリレーションシップAPI名を確認する方法

本編では、添付ファイル管理に関する実装テクニックをご紹介します。

【本レクチャーで分かること】

• 添付ファイルに関する要件の考え方

• ファイル関連の標準オブジェクト構造

• 「フォルダ」カスタムオブジェクトの導入

• 「フォルダ」レコードのアクセス権制御

• Experience Cloudユーザとファイル共有する際の注意

【デモ】

• 提出確認用フォルダ機能（汎用フォルダ）（FolderTreeViewer（LWC）、ContentDocumentLinkTrigger・ContentDocumentTrigger・FolderTrigger（Apexトリガー）、ContentDocumentLinkTriggerHandler・ContentDocumentTriggerHandler・FolderTriggerHandler・FolderLogicHandler_Opportunity・FolderLogicHandler_Matching_c（Apexクラス））

  • 多階層フォルダ構造を作れる（tree-gridを用いてツリー構造を表示できる）

  • 様々なオブジェクトに適用できる

  • ファイルが添付されたら「提出済」フラグが自動的に更新される

  • 「提出済」フラグが変化したら実行さえるロジックをオブジェクト毎にApexクラスで定義できる

  • サブフォルダを含むフォルダにはファイルを添付できないようにする（提出済フラグの制御ロジックを複雑にしないため）

  • datatable/tree-gridの動的アクションの実装方法

  • (deleteトリガーなどで）beforeトリガーでしか取れない情報をafterトリガーに渡して利用する方法

• ファイル整理用フォルダ機能（特定オブジェクト専用フォルダ）（FolderTreeViewer（LWC））

  • サブフォルダを含むフォルダにもファイルを添付できる

  • 添付先の行レベルセキュリティを自動的に継承する（添付先にアクセスできるユーザだけがフォルダ・添付ファイルにアクセスできる）

• 社内ユーザがSales Cloudのレコード詳細画面のChatterからExperince Cloudユーザにファイルを共有する方法

  • Chatter投稿の「宛先」で「アクセス権のあるすべてのユーザ」を指定する（絶対忘れる）

  • ContentDocumentLinkトリガーで特定オブジェクトへの添付を「アクセス権のあるすべてのユーザ」に見えるよう自動設定する

本編では、特定の情報を強調して表示する実装についてご説明します。

【本レクチャーで分かること】

• 凝った表現をするための汎用バナー表示画面部品の開発ポイント

• LastViewedDate項目を使ったユーザごとの既読の管理方法

• 編集画面に特殊な表示を行うための開発ポイント

【デモ】

• 汎用バナー表示画面部品（HTMLBanner（LWC））

  • 文言やスタイルを設定できる

  • モーダル表示できる（配置した画面を開くたびに表示される、コンポーネントの表示条件から外れれば表示されないように制御できる）

  • LightningModalを使ったモーダル表示用LWCの作成

  • LWCで制御できないスタイルの影響を何とかして打ち消す方法

• お知らせ一覧画面部品（AnnouncementList（LWC））

  • 「お知らせ」レコードの一覧を表示する

  • LastViewedDate項目を使ってユーザごとの既読を管理する（ユーザが一度見たお知らせはモーダル表示しない）

  • ApexでLastViewDateを更新する（既読にする）

• 走る猫（RunningCatsBanner（LWC））

  • animation CSSを使って走る猫と一緒にテキストが流れるバナーを表示できる

  • @keyframesを動的に作成して汎用部品にしたかったができず、専用のLWCを作るしかなかった・・

• 標準の新規作成・編集画面に遷移する前にモーダル画面でメッセージを表示するクイックアクション画面部品（ExamEvaluationQuickAction（LC））

  • クイックアクションに設定でき、これをクリックすると固定のメッセージを表示するモーダル画面を表示する

  • モーダル画面を閉じると標準の試験評価作成画面を表示する

• 標準の新規作成・編集画面に遷移する前にモーダル画面でメッセージを表示する標準画面上書き画面部品（ExamEvaluationForm1（LC））

  • 標準アクションの上書きに設定でき、これをクリックすると固定のメッセージを表示するモーダル画面を表示する

  • モーダル画面を閉じると標準の試験評価作成画面を表示する

  • 標準アクションを上書きしたときのURLパラメータの解析・活用（inContextOfRef）

本編では、カスタムオブジェクトに「取引先チーム」等と同じチーム機能を実装する方法についてご説明します。

【本レクチャーで分かること】

• 標準のチーム機能について

• チーム機能の追加

  • 標準のチーム機能がないオブジェクトにもチーム機能が欲しい場合

  • 所有者・システム管理者以外にもチームメンバーを管理させたい場合

• 共有の仕組みについて

  • 共有オブジェクト・レコード

  • Apex共有の理由

• 汎用的なカスタムオブジェクト用チーム機能の実装方法

• 制限の少ないチーム機能の実装方法（特定のオブジェクト専用）

【デモ】

• 標準のチーム機能

  • チームメンバーの作成・レコードアクセス権の付与

  • 有効化・チーム内の役割の管理

  • デフォルトチームメンバー

• 実際の共有レコード

  • ParentId、UserOrGroupId、RowCauseで一意になっている

  • 所有者はRowCause＝Manualの共有レコードしか消せない

  • UserRecordAccessオブジェクト（実際のアクセス権をチェックする際にクエリする）

  • Apex共有の理由の設定

• 汎用カスタムオブジェクト用チーム機能（GenericTeamList・CustomDataTypesProvider・GenericTeamListNewModal・GenericTeamListEditModal（LWC））

  • どのカスタムオブジェクトにも汎用的に利用可能（ただし状況によって制限あり）

  • 本画面部品の利用権限があれば所有者・システム管理者以外でもメンバーを管理できる

  • チームメンバー（共有レコード）を一覧表示できる

  • チームメンバー（共有レコード）を作成・変更・削除できる

  • datatableにてカスタムデータ型を利用する（ユーザ・グループのアイコンを表示できるテキスト型列の作成）

  • cardにてヘッダーにアクションを追加する

  • ポリモーフィックな参照項目の親オブジェクト項目をクエリする（TYPEOF句）

  • 特定の英語エラーメッセージを日本語に変換して表示する

• 特定カスタムオブジェクト専用チーム機能（EmployeeTeamMemberTrigger（Apexトリガー）、EmployeeTeamMemberTriggerHandler（Apexクラス））

  • チームメンバーカスタムオブジェクトを定義するので、標準の関連リストを利用できる

  • チームメンバー（カスタムオブジェクト）レコードでそのメンバーユーザのレコードアクセス権を管理できる

  • チームメンバーのアクセス権制御項目にて「デフォルト」を指定すると、レコードのアクセス権を制御しないようにできる（これのおかげで共有オブジェクトがないオブジェクトやアクセス権を持たないユーザも扱うことができる）

  • ３つの項目値の組み合わせが同じレコードを効率よくクエリする方法

  • 複数レコードの処理でも適切な画面表示用エラーメッセージを作成する方法

本編では、カスタムオブジェクト当たりの項目数の最大値を超えてしまう数の項目を持ちたい場合の解決手段についてご説明します。

【本レクチャーで分かること】

• Salesforceのオブジェクト数・項目数・データ容量の制限について

• 項目数が増えすぎてしまう原因とその対策

  • 時系列やイベントに応じて同じオブジェクトに項目を追加してしまう（レポート等のため）

  • 部署などによって違う項目で管理するため項目を追加してしまう

  • １つのレポートで表示するためにオブジェクトを集約してしまう

• Salesforce流 営業向け予実管理レポート・ダッシュボード（グラフ）の作り方・業務上での使い方

  • 実績をフェーズごとに積み上げて表示する棒グラフ

  • 実績と同じグラフに予算（目標）を表示する方法

  • 期の各タイミングにおけるグラフの読み方・営業判断の考え方

  • どんどん予想精度を上げていくための運用方法・考え方

【デモ】

• 時系列やイベントに応じて同じオブジェクトに項目を追加してしまう例

  • 直近４四半期の売り上げ目標と実績をページレイアウトに並べて比較したい

  • 上記をレポート上で部署ごとに棒グラフを並べて表示したい

  • 別オブジェクトを定義して複数レコードを紐づけて利用する解決方法

    • 参照項目と関連レコードコンポーネントを利用

    • 結合レポートを利用

• 部署などによって違う項目で管理するため項目を追加してしまう例

  • 部署ごとに持ちたい情報が異なる場合

    • 法務部は法務チェック結果、経理部は与信チェック結果を取引先に持ちたい

    • 各部署ごとに持ちたい情報を別オブジェクトに定義して参照項目に持つ解決方法

  • 各部署で同じ項目に異なる内容を別々に持ちたい場合

    • 部署毎のお客様との関係性・コンタクトパーソン・備考を取引先に持ちたい

    • 別オブジェクトに定義して子オブジェクトとし、各部署が１レコードずつ作成する解決方法

      • 全部署の情報を見るユーザは取引先の関連リストで見る

      • 各部署は自分の子オブジェクト側レコードを普段使いする（関連レコードコンポーネントで取引先のように見せる）

• １つのレポートで表示するためにオブジェクトを集約してしまう例

  • 別レコードの同項目を並べて表示したい（JOIN）

    • 直近４四半期の売り上げ目標・実績をレポートで並べ、棒グラフで表示したい

    • 結合レポートを利用する解決方法

    • バッチなどで対象のレコードを参照項目に設定して通常レポートで表示する解決方法

  • 別オブジェクトのレコードを共通項目を揃えて縦に並べて表示したい（UNION）

    • 別々のオブジェクトで管理している業務（商談、プロジェクト、派遣など）のリスクを統合的に管理できるレポートを作りたい

    • 包括オブジェクトを定義し、共通項目の値を数式などで表現して通常レポートで表示する解決方法

      • 参照関係を用いた数式を多用することで参照する項目の制限に抵触することを避ける方法

• 四半期ごとに参照項目を付け替えるバッチ（TargetRevenueBatch・TargetRevenueScheduler（Apexクラス））

  • Apex Batchの利点・注意事項・基本的な構造

  • Database.RaisesPlatformEvents インターフェースとそのイベントを利用方法

  • 自前のアプリケーションログ管理

  • スケジューラ

• 包括オブジェクトを自動的に作成して各オブジェクトを参照項目に紐づけるトリガー（OpportunityTrigger・ProjectTrigger・DispatchContractTrigger（Apexトリガー）、WrapperRecordUtils（Apexクラス））

• 包括オブジェクトに多段階層を回避するためのショートカット参照項目を自動設定するトリガー（RiskManagementTrigger（Apexトリガー）、RiskManagementTriggerHandler（Apexクラス））

• 予実管理レポート・ダッシュボードの作り方（営業予実レポート（レポート）、営業予実ダッシュボード（ダッシュボード）、OpportunityTrigger（Apexトリガー）、OpportunityTriggerHandlerForRevenue（Apexクラス））

  • 予算（売上目標）をカスタムオブジェクトで自作する場合に必要となる構造（売上予測と同じ構造）

  • 上記の構造を保つために必要なトリガー

  • 各フェーズの確度（％）の値の決め方、精度の上げ方

  • セールスプロセスの使い方・意味

本編では、アクセス権や表示条件に関するテクニックをご紹介します。

【本レクチャーで分かること】

• 表示要件の考え方（おさらい）

• Salesforceのアクセス権制御 ー 「機能権限」と「共有」について

• 共有の制御方法

  • 完成するまで所有者以外にアクセスさせない（おさらい）

  • 特別なレコードだけは特定のチームにしかアクセスできない（おさらい）

  • 自分の部署のレコードしか編集できない

    • この手の要件が出たときに必ず確認する事項・注意する制限

    • 「共有ルール」か「Apex共有」かの判断

    • 「Apex共有」を選ぶ時の注意事項

  • 完成するまで所有者以外にアクセスさせない（外部ユーザも対象とする場合）

    • Customer Communityユーザが対象に含まれる場合の注意事項

    • 共有セットを使って無理やり実現する方法

    • 制限ルールを利用する方法

• Customer Communityユーザのアクセス権を制御する方法

• 兼務のアクセス権制御の実現方法

• 共有ルールを作る時のポイント

• Apex共有の再適用

• 外部ユーザの共有制御

  • 外部ユーザの種類

  • 取引先ロール・取引先ロールの最適化（ARO）

  • Partner Community／Customer Community Plusユーザ専用のアクセス権制御機能

    • 取引先リレーション／取引先リレーションデータ共有ルール

    • 外部取引先階層

    • 外部管理取引先

  • 外部ユーザ専用のアクセス権制御機能

    • 共有セット

• 制限ルール

【デモ】

• 完成するまで作成者以外は公開資料にアクセスできないようにする

  • 共有ルール（おさらい）

• 政府案件商談だけは政府案件対応チームだけがアクセスできるようにする

  • 共有ルール（おさらい）

• 手動共有・Apex共有の仕組み（おさらい）

• 自分の部署のマッチングレコードしか編集できないようにする（部署数が多いのでApex共有で実現する）（MatchingTrigger（Apexトリガー）、SharingUtils（Apxクラス））

  • マッチングオブジェクトに「担当部署」選択リストを作りこの項目で制御する

  • Apexでの共有レコード操作

• 自分の部署のプロジェクトレコードしか編集できないようにする（部署数が多いのでApex共有で実現する、所有者ベースで制御する必要がある場合）（ProjectTrigger・UserTrigger（Apexトリガー）、SharingUtils・ProjectSharingRecalcBatch（Apexクラス））

  • 異動を考慮してユーザのロール変更を検知するためにユーザにトリガーを作る

  • ユーザトリガーではMIXED DML Operationエラーを懸念してバッチで共有レコード操作を行う（全件再計算処理にも対応させる）

  • 「組織の共有設定と同じかそれ以下の権限を付与する共有レコードは作成できない」エラーを検知して適切なエラーメッセージを通知する

• Apex共有の再適用

• Experience Cloudユーザ（外部ユーザ）の管理

  • 作成方法

  • 取引先ロールの挙動

• 完成するまで作成者以外は公開資料にアクセスできないようにする（外部ユーザも対象にする）

  • 「ダミー親取引先」と「共有セット」を用いた方法

  • 制限ルールを用いた方法

本編では、余談として「ちょっと気になる、でもよく見るトリガーの書き方」についてお話ししたいと思います。

【本レクチャーで分かること】

• 講師が気になっている、よく見るApexトリガーの書き方

  • トリガーハンドラークラスを1つしか書かない

    • トリガーハンドラークラスを作る意味が半減しないか？

  • トリガーハンドラー内でTriggerクラスを使う

    • トリガーハンドラークラスを作る意味が半減しないか？

  • トリガー実行回数をカウントして一定数で止める

    • 無限ループが発生するのは仕方がないことではない！

• なぜトリガーハンドラークラスを作るのか？

• 「ベストプラクティス」を取り入れるときに考えるべきこと

【デモ】

• 本講義のApexトリガーではどのように「気になる書き方」を回避しているか？

本編では、他ユーザの更新も含めた、データの更新を捉えて画面を更新する方法についてご説明します。

【本レクチャーで分かること】

• 真の「リアルタイム」処理とは

• Webアプリケーションの仕組みから考える「画面に表示された情報の『現在の値』」

• 他ユーザのデータ変更を反映させる方法

  • ポーリング

  • イベント通知

• ストリーミングAPI

  • 変更データキャプチャ

  • プラットフォームイベント

• 非同期処理の結果を反映させる必要性とその方法

• Lightning Experienceのキャッシュを更新する方法

【デモ】

• 在庫の現在の情報を画面に表示し、他ユーザに更新されたら自動的に反映させる（InventoryEvents（プラットフォームイベントチャンネル）、InventoryViewer（LWC）、

  • ポーリング

  • イベント購読（変更データキャプチャ）

    • 変更データキャプチャの設定方法・注意事項

    • 変更データキャプチャで変更のなかった項目の情報も送るようにする方法（カスタムチャンネル）

    • empApiを使ってイベントを購読する方法

    • replayIdの使い方

  • input-fieldを使ってレコード検索フォームを作成する方法

• 別サーバー（Heroku）に注文情報を非同期で登録し、その結果と注文番号を待って確認する（IntegrationStatusChecker（LWC））

  • ステータスの変更をトリガーで検知して非同期で別サーバのAPIを呼び出す

  • ポーリングによりステータスの変更を検知して画面全体にローディングアイコンをモーダル表示したり解除したりする

    • 標準画面でステータスを変更されても非同期処理による連携となるため保存後の画面には結果が反映されていない

    • ユーザには連携の完了までローディングアイコンを表示して待たせたい

  • 連携が完了したらコンポーネントが配置されている画面全体をリフレッシュする

    • Refresh APIの使い方

本編では、新規作成を簡略化・便利化する機能についてご説明します。

【本レクチャーで分かること】

• 「高度なコピー機能」の必要性

• 大量のデータを作成するための工夫

  • コピー機能

  • テンプレート機能

  • 一括登録機能

• 標準コピー機能の仕組み・問題点

• コピー機能実装の注意点

• コピー機能の画面方式

  • 標準コピー機能と同じ形式（事前設定値を制御する）

  • 標準画面で「複製元」参照項目を入力させ、保存時にトリガー出補完

  • カスタムクイックアクションにてユーザから情報を受け付ける

• テンプレート機能の利用シーン

  • 既存レコードにテンプレート名を付けて複製の際に選びやすくする

  • 管理元が構成や内容を徹底させるためにテンプレートを作成・管理する

  • 利用ユーザが操作を自動化するために自らテンプレートを作成・管理・共有する

• テンプレートの管理方法

  • 既存レコードを「テンプレート」として用いる

  • 専用の「テンプレート」オブジェクトを定義する

【デモ】

• 標準コピー機能の仕組みと問題点

  • 新規作成画面に複製元の情報が事前設定されている状態で開かれる

  • コピーの際に値を変えられる

  • ページレイアウトに表示されていない項目は複製されない

  • 子レコードは複製されない

• 標準「関連情報とともにコピー」機能

  • 子レコードも複製されるが、商談など特別なオブジェクトにしか実装されていない

• 昔の請求レコードを、実行日の日付から各種日付を新しくした形で、子レコードと共に複製する（請求カスタムボタン（コピー（カスタム）（CopyInvoice）（カスタムボタン）、InvoiceTrigger（Apexトリガー）、InvoiceTriggerHandlerForClone（Apexクラス））

  • 標準の新規作成画面をdefaultFieldValuesパラメータを使って複製元のレコード値を反映させた形で表示するカスタムボタンを作成する（日付は数式上で計算する）

  • defaultFieldValuesパラメータはページレイアウト上にない項目も差し込むことができる（画面には表示されないが保存時には保存されている）

  • 「複製元」参照項目を作り、ここにもdefaultFieldValuesで複製元レコードIDを事前設定させる

  • トリガーで「複製元」参照項目から複製元レコードIDを得て子レコードを複製する

• 既存のマッチングレコードを、カスタマー取引先かパートナー取引先のどちらか or 両方を保持した形で複製する（MatchingCloneQuickAction（LWC））

  • クイックアクションでどちらを残すべきか入力を受け付けてから複製する

  • LWCの処理としてレコードの複製を行う

• 既存の請求レコードにテンプレート名を付けてテンプレートから複製しやすくする

  • 「テンプレートとして用いる」チェックボックス、「テンプレート名」テキスト項目を追加し、ルックアップ検索条件を用いて複製元を利用ユーザが自分で変更する際にテンプレートだけが表示されるようにする

  • ルックアップ検索条件の条件種別にて「省略可能」にすることで、コピー機能ではテンプレート以外のレコードを複製元に設定できるようにする（利用ユーザが変更する際はテンプレートだけが選べる）

  • 検索レイアウトで２つ目の表示項目をテンプレート名にし、テンプレートを選びやすくする

• ToDoテンプレートを事前定義し、任意のレコードに適用すると定義した内容のToDoが自動生成されるようにする、商談にて「提案書／見積書の作成」フェーズに変更されたら事前定義した内容のToDoを自動生成する（ToDoGeneratorQuickAction（LWC））

  • 「ToDoテンプレート」カスタムオブジェクトを定義し、ここに件名など自動生成したい内容（複数セット可能）を設定させる

  • 詳細ページに配置されたクイックアクションからToDoテンプレートを選び適用すると定義した内容のToDo が自動生成される

  • 任意のオブジェクトのテンプレートを作成・適用可能

  • 利用ユーザは自分の作ったToDoテンプレートを共有して他ユーザに使わせることができる

  • 固定ToDoテンプレートレコードを読み込んでToDoを自動生成させるフローを作成できる（自動生成する内容をToDoテンプレートレコードで制御できる）

本編では、一括機能がどうしても必要という場合に開発して実現できる機能をご紹介します。

【本レクチャーで分かること】

• 一括編集・登録要件のリスク

• 一括編集・登録要件が適切と考えられるケース

• 一括編集・登録要件の実現方法

  • AppExchange等より高度な機能を導入する

  • LWCで表形式の機能を開発する

  • 外部で作成したCSVファイルを取り込む機能を開発する

【デモ】

• 各試験官からの評価点数の平均値・標準偏差を確認しながら調整する一括編集画面（EvaluationEditor・ExamEvaluationCustomDataTypesProvider・ScoreTypeComponent（LWC））

  • 各試験官からの評価点数を一覧表示でき、インライン編集ができる

  • 各試験官からの評価点数の平均値・標準偏差をリアルタイムで計算し表示できる

  • datatableを用いたインライン編集機能の実装方法

  • datatalbeのカスタムデータ型（特にinputタグを使わない実装時）にインライン編集機能を実装する方法

本編では、ファイルダウンロード・アップロード機能の実装についてご説明します。

【本レクチャーで分かること】

• ファイルダウンロード・アップロード要件の考え方について

• 外部IDとUpsertを用いた親子関係の紐づけ方法

• Salesforceにてデータを一括登録する際の注意点

• Excel・CSVファイルのダウンロード・アップロード機能を開発する際の注意点

【デモ】

• Dataloaderで登録する際に参照関係の紐づけを外部IDとUpsertを用いて行う

• 一括ダウンロード・アップロード機能（通常モード・分割処理モード）（DataUploader（LWC））

  • ファイル形式、文字コード、識別項目を指定し、データを一括登録・更新（Upsert）できる

  • サンプルデータをダウンロードしてアップロードファイルのフォーマットを確認できる

  • アップロード後にレコードIDを含んだ結果ログファイルが出力される

  • ファイル形式と事前設定した3つのフィルタ条件のうちの１つを指定してデータを一括ダウンロードできる

  • 上記を分割処理で行うこともできる

  • アップロード・ダウンロード項目、フィルタ条件などをLWCのプロパティで指定できる

  • SheetJS、encodingjsのようなサードパーティライブラリをLWCで利用する方法

  • FileIOを用いて自力でアップロードファイルをLWC内で解析してApexに送る方法

  • LWC内でSheetJSを用いてCSV・Excelファイルを解析し２次元配列に変換する方法

  • ApexからLWCに返された２次元配列をSheetJSを用いてCSV・Excelファイルに変換し自動ダウンロードさせる方法

  • LWC内でデータを分割してApexメソッドを呼びだし、分散処理する方法

  • 自動採番項目による通し番号を用いてクエリ（ダウンロード）を分散処理する方法

  • LWC・Apex間でJSONデータ内のNULL値を正しくやり取りする方法

  • ApexにてUpsertで参照項目を外部IDで紐づけする方法

本編では、Salesforceにおけるシステム連携の意味についてご説明します。

【本レクチャーで分かること】

• Salesforceがシステム連携を大切にする理由

• Salesforceでシステム連携を検討するケース

• Salesforceのシステム連携で検討すべき事項

本編では、IT部門には意外と軽視されがちですが、現場では意外と大歓迎な「画面連携」についてご説明します。

【本レクチャーで分かること】

• 画面連携とは

• 画面連携のメリット・デメリット

• 画面連携を行うために必要な条件

• Salesforceの一般的な画面連携について

• Force.com Canvas

• 画面連携ユースケース

  • 外部フォルダを開く

  • 外部システムの関連情報を表示する

  • 外部システムに関連情報を登録する

  • 外部システムの情報を参照して自システムに反映する

• 最終的に目指すシステム連携の姿

【デモ】※ Herokuアプリの実装サンプルは本レクチャーのリソース「lf-udemy-demo-app.zip」参照

• Heroku上の画面アプリをForce.com Canvasで表示する（Canvas_VF（VF）、CanvasComponent（LC））

  • VFページ・Lightning ComponentでForce.com Canvasを介してHeroku画面を表示する

  • VFページとForce.com Canvas（Heroku画面）の間で通信を行う方法

  • Force.com Canvasの仕組み（署名付き要求）

  • canvas.jsを使うときの注意事項

• ユースケース① 取引先詳細ページからBoxフォルダに格納された法務チェックドキュメントを開く

  • Boxの画面を開くリンクの作り方（運用方法）

• ユースケース② 商談詳細ページから外部配送システムの配送確認画面を開く

  • 外部（Heroku）の画面を開くリンクの作り方（URLパラメータの活用）

• ユースケース③ 商談詳細ページから外部配送システムの納品先情報を登録する

  • 外部（Heroku）の登録画面を開き情報を登録させる方法

  • 上記登録画面の呼び出しを契機にシステム連携を実行する方法（外部側からSalesforce APIを呼び出して外部側のデータを作成する）

• ユースケース④ 商談の出荷コードを外部配送システム上で管理されている出荷コードマスタから選んで登録する（ProductPicker（LWC））

  • LWCにiframeを使って自力で外部（Heroku）画面を埋め込む方法

  • LWCと埋め込んだ外部画面間で自力でイベント通信を行う方法

  • 上記埋め込み・通信のために必要なSalesforce側の設定

本編では、GoogleやBox等のAPIを使ってSalesforceと連携したい、でもプログラムを書ける開発者がいない、という場合に取り得る方法についてご説明いたします。

【本レクチャーで分かること】

• 「データ・機能連携」と「画面連携」の違い

• Salesforceから呼び出せるAPI

• SalesforceからAPIを呼び出す方法

• 「外部サービス」機能

• 指定ログイン情報

• API呼び出しを業務プロセスに適用する方法

• 公式・非公式OpenAPI情報を使って外部サービスを作成し、画面フローなどプログラムを書かずに業務で利用する方法

【デモ】

• Box APIを使ってBoxのファイル一覧を表示する画面部品（Boxファイル一覧（画面フロー））

  • 公式OpenAPIデータから外部サービスを作成する

  • Box API呼び出しのためにBox側で必要な設定

  • 指定ログイン情報（外部ログイン、外部認証IDプロバイダ）

  • 画面フローから外部サービスを呼び出す

  • 画面フローで外部サービスの戻り値を一覧表示する

  • 各ユーザの外部ログイン情報登録方法

• Google Calendar APIを使って今週の予定を表示する画面部品（Googleカレンダー今週の予定（画面フロー））

  • 公式にはないので誰かが変換・作成してくれたOpenAPI情報を探して利用し外部サービスを作成する

  • Google API呼び出しのためにGoogle側で必要な設定

本編では、Salesforceの外側からSalesforceのAPIを用いてデータの抽出や登録などを行う方法についてご説明します。

【本レクチャーで分かること】

• Salesforceの各種APIについて

• Salesforce APIを利用するために必要なこと

• Salesforce データローダー、およびそのコマンドライン実行について

• Salesforce APIを利用するその他の方法

【デモ】※ 本デモで用いたデータローダーフォルダとHeroku PostgreSQL DB Scriptは本レクチャーのリソースに添付してあります。

• データローダーのコマンドライン実行

  • データローダーのフォルダ構成

  • 各種設定ファイルの設定方法

  • Salesforce-Heroku PostgreSQL DB間のデータ連携で必要な設定・注意事項

  • データローダーバッチをWindowsタスクスケジューラーからスケジュール起動する

  • 各設定ファイル内でSOQL・SQLに動的変数を用いる方法

• シナリオ① 取引先マスタ管理

  • 企業マスタシステムから配布されるCSVファイルをSalesforceに取り込む

  • SalesforceレコードIDと共にSalesforceの取引先情報をERP（Heroku DB）に登録する

• シナリオ② 取引先の変更

  • ERP（Heroku DB）で変更された企業情報をSalesforceの取引先に反映させる

  • 更新のあった取引先情報をCSVファイルに抽出する

• cURLを使ってSalesforceのAPIを呼び出す

  • 接続アプリケーションの設定方法

  • cURLの導入・利用方法

  • jqの導入・jqを用いたアクセストークン・API呼び出し結果の抽出方法

• 御礼

• まとめ