Salesforce設計/構築基本ガイド(後編)

開発

2021.11.08

Share:

はじめに

本書の目的

本書は、Salesforce製品 (Sales Cloud, Service Cloud 等のSaaS CRM製品)の特性を活かしたシステム構築を行うために、検討が必要な事項、また注意すべき事項などを提示することを目的とします。

本書利用にあたっての注意⚠️

本ドキュメントは弊社が既にご提供している各種情報を集約したものとなっています。それぞれの情報の詳細および最新情報は、本ドキュメントの各所に記載のLink先のコンテンツをご参照下さい

対象読者とフェーズ

本書は、Salesforce について基礎的な知識を有している(*)Salesforce製品の設定/導入に関わるメンバーを対象としています。

(*) トレイル「システム管理者初級」相当の知識を有していることを想定

本書の利用フェーズとしては、計画/要件定義フェーズ及び設計/開発フェーズを主としていますが、後続フェーズにおいても参照します。

設計/開発ガイド概要

データモデル

Salesforceでは業務データを格納する主要なオブジェクト(テーブル)があらかじめ「標準オブジェクト」として用意されています。

必要に応じて、新たにオブジェクト(カスタムオブジェクト)を作成することが可能です。

標準オブジェクトを前提とした製品機能を活用することができるよう、なるべく標準オブジェクトを利用します。

ただし、標準オブジェクトは追加できる項目数や挙動などカスタムオブジェクトと異なる特性・制約があり、データモデルもある程度決まった形となるため、利用範囲・方法についてはプロジェクトでの検討が必要です。

主要標準オブジェクト

image.png

参考資料: 

標準オブジェクトの概要(サクセスナビ)

データモデル(SOAP API 開発者ガイド)

標準オブジェクトとデータモデルの適用方針

まずは、最も中核となる以下の標準オブジェクトを核として、周辺の関連するオブジェクトを検討します。

  • 顧客管理: 取引先 / 取引先責任者 / 個人取引先
    (「個人取引先」を有効化するには、Salesforce社サポートに有効化依頼が必要)

  • Sales/Service: 商談、ケース

適切な標準オブジェクトが存在する場合、ユースケースをもとに利用を検討します。

ただし特殊な挙動を持つ標準オブジェクトに注意します(活動、商品など)

該当オブジェクトに紐づいた製品機能を利用しない/適合しない場合や、参考情報として見るだけの場合は、無理に使う必要はありません(※製品はより多くの用途・複雑な用途をカバーする方向に拡張されていきますが、100%はカバーされるわけではありません)

最初から必要以上に複雑にしないようにします

  • 多対多リレーション(連結オブジェクト)は通常のリレーション(1対1や1対多)で表現できないときに使用する
  • 既存(移行元)やデータ源泉のデータモデルと差異があり、(核となるオブジェクト以外で)標準オブジェクトを利用しようとするとデータモデルの変更が必要となる場合、その利用有無はメリット/デメリットを評価し判断する(全てを合わせようとしない)
  • 正規化や分離をしすぎると、移行/連携の難易度は上がる
  • ユースケースからみて、二重メンテナンスや分析が難しいといった問題が発生しないか?という観点で評価する

データのアクセス権

構築するシステムに応じて、各データの参照範囲を定義する必要があります。特に、法律や会社ルール上で見せてよいデータの範囲を事前に確認しておく必要があります。

まずは、下記のような観点でアクセス範囲/データ共有ルールを検討します。

  • システムを利用するユーザ(社員、代理店、お客様、ゲストユーザ)
  • ユーザのアクセス可能とする範囲(オブジェクト、レコード種類)
  • 項目単位でのアクセス制御(参照・更新可否、暗号化要否)

Salesforceでのデータアクセスを検討する上で下記の点を考慮した設計/設定を行います。

(セキュリティリスクを低減するためにも、お客様にてアクセス制御の権限設定を、適切に行って頂く必要があります)

アクセス設計に関しては、以下のような点を参考として方針を決定します。

  • アクセス制御条件が複雑化することを防ぐため、必要以上にアクセス制御は実施しない。
    • 参照できてはいけないデータに対してはアクセス制御を行う
    • 参照できても良いが参照する必要のないデータは、画面での検索条件で制御する設計を検討する
  • アクセス制御方法については、まずSalesforce標準機能(組織の共有設定、共有ルール、共有セット等)で実現できるか検討する
  • 個人の異動や、機構改革での組織改編、統廃合等に対応できるアクセス設計とする

Salesforceでは以下のデータアクセス制御機能が用意されている為、機能を組み合わせて要件に沿った適切なデータアクセス設計を行います。

  • オブジェクト・項目アクセス制御:「プロファイル」でオブジェクト・項目に対するベースのアクセス制限を設定し、必要に応じて「権限セット」でユーザ単位でアクセス権開放の設定を行う。
  • レコードアクセス制御:「組織の共有設定」でオブジェクトに対するベースのアクセス制限を設定し、必要に応じて「ロール」、「共有ルール」、「共有セット」、「共有の直接設定」でユーザ、グループに対するアクセス権開放の設定を行う。
スクリーンショット 2021-08-18 17.38.46.png

オブジェクト・項目アクセス制御について

プロファイル毎にテストが必要、またプロファイルそのものの情報量が多大なため後工程や運用の難易度・メンテナンスの工数に大きく影響するため、基本は権限セットを活用し、プロファイルの数を最小限にする設計を検討します。


実現方法
概要
作成方針

プロファイル
機能の利用可否やオブジェクト、項目へのアクセス権をユーザに付与する設定のコレクション
組織の種別(本部、○○管理部門、一般など)単位で作成する

複数法人ユーザが含まれ、それぞれの法人用のアプリやページレイアウトが異なる場合は、法人単位で作成する

オブジェクト権限はプロファイルに一切付与せず、全て権限セットで管理する。


権限セット
システム権限、カスタム開発機能の利用可否と、オブジェクト、項目へのアクセス権をプロファイル設定から拡張する機能
システム権限拡張が必要な職位(役員・管理職)、管理者用の権限セットを作成する

アプリ×ユースケースのアクター単位で権限セットを作成する

アプリで作成した権限セットや、パッケージの権限セット等、複数の権限セットを纏めてユーザに割り当てる場合は、権限セットグループの機能を利用する

レコードアクセス制御について(通常ライセンスの場合)

以下の「基本的な使い分け」を参考に適切な方法を検討し設計を行います

スクリーンショット 2021-08-18 17.47.25.png

考慮点

  • 本当に自動化が必要な要件か(手動共有で代替できないか)検討する
  • 複数アプリが共用で利用するオブジェクトのレコードアクセス権については組織(Org)管理部門が主導で検討する
  • Apex共有に限らず、共有ルールでもオブジェクトに対し大量に設定されているとパフォーマンスに影響を与えやすいことを考慮する
  • 標準オブジェクトの一部は特殊な設定があるため考慮すること。
    • ロール毎に「取引先」に関連する「商談」、「ケース」のアクセス権を個別設定できる
      ※他の標準オブジェクト、カスタムオブジェクトにはない設定のため見落としがち

    • 「活動」について組織の共有設定は特殊であるため注意する。
      (活動のアクセス権とカレンダーの共有設定の関連について)

  • 組織変更や人事異動の際の挙動まで含めて設計する

レコードアクセス制御について(Experience Cloud (Community)ライセンスの場合)

以下の「基本的な使い分け」を参考に適切な方法を検討し設計を行います

スクリーンショット 2021-08-18 17.56.30.png

考慮点

  • Experience Cloudにおいても基本的な考慮点は前項「レコードアクセス制御について(通常ライセンスの場合)」の考慮点と同様。
  • パートナーコミュニティのコミュニティユーザは、すべての設定が利用可能である為、いずれかの共有設定で、レコードアクセス制御を検討する。
  • カスタマーコミュニティの大規模コミュニティユーザはロールが存在せず、共有ルールが利用できない為、「組織の共有設定」、「共有セット」でのレコードアクセス制御を検討する。
  • 大規模コミュニティユーザは、「共有の直接設定(Apex共有、手動共有)」も利用不可。
  • 大規模コミュニティユーザは、公開グループのメンバーとして設定することはできない。
  • エクスペリエンス(コミュニティ)およびサイトをご利用のお客様には、認証されていないユーザのアクセス権限を確認するために、ゲストユーザアクセスレポートパッケージ(英語版日本語版)利用を推奨。また、ヘルプ記事「ゲストユーザプロファイルを設定するときのベストプラクティスと考慮事項」を参照のこと。

参考資料:

データセキュリティ(Trailhead)

データアクセスの管理

Salesforceサイトおよびコミュニティにおけるゲストユーザのアクセス制御の権限設定について

業務ロジック、画面設計に関して

業務ロジック

要件をもとにシステムで実現した機能についてプロセスを自動化する対象を検討します。

    • 画面から作成されたデータに対して、関連するデータの項目を自動的に更新する。
    • 入力されたデータによって、担当者に次のアクションを実行するように促すメールを送信する。

など

自動化したいプロセスについて、Salesforceで用意されているプロセス自動化ツールのうちどの機能を利用して実現するか選択します

  • Salesforce には、ワークフロー、プロセスビルダー、フロービルダー、トリガ など、組織で反復する業務プロセスを自動化するためのツールが複数用意されている。
    • ワークフロー、プロセスビルダー、フロービルダー:UIベースで設定
    • トリガ、画面ロジック:Apexによるプログラム開発
  • 各実装方法について機能の特徴、制限を理解したうえで、要件の実現や今後のメンテナンス性を考慮して方式を選択する。
    • シンプルな要件の場合は、UIで実現可能なワークフロールール、プロセスビルダー、フロービルダーでの実現を検討する。
    • 複雑な機能要件を実現する場合や、大量データを管理するオブジェクトに対する業務ロジックは、機能集約や処理性能を考慮してトリガでの設計を検討する。
    • 処理の実行順序を複雑化しない為、1つのオブジェクトには1つの自動化ツールプロセスを利用する。
    • プロセス1のアクションからプロセス2を起動し、プロセス2のアクションでさらにプロセス1を起動するなど、無限ループする処理とならないように注意する。
スクリーンショット 2021-08-18 18.03.05.png

画面設計

画面の実装は、Salesforce標準で用意されているコンポーネントを利用する方法と、Visualforce、 Aura コンポーネント、Lightning Web コンポーネントの開発により、画面を構築する方法があります。

画面の実装については、基本的に標準機能を利用する方針とします。

  • 要件によって標準機能で実現できない場合、AppExchangeの活用を検討する
  • 標準機能、 AppExchangeの活用で実現できない場合、Lightning Web コンポーネントの開発により構築する
  • 画面のスタイル定義についてはバージョンアップの影響を受ける可能性がある為、Salesforceの設定で行える範囲とする。
  • CSSの設定なども可能であるが、開発で構築するLightning Web コンポーネント、 Aura コンポーネントに限定する。

画面実装方式の例


実装方式
主な特徴
方針
コーディング
有無

実装
優先度


標準コンポーネント
UI設定によるコンポーネント配置で容易に画面構築可能

Chatter コンポーネント
リストビューコンポーネント
最近使ったデータコンポーネント
レコードの詳細コンポーネント
関連レコードコンポーネント
レポートグラフコンポーネント
タブコンポーネント など

Salesforceバージョンアップ等で機能改善・機能追加の恩恵が受けられる

基本的にまずは標準コンポーネントによる画面実装を行うことを検討する。
ノンコーディング
1

Lightning Web コンポーネント
Lighting画面に特化

コンポーネント方式
HTML と最新の JavaScript を使用して作成されるカスタム HTML 要素

Salesforce社からの推奨実装方式

Salesforce社の推奨実装方式であり、今後の拡張性などを踏まえた上で画面開発を行う場合、基本的にはLightning Web コンポーネントによる実装とする。

コーディング

2

Aura コンポーネント
Lighting画面に特化
コンポーネント方式

既存のアプリでAura コンポーネントを利用して画面実装している場合のみ利用する。

3

Visualforce
Classic画面に特化
1画面全体を実装する方式

既存のアプリでVisualforceを利用して画面実装している場合のみ利用する。

4

画面からの簡単なレコード操作の要件に対してはクイックアクションの利用を検討します。

クイックアクションは専用ページレイアウトが用意されているため、限定された項目を表示する/デフォルト値を設定して処理を行うことが可能。

UIの統一感と操作性を持つために処理の起動が標準ボタンの場所から期待される場合、クイックアクション/カスタムボタンで対応することを検討する。実装の要件が満たされない場合、画面や処理のみ開発での対応を検討する。

image.png
image.png

リストビュー/レポート/ダッシュボード設計

リストビュー、レポート、ダッシュボードについてはSalesforceの制限が存在する為、制限を理解したうえで、機能の利用について検討します。
レポート、ダッシュボードでの実現ができない場合、対象データの件数次第でTableau / Tableau CRM等の利用を検討します。


機能
代表的な制限

リストビュー
リストビューに表示できる項目は15項目まで。
リストビュー上でカスタムロングテキストエリア項目は、先頭の 255 文字だけが表示される。



レポート

レポートあたりの項目検索条件数は最大20項目まで。
レポートグラフの埋め込みを行う場合、グラフの更新は組織で1時間に3000回まで。
【レポートAPIの制限】
レポートの同期実行の要求は組織で1 時間あたり 500 回まで。



ダッシュボード

1組織あたりの動的ダッシュボード数

Professional Edition:0個 Enterprise Edition:最大5個 Unlimited Edition:最大10個
ダッシュボードの更新のスケジュール設定

Professional Edition:0件 Enterprise Edition:1時間あたり最大1件 Unlimited Edition:1時間あたり最大2件
【ダッシュボードAPIの制限】
1組織あたり1時間に要求できるダッシュボードの結果表示は5000回まで。

1組織あたり1時間に要求できるダッシュボードの更新は200回まで。

上記、レポート、ダッシュボードの制限は、主に組織に関連する代表的な制限を記載。
上記以外の制限、及び、制限の最新情報は、「
レポート制限、制限および割り当て」 を参照。

Salesforce制限事項に関して

画面ロジックやトリガなどApexを利用して開発を行う場合、Salesforceの制限に抵触しない設計を行います

主な制限の例(最新の制限情報については、参考資料を参照のこと)

トランザクション単位のApex制限


#
説明
同期
非同期

1
発行されるSOQLクエリ数(Select文)
100
200

2
発行されるSOQLクエリ(Select文)によって取得されるレコード合計数
50,000


3
Database.getQueryLocatorによって取得されるレコード合計数
10,000


4
発行されるSOSLクエリ数
20


5
発行されるSOSLクエリによって取得されるレコード数
2,000


6
発行されるDMLステートメント(Insert/Update/Delete/Upsert文)の合計数
150


7
発行されるDMLステートメントの結果として処理されるレコードの合計
10,000


8
HTTPコールアウト数
100


9
HTTPコールアウトにおける総タイムアウト値
120秒


10
@futureメソッドコール回数
50


11
キューに追加されるApexジョブ最大数
50
1

12
sendEmailメソッド合計数
10


13
ヒープサイズ合計値
6MB
12MB

14
最大CPU時間
10秒
60秒

15
最大実行時間
10分

※ batch および future のコンテキストの場合 0、queueable コンテキストの場合 1

プラットフォームのApex制限


#
説明
制限

1
5秒を超える同期要求実行数
10

2
同時スケジュール可能なApex数
100

3
Apexバッチのstartメソッド最大同時実行数
1

4
URLが同じホストへのコールアウト
最大同時要求数

外部:20
Salesforce組織:制限なし

静的Apexの制限


#
説明
制限

1
トランザクション内におけるHTTPコールアウトのデフォルトタイムアウト値
10秒

2
コールアウト要求および応答のメッセージ
最大サイズ

同期:6MB
非同期:12MB


3
SOQLクエリの最大実行時間
120秒

4
Apexリリース内のクラスとトリガの
最大コードユニット数

5,000

API要求の制限


#
説明
制限

1
組織に対する同時API要求数
(SOAP/REST APIによる同時要求の受けれる数)

本番組織:25
Sandbox:25

参考資料:
Salesforce の制限クイックリファレンスガイド

Salesforceと外部システムとの連携について

Salesforceと外部システムを連携することは大規模システムでは必ず発生する。そのためSalesforceが提供するベストプラクティスを理解する必要があります

image.png

image.png

参考資料:インテグレーションのパターンと実践

大量データの検討について驚異の

SalesforceはSaaSのため、個別のデータベースのチューニング等は行えないため、大量データに即して設計が必要となります

参考資料:大量のデータを使用するリリースのベストプラクティス

セキュリティ設定の確実な実施と確保

  • セキュリティ役割分担概要

SalesforceはSaaSであり、Salesforce社で担保するセキュリティと開発/保守ベンダ、エンドユーザーで担保するセキュリティがあります。以下に主な役割分担を示します

image.png

  • セキュリティ役割分担詳細

Salesforce社と、お客様もしくは開発/保守ベンダが提供・担当する主なセキュリティ項目について以下に示します

image.png

Salesforceでは、正しくセキュリティ設定が行われているかどうかを確認するため以下のサービスが提供されています。これらを利用することで組織の状態を理解することが可能となるため、実施することを推奨します。

  • セキュリティ状態チェック
image.png
    • 潜在的なセキュリティ問題を特定して修正し、定期的に見直す
    • Salesforce のセキュリティベースラインに対するお客様の組織のスコアを確認
    • 自社用のカスタムセキュリティベースラインのアップロードと再利用
    • 1つの画面から直接問題を修

参考資料:セキュリティ状態チェック

  • Salesforce オプティマイザー
image.png

セキュリティリスクの把握

セキュリティリスクの分析を、よりインタラクティブで実用的な形で実施


組織の使用状況の把握

どのようなロール、プロファイル、権限セットが使用されているか、また誰が管理者権限を持っているかを特定


ユーザ管理の最大効率化

ユーザーのログイン行動を確認し、使用されていないフィールド、ページ、レコードタイプを把握することができます。

参考資料:Salesforce Optimizer を使用した実装の改善

  • セキュリティセンター
image.png

すべての Salesforce 組織とテナントのセキュリティ、プライバシー、およびガバナンスの状態をまとめて確認できます。このアプリケーションを使用すると、最新の健康チェックスコア、アクセス設定、ユーザおよびログイン総計値を 1 つの読みやすいインターフェースで確認できます。

参考資料:セキュリティセンターを使用したセキュリティ目標の管理

開発環境と本番環境への展開について

Sandbox利用方針

Salesforceでは、開発、テスト等、さまざまな目的で利用できるSandboxが用意されています

Sandboxは本番環境、または、別のSandboxのコピーであり、本番環境とは完全に独立している為、Sandbox で実行する操作が本番環境に影響することはない。

ストレージ、データのコピー有無が異なる以下4種類のSandboxが用意されている為、モックアップ、開発、各種テストなど各組織において目的に沿ったSandboxを利用します。

Sandboxは本番環境をコピーして作成、及び、既存のSandboxをコピーして作成することが可能

作成元を既存のSandboxとすることで、開発中の資産、設定を簡単にコピーできる為、互いに干渉しない複数環境で開発、テストを実施可能

image.png
image.png

バージョンアップ時のテスト

Salesforceでは、年3回のバージョンアップのおよそ1ヶ月前から新バージョンのリリースプレビュー期間が用意されており、Sandbox単位にリリースプレビューへの参加/不参加の選択が可能です。

プレビューへの参加/不参加はSandboxのインスタンスで決定される為、Salesforceから公開されるプレビューのお知らせを確認し、インスタンス単位で参加/不参加に応じたアクション(Sandboxリフレッシュ)を実施します。

  • Sandboxプレビューの参加:プレビュー期間開始から新バージョンが適用され、新機能の確認、新バージョンでの既存機能の確認が可能
  • Sandboxプレビューの不参加:プレビュー期間開始以降も正式バージョンアップ日付まで現バージョンのまま

リリースプレビューに参加するSandboxを用意し、本番環境へのリリース済み機能、及び、開発中でリリース予定の機能についてバージョンアップの影響確認を実施します。

Salesforceの開発ではバージョンアップ打鍵を行うことを運用工数として見込んでおく必要があります

  • 本番環境リリース済み機能:新バージョンでの影響確認テストを実施
  • 開発中でバージョンアップ前に本番環境リリース予定機能:現バージョンでのテスト、及び、新バージョンでの影響確認テストを実施
  • 開発中でバージョンアップ後に本番環境リリース予定機能:新バージョンでの影響確認テストを実施
スクリーンショット 2021-08-18 18.44.59.png

構成管理/デプロイ

Sandbox間、Sandboxから本番環境での開発資産の移行については、下記の移行方法があり、各組織ごと定められた移行方法を利用して資産のデプロイを行います。

  • 変更セット:Salesforce画面からリリースする資源、及び、リリース先の環境(Sandbox、本番環境)を選択してリリースする方法
  • Ant移行ツール:リリース元環境からリリースする資源をローカルに抽出し、ローカルからリリース先環境に資源をデプロイする方法
  • Salesforce DX:開発者はスクラッチ組織(※)を利用して開発を行い、スクラッチ組織からSandbox、Sandboxから本番はコマンド(Salesforce CLI)を利用してリリースする方法

(※)開発者が使い捨ての組織を作成可能

オブジェクト、Apexクラス等、メタデータ取得が可能な開発資源については上記デプロイによる移行を行い、プロファイルの権限設定や、機能の有効化設定等、デプロイによる移行ができないものについては設定手順書を用意し、移行先環境で直接設定を行います。

AppExchangeのパッケージについては、Sandbox用インストールURL、本番環境用インストールURLから、Sandbox、本番環境それぞれにパッケージをインストールします。

参考情報:

Sandbox からの機能強化のリリース

更新後の Sandbox およびメジャーリリースバージョン

Appendix

参考ドキュメント

Salesforceドキュメントホーム

Trailhead (学習用コンテンツ)

開発

2021.11.08

Share:

次の記事「Salesforce設計/構築基本ガイド(前編)」

このカテゴリの人気記事

Salesforceについてもっと学ぶ

Salesforce活用に役立つメルマガ登録

システム管理者のみなさまにおすすめの活用ウェブセミナーや、Salesforceでビジネスを推進いただくために有益なコンテンツを毎月お届けします。

Follow us!

Twitter公式アカウント

Salesforce活用に役立つメルマガ登録(毎月配信)

  • 私は、個人情報保護基本方針プライバシーに関する声明個人情報利用についての通知に同意します。 特に、プライバシーに関する声明で定めるとおり、情報のホスティングと処理を目的として私の個人データをアメリカ合衆国を含む国外に転送することを許可します。詳細私は、海外では日本の法律と同等のデータ保護法が整備されていない可能性があることも理解しています。詳細はこちらでご確認ください

  • 私は、Salesforce の製品、サービス、イベントに関するマーケティング情報の受け取りを希望します。私は、当該マーケティング情報の受け取りを私がいつでも停止できることを理解しています。