Mark Hammer's Blog

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

Lightningでユーザを力技でコピーしたい

はじめに

今回の検証のきっかけはこちらの投稿です。 sf.forum.circlace.com

ユーザはLightningでコピーできるのか、機能を試すという意味で興味を持ったのでやってみることにしました。

検証

実現可否の確認

※以下Salesforce URLは https://mydomain.lightning.force.com/... とします。実際に使用する際はURLはご自身の組織URLに読み替えてください。

まず前提として、LightningでcloneURLパラメータは使えません
以前業務で必要になってSalesforce社に問い合わせたのですが、「無理」という回答でした。

そのため、Lightningでコピーをするには defaultFieldValues を用いて必要な項目を1つずつ指定する必要があります。
参考:Salesforceヘルプ:デフォルト項目値を含むレコード作成ページの起動

次に、ユーザ新規作成画面で defaultFieldValues URLパラメータが使えるかを検証します。
一般的にユーザを新規作成する際は 設定|ユーザ|ユーザ の画面から「新規ユーザ」をクリックしますが、その時のURLは以下のように独特です。

https://mydomain.lightning.force.com/lightning/setup/ManageUsers/page?address=%2F005%2Fe%3FretURL%3D...

試しにこのURLに defaultFieldValues URLパラメータを追加したのですが、全く効きませんでした。

次に、先述したブログの「検証 2 カスタムリンクの作成→Lightningの場合」に記載された新規ユーザ画面に注目します。
この画面は https://mydomain.lightning.force.com/lightning/o/User/new にアクセスすれば表示されます。

もう1つの新規ユーザ画面

しかし、この画面にはユーザ作成に必要なプロファイル等の項目が配置されていないので、ユーザを作ろうとしてもエラーになります。

エラー画面

項目がないならページレイアウトで追加すればいいじゃない、ということで該当ページのページレイアウトを探します。
すると、ユーザオブジェクト設定にある「ユーザプロファイルページレイアウト」が該当ページのページレイアウトであることを確認しました。

ユーザプロファイルページレイアウト編集画面

ここまで確認できれば、このページレイアウトに必要な項目を配置し、 defaultFieldValues URLパラメータで必要項目を設定すればできるのでは、ということで試してみることにしました。

ユーザコピーを行う

まず、ユーザプロファイルページレイアウトに以下項目を配置します。

  • 名前
  • 別名
  • メール
  • ユーザ名
  • ニックネーム
  • プロファイル
  • メールの文字コード
  • タイムゾーン
  • 地域
  • ロール(必須ではない)
  • 有効(必須ではない)
  • その他必要な項目

なお、ユーザ作成には上記項目の他「言語」項目も必要ですが、ユーザプロファイルページレイアウトにはなぜか配置できません。
そのため、この画面からユーザを作成することはできません。

エラー画面

しかし、defaultFieldValues URLパラメータで「言語」項目を指定すればユーザ作成できるかもしれません。

次に、このユーザ作成画面にdefaultFieldValues URLパラメータを使ってアクセスするカスタムリンクを作成します。
作成したカスタムリンクURLは以下になります。

/lightning/o/User/new?defaultFieldValues=
FirstName={!URLENCODE(User.FirstName)},
LastName={!URLENCODE(User.LastName)},
Alias={!URLENCODE(User.Alias)},
Email={!URLENCODE(User.Email)},
Username={!URLENCODE(User.Username)},
CommunityNickname={!URLENCODE(User.CommunityNickname)},
ProfileId={!User.ProfileId},
TimeZoneSidKey={!URLENCODE(TEXT(User.TimeZoneSidKey))},
LocaleSidKey={!URLENCODE(TEXT(User.LocaleSidKey))},
LanguageLocaleKey={!URLENCODE(TEXT(User.LanguageLocaleKey))}

ちなみにメールの文字コード(User.EmailEncodingKey)、ロール(User.UserRoleId)はカスタムリンクの差し込み項目として使用できなかったため加えていません。
しかし言語(LanguageLocaleKey)は指定できました。

このリンクをクリックして表示された画面が以下になります。

コピーリンクをクリックした際の画面

メールの文字コードはデフォルト値が使用されていました。
そしてこの画面で保存をクリックすると…無事保存できました。

保存後の画面

おわりに

今回力技でユーザコピーを試しましたが、以下の理由で実用性がないと考えます。

  • カスタムリンクの時点でメールの文字コード、ロールがコピー対象から抜け落ちる。
  • マーケティングユーザ等の機能ライセンスを割り当てられない。
  • ユーザ設定画面から作成した場合には使える「パスワードをリセットしてユーザに通知する」が使えない。

個人的にはユーザをコピーするならデータローダを使うと思います。
理由は上記欠点のうち「パスワードをリセットしてユーザに通知する」が使えない点以外に対応できること、また複数コピーが同時にできるためです。

MFA必須化に対する1年前の予想の答え合わせと今後の予想

SalesforceのMFAが2022/2/1より契約上必須になりました。
これをご覧いただいている皆様は既にMFAを対応されましたでしょうか。
ちなみに私は利用者10人未満の組織を管理してますが、無事MFA対応を完了しました。

1年前の予想の答え合わせ

さて、私は1年前にSalesforce Saturday 赤坂にてMFAについてLTをしました。


この時に「本当に2022/2/1にMFAを必須にするのか?」について、【「MFA対応不可顧客に対する救済策が確定後に実際の必須化を行う(救済策確定まで延期)」と予想します。】と書きました。
ちなみにこの当時は「2022/2/1からMFAを必須にします」とは言われてましたが、「MFA必須化って具体的に何するの?」という質問に対するSalesforce社の回答はなかったんですね。
なので、ここで書いた「実際の必須化」とは、機能的にSalesforceログイン時にMFAを強制する制限を加えることを指します。

で、実際は

  • 2022/2/1から契約上はMFAを必須にします。これ以降MFAを使用していないユーザは「契約違反」となります。
  • ただししばらくはMFAを使用していなくても契約違反状態ではありますがSalesforce自体は利用できます。
  • 今後は2023年までにMFAを対象組織に強制適用する予定です。ロードマップはありますが確定していません。

となりました。
正直この発表を見たときは「契約違反状態だが強制適用はしない、そういうのもあるのか!」と思いました。
まぁ「機能的な制限の適用は延期する」という意味では予想的中としていいでしょう。

今後の予想

ここでは「現時点でMFAを有効化していないユーザに何らかのペナルティはあるのか」という疑問について予想します。
というのも、FAQでも以下のように2022/2/1時点でMFAを適用しなかったユーザに対する明確な回答はないんですね。

MFA 要件の期限 (2022 年 2 月 1 日) に間に合わないとどうなりますか?
2022 年 2 月 1 日までに MFA を有効にしていないお客様は、契約上の義務を遵守していないことになります。法務部門と相談のうえ、要件の期日までに MFA を有効化しないことによる帰結について理解しておくことをお勧めします。
一部のお客様にとって MFA は大きな変更になる可能性があります。MFA 要件に関する Salesforce の目標はお客様のビジネスを守ることで、MFA はお客様の会社のセキュリティ面やコンプライアンス面への影響を回避するための方策となるものです。この要件を満たすことに関して懸念がある場合は、Salesforce の担当者にお問い合わせください。Salesforce がお客様と協力して解決策を模索します。

で、MSAとかを読みながら「実際に発生し得るペナルティとは何か?」を考えた結果、自分の中で結論が出たのでここに書きます。

注意書き

  • この予想は現時点で確認できた情報を基にした私個人の見解で、Salesforce社とは無関係です。
  • この予想はマスターサブスクリプション契約(以下MSA)下でSalesforceを利用していることを前提としています。特殊な契約を結んでいる場合は適用されません。
  • この予想は契約違反状態のままSalesforceを使い続けることを肯定するものではありません。
  • 免責事項の通り、この投稿に沿って行動したことにより損失や損害などの被害が発生したとしても、当ブログ及び筆者は責任を負いません。あくまで読み物としてご覧ください。

今後の予想

MFA適用ロードマップに記載された「MFA 適用予定日」(ログイン時にMFAを強制する&システム管理者がMFA強制を解除する機能を削除する日)までMFAに対応しなかったとしても、Salesforce社によるペナルティはない。

理由

まず、MFA必須化が何をもって「契約上の義務」となっているかを記載します。
Salesforce Notices and License Informationには、MFA必須化のために以下文言が追加されています。

MFA Requirement for Using the Covered Services
Starting February 1, 2022, Salesforce will begin requiring customers to enable Multi-Factor Authentication (MFA) for all Covered Services, unless otherwise approved by Salesforce in accordance with Salesforce internal policies and procedures. Customer must satisfy the MFA requirement by either: (1) enabling Multi-Factor Authentication for all users who log in to Customer’s Covered Services through the user interface or (2) ensuring MFA is enabled for all users who use Single Sign-On (SSO) to access Customer’s Covered Services, by using the SSO provider’s MFA services or, where supported, by turning MFA on in Salesforce products. Further information on MFA, including acceptable verification methods for MFA, can be found here.

(以下DeepLによる翻訳に手を入れたもの)

対象サービスを利用するためのMFA要件
2022年2月1日より、SalesforceはSalesforceの社内ポリシーおよび手続きに従ってSalesforceが別途承認した場合を除き、すべての対象サービスにおいて多要素認証 (MFA) を有効にするようお客様に要求します。お客様は、以下のいずれかにより、MFA 要件を満たす必要があります。(1) ユーザインタフェースを通じてお客様の対象サービスにログインするすべてのユーザに対して多要素認証を有効にする、または (2) シングルサインオン (SSO) を使用してお客様の対象サービスにアクセスするすべてのユーザに対して、SSO プロバイダの MFA サービスを使用して、またはサポートされる場合は Salesforce 製品で MFA をオンにして、MFA が有効になっていることを確認します。MFA の許容される検証方法など、MFA の詳細については、こちらをご覧ください。

そして、MSAには以下の記載があります。

「本ドキュメンテーション」とは、該当する本サービスの、 https://www.salesforce.com/company/legal/trust-and-compliancedocumentation/ に掲載されている Trust and Compliance という表題(「トラスト及びコンプライアンス」「信頼とコンプライアンス」等と表示される場合があります)の文書、並びに該当する本サービスの利用ガイド及びポリシーで、随時更新され help.salesforce.com 経由で、又は該当する本サービスにログインすることによってアクセス可能なものを意味します。

前述した「Salesforce Notices and License Information」は「Trust and Compliance Documentation」に含まれているので、MSAでいう「本ドキュメンテーション」に含まれます。
続いてSalesforceユーザの責任に関する条項は以下です。

3.3 お客様の責任。
お客様は、以下の義務を負います。
(a) 本ユーザの本契約、本ドキュメンテーション及び本注文書の遵守について責任を負うこと
(中略)
お客様もしくは本ユーザによる上記に違反した本サービスの利用によって、SFDC のサービスのセキュリティ、完全性、可用性が脅かされると判断した場合には、SFDC は、直ちに本サービスを停止することができます。ただし、SFDC は、当該停止前にお客様に通知し、お客様に当該違反又は脅威を是正する機会を与えるよう、その状況における商業上合理的な努力を行います。

つまり、FAQでいう「契約上の義務」及び違反時のペナルティは以下になります。

  • Salesforceユーザは「本ドキュメンテーション」に記載された「MFA 要件を満たす」というルールの遵守について責任を負う。
  • MFA要件を満たさない(=上記に違反した本サービスの利用)ことによりSalesforce社が「セキュリティ、完全性、可用性を脅かす」と判断した場合、Salesforce社はサービスを停止することができる。
  • ただし、Salesforce社はサービス停止前にユーザに対し、当該違反又は脅威を是正する(本件ではMFA要件を満たす)機会を与えるよう商業上合理的な努力を行う。

つまり、Salesforce社は商業上合理的な努力を行う前にサービス停止することはない、ということです。
では「商業上合理的な努力」とは何か、ですが、まずは「ユーザに対しMFA要件を満たすよう様々な方法で依頼、呼びかけをする」ことでしょう。
それでもMFAに対応しなかった場合、もしサービス停止するのであれば「XX年XX月XX日までにMFA対応しない場合はサービスを停止する」といった最後通告がSalesforce社より送られるはずです。

しかし、仮にサービス停止するのであればMFA適用ロードマップを用意するでしょうか。
「MFA 適用予定日」に適用される内容は「ログイン時にMFAを強制する&システム管理者がMFA強制を解除する機能を削除する」です。つまりこれで強制的にMFA要件を満たさせることができます。
方法はともかく、MFA要件を満たしたのであればルールは遵守されたことになりますのでサービス停止にはならないはずです。
となるとサービス停止にするのは「MFA 適用予定日」前でなければなりませんが、「MFA 適用予定日」までにMFA適用していないユーザをサービス停止するのであれば、「MFA 適用予定日」時点では全ユーザがMFA適用済みなのですから、「ログイン時にMFAを強制する&システム管理者がMFA強制を解除する機能を削除する」必要もないです。

また、サービス停止以外のペナルティですが、MSAの「3.3 お客様の責任」節にサービス停止以外のペナルティが記載されていない以上、それ以外のペナルティはないと思います。*1
よって、「今後の予想」節の通り「MFA 適用予定日」まで対応しなくてもペナルティはない、という予想になりました。

おわりに

「MFAは契約上の義務」、「2022/2/1時点でMFA対応しなかったら契約違反」とはずっと言われてきましたが、「対応しなかったらどうなるの?ペナルティはあるの?」に対する回答は今までSalesforce社からもらったことがありません。
ということでMSA等を読んで上記の結論に至ったわけですが、私は法律等の専門家でもありませんので、注意書きに書いたようにあくまで読み物として扱ってください。

皆さんはルールを守ってSalesforceログイン時はMFAを導入しましょう。

皆さんはルールを守ってSalesforceログイン時はMFAを導入しましょう。

大事なことなので2回書きました。

*1:何か見逃した条項がある or 今後MSAにペナルティを追記する可能性はありますが

選択リストを基に作った日付から年度判定をしたい

はじめに

以下のような質問を受けました。

  • あるオブジェクトに、以下の項目がある。
    • 年/月を項目値とした選択リスト項目(項目値として2022/01、2022/02、…のように並んでいる)
    • 上記選択リスト項目を基に、年月は選択リスト項目値のものを、日は15日に固定した数式(日付)項目
      • 例:選択リスト項目が「2022/1」の場合は「2022/1/15」となる。
  • この時、数式(日付)項目が今年度かどうかを判定する数式項目を作りたい。

この数式作りに結構苦戦したのでここに残しておきます。

数式作り

前提

数式に用いる項目のAPI参照名及び仕様は以下とします。

  • 年/月を項目値とした選択リスト項目: picklist_date__c
    • 選択リスト項目値は2022/01、2022/02、…のように、月の部分は2桁固定とします。
  • picklist_date__c から作成した数式(日付)項目:formula_date__c
    • 数式は DATE(VALUE(LEFT(TEXT(picklist_date__c),4)), VALUE(RIGHT(TEXT(picklist_date__c),2)), 15) とします。
  • 今年度か判定する数式項目:chk_thisyear__c (テキスト項目)
    • 今年度の場合は「今年度」、そうでない場合は「今年度以外」と表示します。

年度が固定の場合

これは formula_date__c が該当年度(〇年4月1日~〇+1年3月31日)の間であることをIF関数を用いてチェックすればOKです。
例として、2021年度か否かを判定する場合は以下数式になります。

IF(AND(formula_date__c >= DATE(2021,4,1), formula_date__c <= DATE(2022,3,31)),
"今年度", "今年度以外")

年度が「今日」を基準にする場合

これは年度固定の場合より少し複雑になります。
なぜなら今日の月によって年の判定が変わるからです。

  • 今日が1月~3月の場合
    • formula_date__c が去年の4月1日から今年の3月31日までなら「今年度」
  • 今日が4月~12月の場合
    • formula_date__c が今年の4月1日から来年の3月31日までなら「今年度」
formula_date__c を使った数式

そこで、以下のように今日の月によって判定が変わるようIF関数を追加して、以下の数式を作成します。

IF(MONTH(TODAY())<=3, 
    IF(AND(formula_date__c >= DATE(YEAR(TODAY())-1,4,1), formula_date__c <= DATE(YEAR(TODAY()),3,31)),
    "今年度", "今年度以外"),
    IF(AND(formula_date__c >= DATE(YEAR(TODAY()),4,1), formula_date__c <= DATE(YEAR(TODAY())+1,3,31)),
    "今年度", "今年度以外")
)

すると、数式サイズが5000文字オーバーとしてエラーになってしまいました。

formula_date__c を使うパターンではこれ以上簡単な数式を作れなかったので、再考を求められました。

formula_date__c を使わない数式

formula_date__c を使わないとなると、picklist_date__cから年、月を取り出して、そこから今日の日付と比較を行う必要があります。
また、数式サイズ削減のためDATE関数を使用できないので、年と月を個別に比較する必要があります。
考えた結果、以下の表を作成してからそれを数式に当てはめました。

picklist_date__c
1~3月 4~12月
今日 1~3月 年が同じ picklist_date__cの年が
今日の年の1年前
4~12月 picklist_date__cの年が
今日の年の1年後
年が同じ
  • 数式
IF( 
    OR(
        AND(MONTH(TODAY())<=3,VALUE(right(TEXT(picklist_date__c),2))<=3,VALUE(left(TEXT(picklist_date__c),4))=YEAR(TODAY())),
        AND(MONTH(TODAY())>=4,VALUE(right(TEXT(picklist_date__c),2))>=4,VALUE(left(TEXT(picklist_date__c),4))=YEAR(TODAY())),
        AND(MONTH(TODAY())<=3,VALUE(right(TEXT(picklist_date__c),2))>=4,VALUE(left(TEXT(picklist_date__c),4))=YEAR(TODAY())-1),
        AND(MONTH(TODAY())>=4,VALUE(right(TEXT(picklist_date__c),2))<=3,VALUE(left(TEXT(picklist_date__c),4))=YEAR(TODAY())+1)
    ),
    "今年度", "今年度以外")

これで数式サイズも5000文字以下となり、利用可能になりました。

Salesforce MFAのマニュアル一覧

MFAのマニュアルについて、たまに質問されることがあったのでURLを書いておきます。

日本語版

英語版

その他外国語版

上記言語以外のユーザに対してはMFAロールアウトパックが用意されています。
これは、MFAに関するユーザ説明用資料が以下言語分全てダウンロードできる内容になっています。

  • 日本語(JP)
  • 英語(EN)
  • ドイツ語(DE)
  • スペイン語(es-MX)
  • フランス語(FR)
  • ポルトガル語(pt-BR)
  • 中国語(zh-CN)

多国籍のユーザに案内をする担当者には心強い資料だと思います。
ただし460MBありますのでダウンロード時間に注意してください。

レコードタイプ、ページレイアウト、○○プロセスの分け方を考える(認定アドミニストレータ向け)

最近、会社にてチームメンバーにSalesforce認定アドミニストレータ試験の勉強会を開いています。
その中で、「レコードタイプ、ページレイアウト、セールス/サポート/リードプロセスの使い分けが分かりません」と言われたので、サンプル問題を使って解説しました。
その内容をここにも残しておきます。

サンプル問題

AWコンピュータ社の営業とサポートは、ケースで異なる項目を管理しています。
またCPU、メモリ、マザーボードの3つの製品ラインがあり、それぞれ異なるサポートプロセスと入力が必要な項目があります。
この要件を満たす実装はどれですか?
【選択肢】
A. レコードタイプを2つ、ページレイアウトを6つ、サポートプロセスを2つ
B. レコードタイプを6つ、ページレイアウトを3つ、サポートプロセスを3つ
C. レコードタイプを3つ、ページレイアウトを6つ、サポートプロセスを3つ
D. レコードタイプを3つ、ページレイアウトを2つ、サポートプロセスを3つ

解説

選択肢の機能について

選択肢に記載されている3つの機能について詳しい解説はここでは行いませんが、この中でレコードタイプは特に制約がありません。
一方、他の2つの機能は、以下の通り別の機能が関連します。

  • ページレイアウト:レコードタイプとユーザプロファイルによって決まる
  • サポートプロセス:レコードタイプによって決まる

つまり、ページレイアウトを分けたいならレコードタイプかユーザプロファイルを追加する必要があり、サポートプロセスを分けたいならレコードタイプを追加する必要があります。

問題文の読み込み

1文目

まず、1文目から読み進めます。
「営業とサポートは、ケースで異なる項目を管理」とのことなので、ここから「営業とサポートには自分たちが管理する項目だけ表示させる必要がある」→「営業とサポートでページレイアウトを分ける必要がある」と読み取れます。
また、営業とサポートは利用ユーザのため、「営業とサポートで別のユーザプロファイルを用意し、各プロファイルごとに別のページレイアウトを割り当てる必要がある」と判断できます。

2文目

次に2文目ですが、
「CPU、メモリ、マザーボードの3つの製品ラインがあり、それぞれ異なるサポートプロセスと入力が必要な項目がある」とのことです。
つまり、サポートプロセスは3つの製品ラインごとに用意する必要があります。
また、「3つの製品ラインごとに異なる『入力が必要な項目』がある」とのことなので、3つの製品ラインごとにページレイアウトも用意する必要がある、と読めます。

ここで、前述の通り「ページレイアウトを分けたいならレコードタイプかユーザプロファイルを追加する必要があり、サポートプロセスを分けたいならレコードタイプを追加する必要がある」ので、3つの製品ラインごとにレコードタイプを用意する必要があります。
結果、2文目からは「3つの製品ラインごとにレコードタイプを用意し、それぞれ別のサポートプロセスとページレイアウトを割り当てる必要がある」と判断できます。

各機能の個数を決める

ここまでの話で、レコードタイプ、サポートプロセスは2文目の要件でしか使用しないこと、また3つの製品ラインごとにレコードタイプを用意することから、「レコードタイプは3つ」、「サポートプロセスは3つ」と決まります。
この時点で、回答はCかDのいずれかです。

【選択肢】
A. レコードタイプを2つ、ページレイアウトを6つ、サポートプロセスを2つ
B. レコードタイプを6つ、ページレイアウトを3つ、サポートプロセスを3つ
C. レコードタイプを3つ、ページレイアウトを6つ、サポートプロセスを3つ
D. レコードタイプを3つ、ページレイアウトを2つ、サポートプロセスを3つ

最後のページレイアウトですが、「問題文の読み込み」節にて以下のように読み取りました。

  • 1文目から、営業とサポートで別のユーザプロファイルを用意し、各プロファイルごとに別のページレイアウトを割り当てる必要がある
  • 2文目から、3つの製品ラインごとにレコードタイプを用意し、それぞれ別のページレイアウトを割り当てる必要がある

これを表にすると、以下のようになります。

「CPU」レコードタイプ 「メモリ」レコードタイプ 「マザーボード」レコードタイプ
「営業」プロファイル 「営業&CPU」ページレイアウト 「営業&メモリ」ページレイアウト 「営業&マザーボード」ページレイアウト
「サポート」プロファイル 「サポート&CPU」ページレイアウト 「サポート&メモリ」ページレイアウト 「サポート&マザーボード」ページレイアウト

よって、用意するページレイアウトは6つとなり、答えはCとなります。

【選択肢】
A. レコードタイプを2つ、ページレイアウトを6つ、サポートプロセスを2つ
B. レコードタイプを6つページレイアウトを3つ、サポートプロセスを3つ
C. レコードタイプを3つ、ページレイアウトを6つ、サポートプロセスを3つ
D. レコードタイプを3つ、ページレイアウトを2つ、サポートプロセスを3つ

おわりに

この問題を解くのに最も重要な点は、

  • ページレイアウト:レコードタイプとユーザプロファイルによって決まる
  • サポートプロセス:レコードタイプによって決まる

が理解できていることだと思います。
その上で、問題文からレコードタイプ、ページレイアウト、○○プロセスをどう分けるかを考える力が必要になるでしょう。

Lightningで活動タイムラインが表示されない時に確認する場所

はじめに

通常、Lightning Experienceのレコードページでは、「活動」タブに活動タイムラインが表示されます。

しかし、何をしたわけでもないのに「活動」タブが消え、活動タイムラインも表示されない場合があります。

今回は、このような「活動」タブが消えた際に確認した方がよい設定箇所をご紹介します。

「レコードページの設定」画面

Salesforceには「レコードページの設定」という設定画面があります。
そして、この画面にある「デフォルトの活動ビュー」にてLightning Experienceでの活動を「活動タイムラインで表示する」か「Classicと同様、関連リストとして表示する」かを選択できます。
なお、この設定画面は全体設定だけでなく、個人設定画面にも表示されます。

  • 設定画面

  • 個人設定画面

「デフォルトの活動ビュー」にて「関連リスト」を選択すると「活動」タブが消え、活動タイムラインも表示されません。
その代わり、Lightningレコードページに「活動予定」「活動履歴」関連リストが表示されます。(「活動タイムライン」を選択した場合は「活動予定」「活動履歴」関連リストは表示されません。)

「活動リスト」を選択した場合のLightningレコードページ

上記の通り、「デフォルトの活動ビュー」は個人設定画面にもあるため、「他の人は活動タブが表示されているのに、自分だけ表示されない」という事態も起こりえます。
このような場合は、まずは個人設定画面の「レコードページの設定」を確認することをお勧めします。

追記

「レコードページの設定」では「関連リスト」と「活動タイムライン」どちらかを選ぶ形式のため、「活動タイムライン」と「活動予定」「活動履歴」関連リストを同時に表示させることはできません。
ただし、Lightningレコードページにて「関連リスト - 1つ」コンポーネントを使うことで「活動タイムライン」と「活動予定」「活動履歴」関連リストを同時に表示させることができます。

Lightningレコードページ作成画面

Appendix

Salesforce MFAの紐づけをシステム管理者が代行する方法を考えてみた

(この投稿はSalesforce Advent Calendar 2021の12日目です) qiita.com

どうも、Mark Hammerです。
そういえば今日はSalesforce ハッカソン 2021の発表日ですね。
どういった成果物が出てくるのか楽しみに見たいと思います。

developer.salesforce.com

はじめに

2021年、Salesforce界隈を騒がせたMFA必須化。
皆さん2022/2/1の必須化開始に向けてアプリのインストールや機器の購入、社内調整等で大変かと思います。

私はTrailblazer CommunityのMFAに関するグループをたまに眺めているのですが、そこで出てくるのが「ユーザがMFAアプリを登録するのではなくシステム管理者が登録することはできないのか」という質問。
ちなみにSalesforce AuthenticatorやGoogle Authenticator等サードパーティアプリを使用する場合、以下の流れになります。

  1. 事前にSalesforceの私の設定画面でSalesforce AuthenticatorかGoogle Authenticator等サードパーティアプリの紐づけを行う。
  2. Salesforceログイン時にMFAを必須にする設定を行う。
  3. 2.設定後にSalesforceにログインした際に表示される認証画面で紐づけしたアプリを使用して認証する。

ここで必ずユーザが実施しなければならない作業が1.の紐づけなのですが、これをシステム管理者が代行できるとすれば、以下の要件を満たす必要があると考えます。

  1. ユーザの持つアプリを特定できる情報をSalesforce側にインポートできる。
  2. 1.でインポートした際にユーザの持つアプリに自動でSalesforce認証用情報が登録される。

しかし1.のインポートといっても、Salesforce Authenticator紐づけの際は英単語2個、サードパーティアプリ紐づけの際はSalesforce側に表示されるQRコードか認証コードを用いる必要があるため、アプリ側の情報をSalesforce側にインポートできるように見えません。
2. に至ってはアプリ側の操作なしに自動でSalesforce認証用情報が登録されるというのは無理があるように見えます。
よって、「頑張ってユーザに紐づけ操作してもらってください。」というのが今までの認識でした。

Secretコードによる認証アプリの紐づけ

この認識が変わったのは2021/11/4に行われたMFA FAQの更新です。(日本語版FAQには投稿時点で未反映)
「What are third-party TOTP authenticator apps?」にて、Salesforceにハードウェアトークンを登録できるとの情報が記載されました。
そこに記載されていた説明文では、データローダ等でTwoFactorInfoオブジェクトに対しSecretコードをインポートできるとの記載がありました。

To associate a hardware token with a user, insert a TwoFactorInfo object into the database, as described in the Salesforce Object Reference. You need to provide the Secret, the user's ID, and specify the Type field as 'TOTP'. You can use the Data Loader, Workbench, or custom Apex to insert TwoFactorInfo objects into the database.

おそらくハードウェアトークンであればSecretコードは製品のどこかに記載があるのだと思います。
ではアプリ紐づけの際に使えるSecretコードを取得することはできないのだろうか、と情報を探しました。
そして、ApexのSessionManagement クラスにて、 getQrCode() 関数の存在を知りました。

Apex 開発者ガイド:SessionManagement クラス より抜粋

getQrCode()
多要素認証 (MFA) 用の認証アプリケーションまたはデバイスを設定するための、QR (Quick Response) コードと時間ベースのワンタイムパスワード (TOTP) の共有秘密への URL が含まれる対応付けを返します。

これで、特定のSecretコードを認証アプリに登録するためのQRコードを発行できるURLを入手できました。

(匿名 Apex コード)
Map<String, String> codeResult = Auth.SessionManagement.getQrCode();
String result = 'URL: '+codeResult.get('qrCodeUrl') + ' SECRET:  ' + codeResult.get('secret');
System.debug(result);

(Output)
USER_DEBUG [3]|DEBUG|URL: https://sampledomain.my.salesforce.com/secur/qrCode?w=200&h=200&t=tf&u=sample%40example.com&s=3C2IC7JFL7SXMGSQSMLTJKFIZSXJOXG0 SECRET:  3C2IC7JFL7SXMGSQSMLTJKFIZSXJOXG0

このURLの secret 部分は英数字であれば書き換えても利用可能です。
これを利用して、Salesforceへの認証アプリ登録をシステム管理者が実施することが可能になりました。

システム管理者が認証アプリを紐づけする手順

データローダでの作業

※作業前に、システム管理者に「API で多要素認証を管理」権限を付与する必要があります。
この権限は「システム管理者」標準プロファイルにはないため、カスタムプロファイルか権限セットで付与してください。

UserId Type SharedKey
005xxYYYYYzzzzz*1 TOTP 0Z1Z2Z3Z4Z5Z6Z7Z8Z9Z0Z1Z2Z3Z4Z5Z*2
  • データローダ等を用いて「2要素情報(TwoFactorInfo)」オブジェクトにInsertを行う。
    • データローダ利用の際はオブジェクト選択時に「Show all Salesforce objects」にチェックを入れること。
    • Insert成功時、紐づけ先ユーザには「Salesforce アカウントに新しい検証方法が追加されました」というメールが届くため、事前にユーザに説明が必要。

ユーザへのQRコード提示

上記作業はあくまでSalesforce側への登録のため、これだけではユーザが持つアプリにSalesforce認証用の情報が入りません。
そのため、以下URLやSecretコードを連携してアプリに登録してもらいます。

メリットとデメリット

この方法のメリットとデメリットは以下の通りです。

  • メリット
    • ユーザが行うのは認証アプリでのQRコードの撮影、またはコード入力のみ。Salesforceの画面操作は不要。
    • QRコード撮影による登録の場合、アプリに表示する識別用文字列を自由に変更できる。*3
    • 極論、端末さえ貸してもらえればユーザのパスワードやメールで届く認証コードなしで多要素認証のアプリ紐づけが可能なのでシステム管理者のみの作業で済む。
  • デメリット
    • ユーザがアプリへの紐づけ登録を行わずに多要素認証を有効化した場合、Salesforceにログインできない状況が発生する。
      • この場合は一旦システム管理者がSalesforce側のアプリ接続を削除するしかない。
    • ユーザがアプリへの紐づけ登録をしたか否かはシステム管理者含む他の人には分からない*4ので、いちいちユーザに登録状況を確認する必要があり、面倒。
    • この方法で登録できるのはワンタイムパスワード認証(TOTP)のみで、Salesforce Authenticatorやセキュリティキーの登録はできない。

個人的には、この方法は「システム管理者が登録を代行したい」という要望がなければ考えない方法であり、あまり有用とは思っていません。
ただ、「こういう方法もあるよ」ということで今回投稿してみました。

悪い例:セキュリティ強度が落ちる紐づけ

通常、TwoFactorInfoオブジェクトに登録する SharedKey (Secretコード)はユーザごとに異なるのですが、 SharedKey 項目にはユニーク制約がないので、複数のユーザに同じSecretコードを設定することができます。
また、複数の認証アプリに同じSecretコードを設定すると、(当然ながら)同じ6桁の認証コードが表示されます。

つまり、以下のような設定も可能なわけです。

  • TwoFactorInfoオブジェクトへのインポートで、全ユーザに同じ SharedKey (Secretコード)を設定する。
  • ユーザのアプリ紐づけ用QRコードのURL、コードを1つ作成し、全ユーザに連携する。
    • URLの u パラメータは会社名などにする。
  • 全ユーザの認証アプリに表示される認証コードは同一のため、自分の端末を失くしても他の人の端末(認証アプリ)があれば認証できる。

…まぁこれは多要素認証の意味がなくなる設定なので、やったらダメですよ。

おわりに

TwoFactorInfoオブジェクトの存在から、MFAの紐づけをシステム管理者がどこまで代行できるか考えてみましたが、最終的なアプリの紐づけはユーザに実施してもらう必要がある*5以上、従来通りSalesforceの「私の設定」から紐づけしてもらうのが一番楽ではないか、という結論になりました。
ただ複数の方法を知っていることは何かの役に立つかもしれませんので、この投稿が(悪い例以外で)お役に立てれば幸いです。

追記:代理ログインによるMFA紐づけ代行

今回の調査を行った後に、システム管理者が他のユーザに代理ログインし、アプリ紐づけができるか試したところできることが分かりました。なので、この方法でもユーザのパスワードなしでMFA紐づけを代行することは可能です。
ただ、代理ログインでのアプリ紐づけの場合、ユーザ確認として確認コードのメール送信か、既に紐づけ済みのアプリによる認証が行われます。
通常アプリ紐づけは初回になるかと思いますので、ユーザに確認コードのメールを転送してもらう必要があります。

*1:紐づけしたいユーザID

*2:Secretコード

*3:従来のSalesforce画面で登録する場合、識別用文字列はユーザ名固定

*4:レポートやユーザ画面ではSalesforce上の紐づけ状況しか確認できないので、今回の方法ではアプリ紐づけ状況が分からない

*5:前述の通り端末を貸してもらえればユーザのパスワードなしに紐づけ代行はできますが、そこまでするシステム管理者はいないと思います

Trailhead モジュール:Platform デベロッパー認定資格の更新 (Winter '22)

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

Platform デベロッパー向けの新機能の学習

https://trailhead.salesforce.com/ja/content/learn/modules/platform-developer-i-certification-maintenance-winter-22/learn-whats-new-for-platform-developers-22

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

【Challenge要約】

※このChallengeにはセールスフォース・ドットコム社による解説があります。

  • 組織設定にて「言語のデフォルト値」を「英語」にしてください。
  • 事前に「ハンズオン Challenge の準備」節の作業を実施してください。
  • 新規Apexクラス「CountryCodeHelper」を作成してください。
  • 「ハンズオン Challenge の準備」節の「CountryCodeHelper Apex クラス」のコードをApexクラス「CountryCodeHelper」にコピー&ペーストしてください。
  • Apexクラス「CountryCodeHelper」を、getInstance メソッドを使用してカスタムメタデータの情報を返すように書き換えてください。
  • 不要なコードはコメントアウトではなく削除してください。(これはチェックしません)

Trailhead モジュール:Platform アプリケーションビルダー資格の更新 (Winter '22)

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

Winter '22 のアプリケーションビルダー向けの新機能の学習

https://trailhead.salesforce.com/ja/content/learn/modules/platform-app-builder-certification-maintenance-winter-22/learn-whats-new-for-app-builders-in-winter-22

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

【Challenge要約】

※このChallengeにはセールスフォース・ドットコム社による解説があります。

  • 事前に設定|機能設定|アンケート|アンケートの設定 にて「アンケート」を有効にしてください。
  • 以下内容で権限セットを作成してください。
    • 表示ラベル:Create Surveys
      • API参照名:Create_Surveys
      • ライセンス:なし
      • 「アンケート」オブジェクト権限:参照、作成、すべて表示
    • 表示ラベル:Access to Contacts
      • API参照名:Access_to_Contacts
      • ライセンス:なし
      • 「取引先責任者」オブジェクト権限:参照、作成、すべて表示
  • 以下内容で権限セットグループを作成してください。
    • 表示ラベル:Contacts Survey
      • API参照名:Contacts_Survey
      • 説明:Access to create survey and read and edit access to contacts
      • セッションの有効化が必要:チェックを入れる
  • 作成した「Contacts Survey」権限セットグループに「Create Surveys」権限セットと「Access to Contacts」権限セットを追加してください。

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

はじめに

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

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

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

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

検証

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

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

[Salesforce ログイン情報を使用したログインを無効化] を有効にした時のログイン履歴

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

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

[シングルサインオンの有効] 権限を付与した時のログイン履歴

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

おわりに

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

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