Mark Hammer's Blog

SalesforceやTrailheadに関する情報を投稿しているブログです。

SalesforceでログインをSSOに限定する方法

はじめに

Salesforceは通常ログイン画面でユーザ名・パスワードを入力してログインしますが、SSOログインも利用可能です。
また、ログイン方法をSSOのみに制限する方法もヘルプで公開しています。
Salesforce Help: SSO を使用したログインをユーザに要求

このヘルプの内容によると、ログイン方法をSSOのみに制限するには以下3点の設定が必要とのことです。

  • 私のドメイン設定にて [ https://login.salesforce.com からログインできないようにする ] を有効にする
  • シングルサインオン設定にて [Salesforce ログイン情報を使用したログインを無効化] を有効にする
  • ユーザプロファイルか権限セットで、ユーザに [シングルサインオンの有効] 権限を付与する

これを見たとき、こんな疑問を浮かべました。
「組織全体に影響するシングルサインオン設定でSalesforce ログイン情報を使用したログインを無効化して、ユーザに [シングルサインオンの有効] 権限を与える…。
これ [シングルサインオンの有効] 権限与えないとSalesforceにログインできなくなるのでは?」
ということで、検証してみました。

検証

まず、SSOログインが可能な環境を作成し、シングルサインオン設定にて [Salesforce ログイン情報を使用したログインを無効化] を有効にします。
その時の動作は以下の通りです。

  • SSOログイン:可能
  • ユーザ名・パスワードでのログイン:可能

f:id:mark-hammer:20211121034055p:plain
[Salesforce ログイン情報を使用したログインを無効化] を有効にした時のログイン履歴

次にユーザプロファイルにて、 [Salesforce ログイン情報を使用したログインを無効化] を有効にした際に表示される [シングルサインオンの有効] 権限を付与します。
その時の動作は以下の通りです。

  • SSOログイン:可能
  • ユーザ名・パスワードでのログイン:「このシングルサインオンゲートウェイ URL は無効です」エラー

f:id:mark-hammer:20211121034737p:plain
[シングルサインオンの有効] 権限を付与した時のログイン履歴

なお、 [シングルサインオンの有効] 権限を付与した場合APIログインもSSOを介さないとログインできなくなります。(ユーザ名・パスワードでのログインだと「このシングルサインオンゲートウェイ URL は無効です」エラー)

おわりに

[Salesforce ログイン情報を使用したログインを無効化] の名前だけ聞くとこの設定を有効にした時点で組織全体がSSOログイン以外無効化するように見えますが、実際はSSOログインに制限するためのユーザ権限である [シングルサインオンの有効] 権限を表示するためのものでした。
また、 [シングルサインオンの有効] 権限の名前だけだと「SSOログインができるようになるために必要な権限」と思われますが、実際には「SSOログインに限定するための権限」でした。
[シングルサインオンの有効] 権限の英語名は "Is Single Sign-On Enabled" ですので、日本語訳としては合っています。
ただ、(もう少し実際の動作に沿った権限名にしてほしかったなぁ…)と思った一件でした。

MFA FAQでは「システム管理者へのSSOログイン有効化はお勧めしません」とされていますが、仮にSSOを使用する場合、 [シングルサインオンの有効] 権限によるSSOログイン限定をシステム管理者のみ外す、という方法はありかな、と思いました。

Salesforce制限拡張、機能有効化のヘルプ一覧

はじめに

Salesforce Helpの中に、英語版のみではありますが制限拡張、機能有効化に関するヘルプ一覧がまとめられたページを発見しました。

Salesforce Help: Common Feature Activation and Limit Change requests

以下、上記ヘルプのリストを依頼方法に沿ってリスト化した制限拡張、機能有効化の一覧となります。
(日本語版が存在するヘルプは日本語版を、存在しないヘルプは英語版が表示されるようリンクを設定しています。)

制限拡張

Salesforceサポートへの問い合わせが必要なもの

拡張が有償、または担当営業(AE)に依頼するもの

拡張できないもの

機能有効化

Salesforceサポートへの問い合わせが必要なもの

有効化が有償、または担当営業(AE)に依頼するもの

有効化がユーザで可能なもの

依頼方法について

上記制限拡張、機能有効化を依頼する際、Salesforceサポートは以下の情報を要求します。

  • 依頼者がシステム管理者(「すべてのデータの編集」、「アプリケーションのカスタマイズ」両方の権限を持つユーザ)であること
    • 依頼ケースに依頼者のユーザ名を記載します。
  • 組織ID(本番、Sandbox)
  • 申請の理由

その他、申請内容によっては別途必要事項を記載する必要がありますので、事前に上記ヘルプを参照することをお勧めします。

*1:Winter '15 より前に Salesforce の使用を開始した場合はサポート問い合わせ

Salesforce DX CLI で脆弱性とされた機能の紹介と対応策

はじめに

2021/10/4に、CERT/CCよりSalesforce DX CLIについてアクセス制限不備の問題が指摘されました。

jvn.jp

www.security-next.com

これに対し、Salesforceでは Salesforce ヘルプ: Salesforce Developer Experience Command Line Interface の設定 を公開しましたが、具体性がなく何が起きているのか分からない内容となっています。

ここでは、実際にどのような操作が問題なのか、また対応策について書いていきます。

注意事項

筆者は普段Salesforce DX CLIを使っておらず、一部憶測を含む部分があります。
本投稿の内容を試した際など、掲載内容からいかなる損失や損害などの被害が発生したとしても、当ブログでは責任を負いません。(サイトポリシーの免責事項もお読みください。)

問題となる事象と再現方法

Salesforce DX CLI には、登録した組織・ユーザにコマンド1つでログインできる機能があるのですが、そのコマンドを実行した際にそのユーザとして組織にログインできるURLが出力されます。
これが今回問題となった機能と思われます。

再現方法

  • Salesforce DX CLI をインストールする。
    • インストール方法はこちらを参照してください。
  • sfdx force:auth:web:login を実行し、ブラウザ画面からSalesforceにログインする。これにより Salesforce DX CLI 側に組織、ユーザ情報が登録される。
  • sfdx force:org:open を実行する。これにより sfdx force:auth:web:login コマンドでログインしたユーザと同じユーザでログインした状態でブラウザが起動すると同時に、そのユーザとして組織にログインできるURLが出力される。

実際のコマンド実行と出力内容の例です。

> sfdx force:auth:web:login -a test
# このコマンド実行後、Salesforceログイン画面が表示された状態でブラウザが起動する。
# この画面でログインすることで Salesforce DX CLI 側に組織、ユーザ情報が登録される。

> sfdx force:org:list
=== Orgs
  ALIAS  USERNAME             ORG ID              CONNECTED STATUS
  ─────  ───────────────────  ──────────────────  ─────────────────────
  test   test@sampleorg.com   00DxxYYYYYzzzzzAAA  Connected
# force:auth:web:login でログインした情報が表示される

> sfdx force:org:open -u test
WARNING: This command will expose sensitive information that allows 
for subsequent activity using your current authenticated session.
Sharing this information is equivalent to logging someone in under the 
current credential, resulting in unintended access and escalation of privilege.
For additional information, please review the authorization section of the 
https://developer.salesforce.com/docs/atlas.en-us.234.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_web_flow.htm

Access org 00DxxYYYYYzzzzzAAA as user test@sampleorg.com with the following 
URL: https://mysampledomain.my.salesforce.com/secur/frontdoor.jsp?sid=00DxxYYYYYzzzzz!heersgKJolaf0kq3rLMODASA...
Waiting to resolve the Lightning Experience-enabled custom domain...... done

上記コマンドの https://mysampledomain.my.salesforce.com/secur/frontdoor.jsp?sid=00DxxYYYYYzzzzz!heersgKJolaf0kq3rLMODASA... が「そのユーザとして組織にログインできるURL」です。
上記URLの sid はセッションIDを指すと思われます。つまりこのURLを悪用すればセッションハイジャックができてしまうということです。

cybersecurity-jp.com

なぜURLを出力しているのか

Salesforce DX CLI では、スクラッチ組織という開発者が開発のために作ることができる組織があります。(Developer Edition組織とは別です。)

trailhead.salesforce.com

この「スクラッチ組織を使って開発する」ことを考えたときに、複数人でチームとして開発しており、開発の内容をチーム内で確認してもらいたいときは「スクラッチ組織に開発者全員のユーザアカウントを作成してアクセスしてもらう」よりも「システム管理者としてログインできるURLを発行してそれをチーム内に連携する」方が便利です。
(「スクラッチ組織を作成→その組織にログイン」の流れが force:org:createforce:org:open とコマンドで完結し、ログイン画面を介さないため「ユーザ名とパスワードを連携する」という方法も不便になってしまう。)

よって、Salesforceとしてはこの機能は開発用に用意したものであり、本番環境はセッションハイジャックを防ぐためにセッション設定を用意しているのでそれを適用するように、というのが見解だと思われます。

対策方法

発行されたURLはログイン済のセッションを用いているため、ユーザ名、パスワードはもちろん多要素認証を必須にしていたとしても多要素認証の情報なしにログイン後の画面にアクセスできてしまいます。
さらに、ログイン履歴にもこのURLを用いたアクセスは記録されません。(アクセス後にレコードを参照すると、「最近参照したレコード」として記録はされます。)

発行されたURLからの外部アクセスを防ぐためには「セッションの設定」にて防止用の設定を導入する必要があります。 具体的には以下2点です。

ログイン時の IP アドレスとセッションをロックする

これはログイン時のIPアドレスとログイン後のIPアドレスが変わった場合にそのセッションを切断し、再度ログインを要求する機能です。
これにより、 Salesforce DX CLI で発行されたIDに外部からアクセスしようとしてもログイン画面に戻されます。
ただし、「ログイン時の IP アドレスとセッションをロックする」を有効にした後のログインが対象となります。有効にする前にログインした際のセッションはこの機能の制限を受けません。

これを有効にするとSalesforceアクセス後に自分の端末のIPアドレスが変わるとログイン画面に戻されることになります。(ノートPCやスマートフォンでは影響があるでしょう。)
また、Salesforceヘルプ: セッションセキュリティ設定の変更 にも「この設定は、さまざまなアプリケーションやモバイルデバイスの機能を妨げる可能性があります。」という注意書きがありますので、安易な設定はお勧めできません。

すべての要求でログイン IP アドレスの制限を適用

これはログイン IP アドレスの制限が設定されているユーザにてログイン後にIPアドレスがログイン IP アドレスの制限の範囲外になった場合、エラーとする機能です。

f:id:mark-hammer:20211104015337p:plain
エラー画面

これも同様に、Salesforce DX CLI で発行されたIDにログイン IP アドレスの制限範囲外となる外部からアクセスしようとしてもエラーになりますが、Salesforceアクセス後に自分の端末のIPアドレスがログイン IP アドレスの制限範囲外になった場合もエラーになります。(ノートPCやスマートフォンで、VPN使用時にVPNが切断された場合などが該当するでしょう。)

備考

ここでは2つの設定を紹介しましたが、いずれにも言える点は「たとえ有効にしたとしてもセッションハイジャックを完全に防ぐことはできない」という点です。
具体的にはどちらの設定もログイン後にIPアドレスが変わったことをトリガとしてエラーとするため、「社内で Salesforce DX CLI により発行されたURLを盗み見てアクセスすればセッションハイジャックできる」といった内部犯行を防げません。(社内のPCに対しグローバルIPアドレスを個別に割り振っているのであればこのような内部犯行は防げますが、そのような会社はごく少数でしょう。)

よって、セッションハイジャックを完全に防ぐ方法として「本番環境では force:org:open を使わない」を提案します。
そもそも force:org:open はスクラッチ組織のためにあるものだと考えれば、ユーザ名、パスワードを入力すればログインできる本番組織には不要とも言えます。
コマンド1つでログイン画面が表示できるのは便利ではありますが、セキュリティを考慮すると本番環境では使わない方がよいと考えます。

おわりに

今回の問題はゲストユーザ問題と同様、責任共有モデルが大きく関わってきます。
つまり「Salesforceはセッションハイジャック防止用の設定を用意しているので、ユーザの責任で導入してください。」というものです。
しかし先述の通りアクセス元IPアドレスが変わらない状況にてセッションハイジャックを防ぐ機能がSalesforceにない現状では、片手落ちの印象も受けます。

本件について記載されたヘルプでは「今後、機能拡張があった場合は、この記事を更新します。」とのことですので、何らかの機能拡張があるか注目したいと思います。

Salesforceのリリースバージョン番号

はじめに

今年もDreamforceが終わりました。
Twitterを見てると、今年はワークフローとプロセスビルダーからフローに乗り換えに関する話題で盛り上がりましたね。
約1年後にはワークフローとプロセスビルダーの新規作成を禁止されるとなると結構な重要事項ですが、今回のテーマはそれではありません。

True to the Core オンデマンド録画の25分ごろからその話題になるのですが、ここでスピーカーのPatrick Stokes氏はタイムライン説明の際に "Spring ‘22" といった形ではなく ”Two thirty-six”, "Two thirty-eight", "Two fourty" と話しています。
しかし紹介したブログには、 "Spring ‘22", "Summer'22", "Winter'23" と従来のバージョン名で記載されています。
これはどういったことなのでしょうか。

Salesforceのリリースバージョンには番号がある

実はSalesforceのリリースバージョンには、"Winter'22"のような我々がよく知る「季節+年」の表記以外に数字のバージョン番号も設定されています。
それはSalesforceリリースノートのURLを見れば分かります。

このように、releaseURLパラメータがSummer'21では232、Winter'22では234と2増えています。
このルールは今後のバージョンでも同様ですので、

  • Summer'21: 232
  • Winter'22: 234
  • Spring'22: 236
  • Summer'22: 238
  • Winter'23: 240

となります。
Patrick Stokes氏はバージョンをこの番号で説明しており、それをブログ著者が「季節+年」の表記に書き換えたんですね。

おわりに

通常、Salesforceのバージョンは「季節+年」表記で表されており、一般ユーザがバージョン番号を聞くことは滅多にありません。*1
少なくともDreamforceのこのセッションは一般向けではなかった、ということでしょうか。

releaseURLパラメータはメジャーリリースごとに2増える、と覚えておくと先述のリリースノートのURLパラメータ書き換えだけで希望のリリースノートを見つけることができたりするなど*2、いいことがあるかもしれません。

*1:目にするのはSalesforceアプリのバージョン番号ぐらいでしょうか。それもあまり気にしませんよね。

*2:リリースノート画面にあるバージョン選択リストから選んだ方が早い、と言われるとそうですが…

Trailhead モジュール:Advanced Salesforce Release Readiness Strategies

※この内容は2021/9時点のものです。

Master the Release Readiness Process

https://trailhead.salesforce.com/ja/content/learn/modules/advanced-salesforce-release-readiness-strategies/master-the-release-readiness-process

  • 説明:英語
  • Challenge:英語選択問題

Select and Prioritize Features

https://trailhead.salesforce.com/ja/content/learn/modules/advanced-salesforce-release-readiness-strategies/select-and-prioritize-features

  • 説明:英語
  • Challenge:英語ハンズオン

【Challenge要約】

※筆者注:Challenge前に組織設定にて言語のデフォルト値を「英語」にする必要があります。

  • 以下内容で新規カスタムオブジェクトを作成してください。
    • 表示ラベル:New Feature
    • 表示ラベル(複数形)*1:New Feature
    • オブジェクト名:New_Feature
    • 説明:Object to track and prioritize new features to be deployed
    • タブスタイル:トロフィー
  • 以下内容でNew Featureカスタムオブジェクトに新規カスタム項目を追加してください。
    • 項目の表示ラベル:Feature Area
      • データ型:選択リスト
      • 項目名:Feature_Area
      • 値:Accounts & Contacts, Opportunity, Productivity, Case Management, Knowledge, Tasks & Activities, Email, Calendar, Automation, Reports, Dashboards
    • 項目の表示ラベル:Business Impact
      • データ型:選択リスト
      • 項目名:Business_Impact
      • 値:High, Medium, Low
    • 項目の表示ラベル:Implementation Effort
      • データ型:選択リスト
      • 項目名:Implementation_Effort
      • 値:High, Medium, Low
    • 項目の表示ラベル:Decision Status
      • データ型:選択リスト
      • 項目名:Decision_Status
      • 値:Proposed, Auto-activated, In development, Deployed, Cancelled
    • 項目の表示ラベル:Target Deployment Date
      • データ型:日付
      • 項目名:Target_Deployment_Date
      • ヘルプテキスト:When will this feature be deployed?
  • 以下内容でNew Featureオブジェクトのレコードを作成してください。
    • New Feature名:Flow
    • Feature Area:Productivity
    • Business Impact:High
    • Implementation Effort:High
    • Decision status:Proposed

Test New Features Before a Release

https://trailhead.salesforce.com/ja/content/learn/modules/advanced-salesforce-release-readiness-strategies/test-new-features-before-a-release

  • 説明:英語
  • Challenge:英語選択問題

Communicate New Features to Users

https://trailhead.salesforce.com/ja/content/learn/modules/advanced-salesforce-release-readiness-strategies/communicate-new-features-to-users

  • 説明:英語
  • Challenge:英語選択問題

*1:設定項目の表示には組織設定にて言語のデフォルト値を「英語」にする必要があります

古いAPIバージョンのアクセスを追加費用なしで確認したい

はじめに

Salesforce Platform API バージョンが古いものについて、以下のように順次サポート終了、アクセス不可が予定されています。

こうなると自分の組織に古いAPI バージョンのアクセスがないか気になるところですが、これを確認する方法は現状EventLogしかありません。
しかし、イベントログの開発者ドキュメントには以下の記載があります。

安全でない外部アセットイベント、ログインイベント、ログアウトイベントは、サポートされている Salesforce エディションで追加費用なしで使用できます。残りのイベントタイプを購入するには、Salesforce にお問い合わせください。

APIアクセスイベントは上記でいう「残りのイベントタイプ」になります。 つまりEvent Monitoringライセンスを購入しないと古いAPI バージョンのアクセスがあるかないか分からないのです。

しかし、それでは困るという顧客の声があったのでしょう。
Summer'21リリースにてAPI 合計使用量イベントを使用した API バージョンの使用の追跡というリリースが行われました。

このイベントは、バージョン 30.0 までの SOAP、Bulk v1、および REST API 要求へのコールを記録します。データは 24 時間保持されます。
(中略)
API 合計使用量イベントは、すべての顧客が無料で使用できます。

これにより、追加費用なしでも廃止対象APIバージョンのアクセスを確認することができるようになりました。

試してみた

実際にAPI 合計使用量イベント(ApiTotalUsage)が取得できるか試してみました。

古いAPIバージョンでアクセスする

今回はWorkbenchでアクセスします。

  1. Workbench経由でSalesforceにログインする
  2. 上のメニューから Utilities|REST Explorer をクリック
  3. HTTPメソッドを「GET」、URIを /services/data/v20.0/sobjects/account/describe で指定して[Execute]をクリック

f:id:mark-hammer:20210909020715p:plain
Workbench画面

イベントログを取得する

Workbenchアクセス後、1日待って以下作業を行います。

  1. Salesforce Event Log File Browser経由でSalesforceにログインする
  2. EventTypeを「ApiTotalUsage」と指定して「Apply」をクリック
  3. 結果が表示されればCSVをダウンロード

f:id:mark-hammer:20210909020852p:plain
Salesforce Event Log File Browser画面

実際の結果はこうなりました。(CSVから一部抜粋)

EVENT_TYPE API_FAMILY API_VERSION API_RESOURCE HTTP_METHOD
ApiTotalUsage REST 20 /v20.0/sobjects/account/describe GET

ちゃんとバージョン20のAPIアクセスが記録されていますね。

おわりに

注意点として追加費用なしの場合、イベントログは1日しか残らない点が挙げられます。
つまりアクセスの有無を確認するには毎日取得しなければならないので、実際に取得を検討される方はご注意ください。

Appendix

Lightning Platform Starter, Plus ユーザとケースオブジェクトへのアクセス

はじめに

Salesforceユーザライセンスのうち、比較的安価な Lightning Platform Starter ライセンスと Lightning Platform Plus ライセンス。

www.salesforce.com

この2つのライセンスは、ヘルプにてケースオブジェクトにアクセス可能なことが明言されています。

f:id:mark-hammer:20210715000313p:plain
ヘルプページ抜粋

しかし、Lightning Platform Starter, Plus ユーザライセンスを購入するとSalesforce組織上では Salesforce Platform ユーザライセンスとして有効化されますが、 Salesforce Platform ユーザライセンスではケースオブジェクトにアクセスできません。 権限セットを割り当てようとしても以下のようにエラーになります。

f:id:mark-hammer:20210731134937p:plain
エラー画面

実際にケースにアクセスさせるには

実はヘルプの冒頭に

「Lightning Platform Starter と Lightning Platform Plus のどちらにも Salesforce Platform ライセンスと Company Communities 権限セットライセンスが含まれます。次の表は、Salesforce Platform ライセンスが付与され、Company Communities 権限セットライセンスが割り当てられているユーザが使用できる機能を示します。」

という文言がある通り、 ケースオブジェクトにアクセスさせるには Company Communities 権限セットライセンスをユーザに付与する必要があります。
Company Communities 権限セットライセンスは、Salesforce組織上では「Company Community for Force.com」権限セットライセンスとして有効化されます。

手順

Company Communities 権限セットライセンスをユーザに付与する具体的な手順は以下になります。

  1. 設定画面でメニューから「権限セット」を選択
  2. [新規]をクリック
  3. 表示ラベルやAPI参照名を入力し、ライセンスから「Company Community for Force.com」を選択して[保存]をクリック
    f:id:mark-hammer:20210731135508p:plain
    権限セット作成画面
  4. [オブジェクト設定]をクリック
  5. オブジェクト名から[ケース]をクリック
  6. [編集]をクリックし、オブジェクト権限の「参照」「作成」「編集」「削除」から必要な権限をチェックして[保存]をクリック(必要に応じて項目権限等もチェックを入れる)
  7. [割り当ての管理]をクリック
  8. [割り当てを追加]をクリック
  9. 割り当てたいユーザにチェックを入れ、[割り当て]をクリック
  10. 割り当てが成功したことを示すメッセージが表示されればOK

注意事項

上記手順で作成した権限セットは、Salesforce Platformユーザライセンス以外のユーザにも割り当てられます。
つまり、SalesforceユーザライセンスのユーザにCompany Communities 権限セットライセンスを割り当てることもできますが、これはCompany Communities 権限セットライセンスを無駄にする行為です。(Salesforceユーザライセンスは単体でケースアクセス可能なため)
Company Communities 権限セットライセンスを使った権限セットの割り当てはSalesforce Platformユーザに限定するようにしましょう。

Appendix

Salesforce ヘルプ: Grant users with Salesforce Platform License access to Case object

Known IssueとIdeaExchange検索結果を以前と同じページ表示にする

はじめに

Trailblazer CommunityがTrailheadと合流したため、Known IssueとIdeaExchangeはページの形式が変わりました。

trailblazer.salesforce.com

trailblazer.salesforce.com

さらにKnown IssueとIdeaExchangeの検索結果画面は、Salesforce Help画面に統合されました。

f:id:mark-hammer:20210714214038p:plain
Known IssueとIdeaExchangeの検索結果画面

しかし、Salesforce Help側の検索画面…、個人的な思いですがなんか使いにくいんですよね…。
例えば、「lightning report」でIdeaExchangeを検索した場合の結果を比較しましょう。

f:id:mark-hammer:20210714214428p:plain
旧画面の検索結果

f:id:mark-hammer:20210714214445p:plain
新画面の検索結果

旧画面の方では「関連する投稿→ポイント数降順」のソートがかかっているように見えます。
結果、検索に関連する投稿のうち、よりポイント数が多い=他ユーザの共感が多い投稿が上位になります。

一方、新画面の方はステータスがMerged(=0ポイント)の投稿が最上位となっており、完全に検索キーワードとの関連度のみでソートしているように見えます。
これが致命的に悪いというつもりはありませんが、個人的には旧画面の方が好みなのです。

旧画面の検索結果を表示する

かといって、現時点ではKnown IssueとIdeaExchangeページの検索窓にキーワードを入力すると強制的にSalesforce Help画面に遷移するので、旧画面の検索結果は表示できません。
そこで、URLパラメータを使い、以下のようにURLに検索キーワードを直打ちします。

https://trailblazers.salesforce.com/issues_index?keywords=<検索キーワード>
https://trailblazers.salesforce.com/ideasearch?keywords=<検索キーワード>

これで旧画面の検索結果ページを引き続き表示させることができます。
私のような旧画面の検索結果ページが好みだった方にお使いいただければ幸いです。

データローダで複数のオブジェクトにまたがったデータを取得したい

はじめに

データローダでデータを取得しようとするとき、例えば取引先責任者で「ID、姓、名、取引先名、作成者、最終更新者」のデータを取得しようとすると、以下SOQLと結果になります。

  • SOQL
Select Id, AccountId, LastName, FirstName, CreatedById, LastModifiedById FROM Contact
  • 結果(CSV)
ID ACCOUNTID LASTNAME FIRSTNAME CREATEDBYID LASTMODIFIEDBYID
0032v00002m22azAAA 0012v00002MaYXxAAN Gonzalez Rose 0052v00000YW5o3AAD 0052v00000YW5o3AAD
0032v00002m22b0AAA 0012v00002MaYXxAAN Forbes Sean 0052v00000YW5o3AAD 0052v00000YW5o3AAD
0032v00002m22b1AAA 0012v00002MaYXyAAN Rogers Jack 0052v00000YW5o3AAD 0052v00000YW5o3AAD

ここで、取引先名、作成者、最終更新者はIDではなくて実際の名前を取りたいと思いました。
レポートであれば実際の名前を取得できるのですが、ここではデータローダで取得してみましょう。

データローダでリレーションクエリを使う

リレーションクエリとは、参照関係や主従関係がある場合に対象のオブジェクトと関連するオブジェクトのデータを取得するクエリです。
詳細は以下を参照してください。 developer.salesforce.com

リレーションクエリでは、 <呼び出し元の項目名>.<呼び出し先のAPI参照名> という形で項目を指定します。
「項目名」はAPI参照名ではなく、項目設定画面で確認できます。
例えば取引先責任者オブジェクトの「取引先名」項目は、API参照名は AccountId ですが、項目名は Account になります。

f:id:mark-hammer:20210706012109p:plain
リレーションクエリで用いる項目名

「はじめに」に書いた要件を満たすようリレーションクエリを用いたSOQLが以下になります。

Select Id, Account.Name, LastName, FirstName, CreatedBy.Name, LastModifiedBy.Name FROM Contact

結果(CSV)はこうなります。

ID ACCOUNT.NAME LASTNAME FIRSTNAME CREATEDBY.NAME LASTMODIFIEDBY.NAME
0032v00002m22azAAA Edge Communications Gonzalez Rose 管理 一郎 管理 一郎
0032v00002m22b0AAA Edge Communications Forbes Sean 管理 一郎 管理 一郎
0032v00002m22b1AAA GenePoint Rogers Jack 管理 一郎 管理 一郎

おわりに

標準オブジェクトやカスタムオブジェクトの場合、レポートでも同様の出力は得られますが、「サイト」や「権限セット」など、設定側のオブジェクトデータをエクスポートする際には役立つかと思います。
リレーションクエリはApex等開発でしか使わないものかと思っていましたが、データローダのエクスポートクエリはSOQLなので、リレーションクエリも使えるのだと勉強になりました。

Trailhead モジュール:認定アドミニストレーター資格の更新 (Spring '21)

※この内容は2021/4時点のものです。

Spring '21 での認定アドミニストレーター資格の更新

https://trailhead.salesforce.com/ja/content/learn/modules/administrator-certification-maintenance-spring-21/maintain-your-administrator-certification-for-spring21

  • 説明:日本語
  • Challenge:英語ハンズオン

【Challenge要約】

※このChallengeには、Salesforce公式解説があります。

  • このCSVファイルをダウンロードした後、オブジェクトマネージャの「作成|スプレッドシートからのカスタムオブジェクト」をクリックして、オブジェクトのAPI名: Laptop_Warranty としてインポートしてください。
    • 筆者注:「作成|スプレッドシートからのカスタムオブジェクト」を選択後、Salesforceログイン画面に戻るので、事前にユーザのパスワードリセットを行ってください。
    • 筆者注:オブジェクトのAPI名: Laptop_Warranty 以外はデフォルトのままで問題ありません。
  • カスタムオブジェクトのレコード詳細ページを動的フォームにアップグレードしてください。
    • Informationセクションを1個の列に変更してください。
    • 「Active Warranty」項目を「Support Level」項目の上に配置してください。
    • 「Support Level」項目と「Expiration Date」項目は、「Active Warranty」項目にチェックがある場合のみ表示するようにしてください。
    • 筆者注:有効化前にレコード詳細ページの表示ラベルが「Laptop_Warranty Record Page」、API参照名が「Laptop_Warranty_Record_Page」となっていることを確認してください。なっていない場合は修正してください。
  • レコード詳細ページを保存し、デスクトップおよび電話の組織のデフォルトとなるよう有効化してください。
  • 保存後に実際のレコード詳細ページを表示し、「Active Warranty」項目にチェックがある場合のみ「Support Level」項目と「Expiration Date」項目が表示されることを確認してください。