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

開発

2021.11.08

Share:

はじめに

本書の目的

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

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

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

対象読者とフェーズ

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

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

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

システム開発の指針

基本指針

Salesforce製品を用いたシステムの導入に当たり、以下のような基本指針を取ることが望ましいと考えます。

  • パッケージ標準機能の活用を前提として要件定義/設計/開発を行う
  • 周辺プラットフォームやツールについても、広く一般に利用されている組み合わせを活用する
  • オンラインでの利用(ブラウザやモバイルアプリなどを用いたリアルタイム処理)を基本とし、カスタム開発のバッチデータ処理の利用を極力避ける(どうしても必要な場合は、周辺プラットフォームにオフロードすることを検討する)
  • 周辺システムとの連携に関しては、要件を確認した上で適切な方式を選択する

Salesforceの特徴

  • Salesforce は SaaS パッケージですが、その標準機能はフレームワーク(Lightning Platform)上に構築されています
    • データ項目を作成・変更したり、データを操作する画面を作成する・レイアウトを設定するといった機能が、フレームワークとして提供されている(設定画面から実施可能)
  • 標準機能を利用することで、システムを迅速に構築し、保守対象も減らすことができます
    • 画面のLook&Feel等(列幅、フォントサイズ、色、アイコン、部品の挙動など)は規定されており、基本的にはこのLook&Feelに合わせたUIを検討する
    • 画面のレイアウトパターンは、用意されているものから選択する
    • バージョンアップによりメニュー項目等が追加される場合がある
  • 標準機能で対応ができない部分に関しては、フレームワーク上でカスタム開発(コーディング)を行うことも可能です
    • Java/SQLに類似した独自言語や、HTML/JavaScriptなどを使用し、標準機能にない画面やロジックを作成可能
    • 便利な反面、フレームワークとしての制約や、マルチテナントによる制約(ガバナ制限など)の考慮が必要

image.png

image.png

Salesforce標準機能の活用

  • 画面 (UI) には、現在主流かつ拡張が行われている Lightning Experience (LEX) 利用を前提として検討します
    (LightningとClassicの機能比較に関しては、こちらの
    ページを参照)

  • パッケージを利用するメリットを引き出すため、標準機能で実現できることを理解し、うまく活用(工夫)します
    • グローバルの企業では、標準:8、カスタム:2 の割合が主流。標準で実現できることが増えている
    • 標準機能をベースとすることで、短期間・低コストでの構築の可能性が高まり、年3回のバージョンアップによる機能拡張の恩恵も受けやすくなる
    • 現行システムをSalesforceに移行する場合、機能・画面の単純移行を前提とするのではなく、代わりに実現したい業務や業務シーン・効果に立ち返って、標準機能を用いて実現する方法を検討する
    • カスタム開発する場合も、全部ではなく必要な部分(画面コンポーネントの一部など)だけに留めるよう検討する
    • ロジックの実装について、宣言的開発機能(ノンコーディング; ワークフロー、プロセスビルダー、フローなど)の活用も検討する

Salesforce標準機能のイメージ

image.png

Salesforce製品の適用分野

Salesforceの全体概要

Salesforceは、データベース、ワークフロー、セキュリティ、モバイルやAI等のアプリケーション基盤としてのプラットフォームと、プラットフォームの上に成り立つ顧客管理、サービス、マーケティング等のビジネスソリューションで構成されます。

image.png

Salesforce製品には顧客管理を中心とした業務パッケージと、汎用のプラットフォーム製品があり、実現したい業務に基づき選択します

image.png
スクリーンショット 2021-08-17 14.32.38.png

Salesforceのエディションについて

Salesforceのいくつかの製品は、それぞれが特定のビジネスニーズに合わせて調整された機能とサービスのバンドルとして「エディション」という形で提供されます。

デザインは同じですが、機能と価格はそれぞれ異なります。最初は基本的なエディションを使用し、ビジネスの要求が進化するのに合わせて、より機能が豊富なエディションにアップグレードするお客様もいます。

特に使用できる機能やリソースの制限が異なるため、構築するシステムの特性に合わせて適切なエディションを選択する必要があります。また、このエディションは「組織」ごとに統一する必要があります。

以下は、提供されている各エディションの概要です。

image.png

参考リンク

Salesforce利用に際する一般的な考慮事項

パフォーマンスチューニング

SalesforceのデータベースはSaaSの特性上、プラットフォームの一部としてSalesforce社により管理されるため、お客様が直接チューニングすることはできません。

SOQLクエリの最適化、スキニーテーブルの使用等アプリケーションレベルでのチューニングが可能な部分もあるが、限界もあるため、特に大規模システムを構築する場合は、過去の事例の確認や、必要に応じてプロトタイプなどによりパフォーマンスを評価し、その結果を受けて本格開発するような開発計画を立てることが望ましいと考えます。

パフォーマンス検証を実施する場合は、検証環境構築の時間(大規模なデータ(数十万件から数百万件以上のデータ)をロードする時間など)も必要となるため、検証期間にも注意が必要です。

ピーク性

短時間に大量トランザクションを処理するような業務は、Salesforceの制限に抵触する可能性もあるため、事前にSalesforce社もしくは認定コンサルタントなどに相談をするとともに、POC(Proof of Concept)などを実施した上で本格開発するなどの計画を建てる必要があります。

バッチ処理

Salesforceは、オンライン処理・リアルタイム処理指向であるため、前提としてバッチ処理は最小化する方向で検討します。

バッチ処理は、Salesforce内で実装するのではなく、Heroku、もしくは外部システムにアウトソースする方式を考えます。

その際、プロトタイプでパフォーマンスを評価し、その結果を受けて本格開発するような開発計画にします。

ネットワーク

社内から使用する場合は、社内ネットワークとインターネット回線の接続部分(ゲートウェイ部分)にトラフィックが集中する可能性があります。データサイズやトラフィック量が運用費増につながる可能性もあるため、十分に回線容量などを精査する必要があります。

一般的なページの遷移の場合は大きな帯域は必要ありませんが、ファイル添付や動画ストリーミング等が必要な場合は特に注意をして下さい。

回線環境増強の必要がある場合は、コストと増設完了までの作業期間を考慮し検討をします。コスト効果に見合わない場合は、実現機能の選定を行います。

参考情報: Salesforce の帯域要件

メール一斉配信

Salesforceのメール発信機能は、一括発信通数に制限があるため留意が必要です。

大量のメール配信が必要な場合は、メール配信機能を提供するAppExchangeや、Markrting Cloud等の利用も検討して下さい。

参考情報: メールの制限の種類についての概要

可用性レベル

ネットワークサービスや、Salesforceデータセンター側での障害発生のリスクも想定されるため、障害発生時のSalesforceに対するサポートリクエストの起票、サポート処理中の体制、社内外コミュニケーションについての運用ルールの策定を検討します。

なお、業務停止が許容されないシステムの場合、障害発生時の業務継続手段(バックアップシステムの準備、運用手順等)の検討を計画に盛り込みます。

利用ユーザー

利用者が、社員か外部ユーザ(代理店やお客様等)かにより、利用するライセンスや情報のアクセス範囲が異なります。

特に、ポータル等で外部ユーザに情報提供をする場合は、導入者が利用機能や情報へのアクセス権を的確に設計/設定を行う必要があります。

参考情報: ゲストユーザセキュリティポリシーのベストプラクティス

ユーザ認証

お客様にて定義されている、ユーザ認証の要件に従い設計/設定を行います。

また、Salesforce社は、セキュリティの向上のために「多要素認証 (MFA)」の利用を推奨しているため、この採用を検討します。

認証手法の詳細は、後項の「設計/開発ガイド概要」を参照してください。

参考情報: ユーザの認証(Salesforce セキュリティガイド)

ログ

標準機能は、Salesforce側で取得するログ(ログイン履歴、設定変更履歴、項目履歴)に依存します。高度なログ取得が必要な場合は、イベントモニタリング機能(有償)の導入を検討します。

なお、Salesforceで記録されるログは、ログの保存期間制限があるため、ログファイルのエクスポートを実施する必要があります。

APEX等の言語を利用して個別開発した機能は、必要に応じて個別にログ取得する機能を実装することも検討します。

特に個人情報を扱う場合は、漏えいが発生した際、証跡を追跡できるログを個別にとることも検討をして下さい。

サービスの停止

Salesforce社によるメジャーリリース、及びメンテナンス実施のため、数分から1時間程度の利用制限(読み取り専用状態、またはサービス停止)が発生する場合があります。メンテナンスの実施は、事前に管理者に通知され、またメンテナンスの実行は、土曜深夜(土曜深夜~日曜早朝)が中心ですが、システム障害などにより利用者のサービス時間内の停止も考えられるため、業務停止が許容されないシステムの場合、障害発生時の業務継続手段(バックアップシステムの準備、運用手順等)の検討を計画に盛り込む必要があります。

参考情報: 稼働ステータス及びメンテナンス計画の確認

データのバックアップ・リカバリ

Salesforceは基盤として、データの二重化、災害対策を実施済みであるため、利用者側でデータ損失への考慮は必要としません。

ただし利用者が、業務上のオペレーションミスからのリカバリ、時間を指定したデータリストア等、個別の要件がある場合、データのバックアップを検討します。

また、オペレーションミスによるデータ削除に対するリカバリは、Salesforceの「ごみ箱機能」で対処することも可能ですが、個々のユーザーからのごみ箱閲覧ができないケースも有るため、必要な場合はデータのバックアップを検討します。

参考情報: バックアップとリストア(サクセスナビ) /  Salesforce データのバックアップのベストプラクティス

クライアント環境に関する考慮

Salesforceでサポートされるブラウザ及びバージョンについては、下記情報を参照し、現環境との差異の有無を確認します

参考情報:サポートされるブラウザおよびデバイス

AppExchangeを使用する際の考慮

AppExchangeによりSalesforce機能を容易に拡張することが可能ですが、採用する際は、導入コスト/スケジュール、運用(バージョンアップ、サポート体制/期間)を考慮し、使用可否の検討を行います。

データ量/ファイル量

Salesforceのデータ量/ファイル量は契約により決まっており、契約以上のデータ/ファイルを保存すると費用が発生します。契約時に使用する量を算出する必要があります。

参考情報:

データストレージとファイルストレージの割り当て

Salesforce レコードサイズの概要

Salesforce設計/開発のアプローチと役割分担

設計/開発のアプローチ

設計/開発のアプローチは各プロジェクトでの検討となりますが、Salesforceの特性を考慮した基本的な設計/開発の流れ(全体像)は以下の通りとなります

image.png

要件定義フェーズのポイント:  モックアップの活用

Salesforce では、データ項目や標準画面の作成を設定画面から容易に実施することができます。

Salesforceのメリットを引き出すためには、標準機能・標準画面を最大限利用することを前提とした要件定義を行う必要があります。

そのため要件定義フェーズでは、標準機能・標準画面を利用したモックアップ(動作するサンプル)を作成し、これを中心に関係者間での認識合わせを実施します。(これは、ビジネスフローをインプットとした、システムフロー(画面フロー)の作成に相当します)

モックアップ利用のメリット

  • 画面設計書をもとに会話するより、画面の挙動や見た目も含めて早い段階でのすり合わせや修正が可能で、ドキュメントの作成・管理に関わるコストの低減にもつながる
  • 実際に動作する画面を見ながら検討をすすめることにより、操作しないと気がつかない部分についてもフィードバックが得られる
  • 要件によってはカスタム開発が適切な場合もあるが、その際も必要な部分にのみ留めることができるように、標準画面との連動方法について認識合わせをすることができる(標準画面からの遷移方法や、コンポーネントとして画面レイアウトにどう埋め込むかなど)

なお、バッチ処理や他システム連携等は通常のシステム開発と同様、ドキュメントによる認識合わせを行います。

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

要件定義フェーズでの役割分担の例

要件定義フェーズでの発注側・提供者(SIer)側の役割分担については、下記を参考に調整します。

A
B
C
D
1タスク
発注者側の主な役割
提供者(SIer)側の主な役割
注意点・備考
2画面定義
・各画面で実現したいことの明確化
・ビジネスフローとの整合確認
・利用ユーザへの確認

・画面内容・画面遷移の検討
・標準/カスタムの検討
・モックアップ作成

標準及び、マウスによる
ポイント & クリックの範囲で実現する方法を考え、それが難しい場合にのみカスタム開発を検討する

3オブジェクト(データモデル)設計
・概要/制約の理解
・オブジェクト/データモデルの設計
・レポート等機能への影響の整理

大量データや各標準オブジェクト固有の挙動を考慮して設計
4項目定義
・業務に必要なデータ項目の検討
・データ項目の作成・詳細化
・非正規化や数式、項目自動更新処理の検討


5データアクセス設計
・データアクセス要件の検討
・データアクセス権によるユーザのオペレーションへの影響の理解・ユーザ調整

・データアクセスの設計、方式検討
・オペレーションへの影響の整理

性能および運用負荷の検討が必要(人事異動に伴うメンテナンス等)
6業務ロジック定義
・業務ルール(契機・実現したいこと)の検討
・実装方式の検討
実装方式が複数る場合、使い分けの検討が必要
7カスタム開発機能 /
インテグレーション設計

・概要の理解
・カスタム開発機能/インテグレーションの洗い出し・設計

8リストビュー/ レポート定義
・オペレーションに必要なリストビュー/レポート内容の検討(項目・条件・利用者など)および作成
・アクセス権等の設定
・性能や制約など技術観点でのフォローアップ、対応策検討

表示用項目の作成、集計処理の作成等の検討が必要な場合あり
9非機能要件定義
・非機能要件の理解・承認(サービス停止時間、セキュリティなど)
・画面応答性能などユーザへの確認

・非機能要件の定義(認証方式も含む)
特に既存システムからの移行では差異があるため早めに合意が必要

カスタム開発の実施判断について

要件定義フェーズでは、必要な機能の洗い出しとともに、これを標準機能で実現するか、カスタム開発するかの判断を行います。(カスタム開発する場合、標準機能利用と異なるプロジェクトタスクを実施することとなり、必要な人員・スキルセットも変わるため、早い段階での判断が望ましい)

カスタム開発の実施判断にあたっては、以下の観点について関係各社間で認識合わせすることが望ましいと考えます。

  • 標準機能のギャップ内容(標準機能だけでは実現できない、操作が煩雑になる、など)
    仮に標準機能で対応できない場合も、運用や業務プロセスの変更で対応できるかどうかを検討する

  • ビジネス効果(ビジネスフロー上必須かどうか、カスタム開発機能によって生み出される価値、など)
  • 将来発生しうるリスク(バージョンアップによる機能拡張の恩恵が受けられない場合がある、など)
  • 設計/開発コストと期間
  • 保守/運用コスト(製品バージョンアップ時のリグレッションテスト対応など)

標準機能、標準機能設定(宣言的開発)、カスタム開発(コーディング)の定義は以下のとおり

(システム連携インタフェースは除く。目安としては全体の7割〜8割は標準機能・標準機能設定で実現可能)

※標準機能設定(宣言的開発)は、「ポイント & クリック操作によるカスタマイズ」と表現されることもあります

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

ディシジョンツリーの例

実装方針を決める際の条件を、プロジェクト内で事前に整理しておきます。
以下に、デシジョンツリーのサンプルを示します。

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

各フェーズの作成ドキュメント

作成するドキュメントについては、各プロジェクトでの設計/開発アプローチの中で検討となるが、以下のような事項を考慮します

  • 設計内容の依拠(業務の前提や設計選択理由など)を記載する。採用しなかった選択肢とその理由もできるだけ記載する。
  • Q&Aもプロジェクト成果物として残しておく
  • 標準機能を利用する部分について記載する場合、保守性・効率性の観点から、設定した内容とその理由を記載するまでにとどめる
  • 作成予定のドキュメントと内容・記述レベル・利用方法について、あらかじめ発注者側と合意しておく(Q/C/Dに影響するため)

作成ドキュメント例

image.png

凡例: ◯:作成/△:一部作成/×:作成しない

外部パートナー選定方針

以下のSalesforce社の公開情報等を参考に、Salesforce開発関連作業を委託できそうなパートナー候補を抽出します。



組織(Org)の検討

組織の利用方法

Salesforce組織(Org)とは?

  • Salesforceはマルチテナント方式となっており、各テナント環境を組織(Org)と呼んでいる。
  • 組織(Org)は、ユーザー、ライセンス、アプリケーション(データ、ロジック、画面)、運用の管理単位となる
  • 組織(Org)に対してユーザを作成(ユーザライセンス割当)、データ/ロジック/画面を構築し利用する
  • 組織(Org)の中に複数のアプリケーションを構築可能 (ユーザ/データ/ロジック/画面を共用可能)

すでにSalesforceを導入済みで、新規にSalesforceのアプリケーションを構築する場合、既存の組織上に統合(相乗り)するか、新規に組織を作成するかを検討する必要があります。これは、プロジェクト計画〜要件定義フェーズに置いて方針を決定します。

シングル組織/マルチ組織の検討アプローチ

シングル組織とマルチ組織のイメージ

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

シングル組織/マルチ組織の利点と課題


組織
利点
課題

シングル組織
・部門間のコラボレーション向上(クロスセル/アップセル/均一された顧客対応)
・共通のビジネスプロセスの共有による生産性向上
・必要に応じてデータ共有が可能
・統一されたレポーティング
・全社リアルタイムコラボレーションの実現
・ユーザIDの一元化(Single login)
・システム管理・サポート業務の効率化

・イノベーションの遅延。複雑な構成の組織は、設定・テスト等に手間がかかる場合がある
・複数のチームが、同時に新しい機能を開発する場合、整合性をチーム間で調整する必要があり、利用開始までに時間がかかる可能性がある
・組織の利用制限(ガバナ等)に抵触する可能性
・運用していくためのルールと仕組み作りが必要


マルチ組織
・事業の独立性、組織設定の管理しやすさ
・複雑性の緩和、テスト負荷の軽減
・利用開始までの時間短縮と自律性、早い対応
・セキュリティ(法令対応など)
・組織の制限(ガバナ等)に抵触する可能性は低い

・全社でのプロセス明確化が困難
・設定やコードの再利用が最小化
・部門間のコラボレーションが低下
・階層を利用したレポーティングが難しい
・データ・アーキテクチャ/マネジメントがさらに複雑化
・組織単位にシステム管理者が必要
・シングル・サインオンの複雑性の増加

考慮すべきポイント


分類
シングル組織
マルチ組織

システム管理
- 可視性

システム管理者は、自身が担当していない他部門の設定情報やデータも見ることができる。

誤って他部門の設定を変更してしまうリスクがある。

プロファイルやページレイアウトが多くなりすぎて、管理の複雑になる可能性がある。

システム管理者は、自身が担当している組織の設定情報のみ見ることができる。

変更管理のスコープも自身が担当している組織のみでよい。


システム管理
- 影響

1つの設定変更により、すべての部門の業務に影響が出る可能性がある。
多くの設定変更を加えたとしても、自身が担当している組織にしか影響はない。例えばタブ名、項目名、カスタムオブジェクトなど。

組織単位で有効/無効を制御する機能を、各組織の判断で選択できる。


システム管理
- AppExchange

パッケージを1度インストールするだけで、プロファイル設定に従って各ユーザが利用可能になる。
AppExchangeは各組織にインストールする必要があるため、同じパッケージを複数組織で利用する場合は手間がかかる。

有償アプリの場合、組織ごとに課金される可能性がある。


システム管理
- 変更管理

大企業における単一組織では、各地域のシステム管理者と協働するために、入念に定義された変更管理プロセスが必要となる。
複数組織に対して同じ設定変更を行う可能性も考慮に入れた変更管理手順が必要。

システム管理者は自身が担当していない組織にはログインしないため、その点も考慮に入れる。


メンテナンス時間
対象組織を複数の国から利用している場合は、年3回バージョンアップのメンテナンス時間を考慮する必要がある。
例えば日本用のインスタンスで運用した場合、日本時間の日曜深夜=アメリカでは土曜の日中となり、その時間帯はSalesforceにアクセスできなくなる。
※実停止時間は最大5分間程度。

各地域(国)毎に最適な国に組織を配置することで、各地域に考慮した時間帯にメンテナンスが実施される。

顧客の360°ビュー
他部門の顧客に関する過去のやりとりを共有できるので、スムーズなケース対応を実施したり、営業部門と共有してクロスセルやアップセルにつなげることも可能。

他部門に共有したくない情報がある場合、データアクセスコントロールの設定に注意を払う必要がある。

とある顧客を複数地域で担当している場合、顧客データが複数組織に分散するため一元管理を行うのが難しい。

複数組織間でデータを同期させる運用も考えられるが、このプロセスを維持するのは難しい。


レポート &
ダッシュボード

グローバル各拠点のデータを統合的にレポーティング可能。

目安として、1オブジェクトあたり100万件を超えてくるとレポートの実行時間に影響が出る可能性がある。
(データ特性や抽出条件の設定により、影響の大きさは異なる)

データ連携を行わない場合、自身の組織に関するデータしかレポーティングできない。

Salesforce Connectを利用して組織間でデータを連携したり、ETLツールなどを利用し、1つの組織にグローバルのデータを集約してレポーティングすることは可能。

Tableau / Tableau CRM等にデータ連携をして、その環境で分析を行うという選択肢もある。


セキュリティ
とある顧客を担当するグローバルのユーザが多くなりすぎた場合、データアクセスコントロールが複雑になる可能性がある。
各組織ごとにデータアクセスコントロールを定義する必要がある。

とある顧客の他部門の過去のやりとりを参照するために、1人のユーザが複数IDを持つ運用が考えられる。


データ量
1つの組織にグローバルの全データが集約されるので、大量ボリュームになる可能性がある。

ストレージは追加購入可能。

各組織にデータが分散するので管理しやすい。

リリース
部門ごとに注意を払う必要があるため、リリースや展開に関する管理がやや複雑。

同様の理由により、リリースまでのスピードもやや遅くなる。

リリースや展開に関する管理が容易。

リリースまでのスピードが速い。


Chatterによる組織間(部門間)コラボレーション
標準機能
組織間での情報統合をしないと使えない

参考:組織の利用状況の確認方法

Salesforce管理画面による確認

組織情報の確認

  • 調査対象の組織にシステム管理者でログインする
  • クイック検索に「組織情報」と入力する
スクリーンショット 2021-08-18 12.59.41.png

システムの概要情報の確認

  • 調査対象の組織にシステム管理者でログインする
  • クイック検索に「システムの概要」と入力する
スクリーンショット 2021-08-18 13.05.02.png

Salesforce CLIによる確認

  • 該当組織にログインする [sfdx force:auth:web:login ]
  • ブラウザーの認証画面が表示される。
    調査対象の組織のログインを行う。

  • 組織の利用状況を表示するコマンドを実行 [sfdx force:limits:api:display –u 管理者のユーザーID ]
  • REMAININGの数値を確認し残容量を把握を行う
スクリーンショット 2021-08-18 13.09.43.png

※本操作は、操作端末にSalesforce CLIのインストールが必要。
インストールモジュールは、下記URLから入手可能

Salesforce組織間の連携

主要な連携パターンを以下に示します。

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

開発

2021.11.08

Share:

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

次の記事「Salesforce運用基本ガイド」

このカテゴリの人気記事

Salesforceについてもっと学ぶ

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

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

Follow us!

Twitter公式アカウント

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

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

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