Mark Hammer's Blog

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

認定JavaScriptデベロッパー試験勉強で使用したもの

Salesforce Tips

先日、JavaScriptデベロッパー多肢選択試験に合格しました。

他のSalesforce資格試験は当然ながらSalesforceに関する知識を問われますが、この試験で問われるのはJavaScriptの知識だけで、Lightning Web Component含めSalesforceに関する知識は問われません。
（Salesforceに関する知識はJavaScriptデベロッパー資格取得のもう一つの条件であるLightning Web Component Specialist SuperBadgeで問われます。）

ここでは、勉強に使用した資料を書いていきます。

試験勉強用GitHubリポジトリ

github.com

Exercisesフォルダに試験ポイントスタディ（有償研修）にて使用すると思われるコードが入っています。
他の試験ポイントスタディ研修の資料は（恐らく）外部公開されていないことを考えると、太っ腹な対応といえます。
ソースコードのダウンロードはGitクライアントを用意しなくても[Code] ⇒ [Download ZIP]からダウンロードできます。

動作確認方法

VSCodeでリポジトリ内のコードの動作を確認する方法として以下があります。

VSCode上でのデバッグ機能

まずエクスプローラーからソースコードを開きます。

次に左端の「実行とデバッグ」アイコン（三角形と虫のアイコン）をクリックし、「実行とデバッグ」をクリックします。

すると、ブラウザが起動するとともにVSCode上にデバッグ用アイコンが表示されます。

アイコンの内容は以下だけ覚えておけば十分です。

  • 一番左：一気に全部のコードを実行する。
  • 左から2番目：1行ずつコードを実行する。
  • 右から2番目：最初(debuggerの行)からやり直す。
  • 一番右：デバッグを終了する。
VSCodeのLive Server拡張機能

左端の「拡張機能」アイコン（四角形4つで右上だけ飛び出しているアイコン）をクリックし、検索窓に「live server」と入力して最初に表示されるLive Server拡張機能をインストールします。

インストール後、右下に「Go Live」と書かれたアイコンがあるので、これをクリックすることでWebサーバが起動します。停止したい場合はもう一度クリックします。

その他詳細は「live server VSCode 拡張機能」で検索すれば調べられると思います。

使用するツール

Lesson2、Lesson3はVSCode上でのデバッグ機能、Lesson4～Lesson6はLive Server拡張機能を使用したほうが良いと思います。
なお、Lesson7はNode.jsのインストールが必要になります。

MDN Web Docs

developer.mozilla.org

Salesforceのヘルプ、開発者ドキュメントに相当するサイトです。
GitHubリポジトリ内のコードで分からないことがあればここで調べましょう。

セマンティックバージョニング資料

semver.org

docs.npmjs.com

docs.npmjs.com

サーバーサイドJavaScriptセクション範囲です。
1問出るか出ないかですが、覚えれば確実に取れる問題で内容も少ないので覚えておいて損はないです。
「セマンティック バージョニング 2.0.0」の概要は最低覚えてください。
可能であればsemverにある~（チルダ、tilde）と^（キャレット、caret）の両演算子も覚えるとよいです。上のサイトだと英語で分からないという人は検索をかけるとQiitaとかの日本語資料が出るのでそれを参照してください。

Trailheadトレイル：Study for the Salesforce JavaScript Developer I Exam

trailhead.salesforce.com

試験セクションごとに例題とフラッシュカード（単語帳）が用意されています。
このページの問題と単語帳の意味の確認だけでなく、間違った人用に用意されている資料URLも全部アクセスして一通り見ましょう。
各モジュールの最初にモジュールの全内容がPDF形式でダウンロードできるリンクも用意されているので、利用しましょう。

SSOのMFAをSalesforce側で実施しながらAPIログインのMFAを回避する方法の検証

Salesforce Tips

はじめに

SalesforceのMFAが「契約上必須」から「機能上必須」に切り替わりそうなタイミングですが、皆様はMFA対応を進めていらっしゃいますでしょうか。
さて、SalesforceにSSO経由でログインする際もMFAが必要となりましたが、SSO経由の場合はIdP側、SP側（Salesforce）どちらかでMFA対応を行えばよいことになっています。
しかし、Salesforce側でMFA対応を行うには現状プロファイル設定にて [ログインに必要なセッションセキュリティレベル] を [高保証] に設定するしかないのですが、この設定を行うとAPIログイン時にもMFAを求められ、「ユーザ名、パスワード入力方式(Password Authentication)ではデータローダでログインできない」といった状況が発生します。

以前行った検証はこちら↓
sfblog.markhammer.net

このためSSO経由ログインを行う場合はIdP側でのMFA対応が必須と考えていました。
しかし「何か方法がないかな…」と思いながら設定画面を眺めていた時に思いついた方法で今回動作したので、その内容を書いていきます。

検証

今回は以下すべての条件を満たすことを目標にします。

  • SSO経由でSalesforceにログインした場合に、Salesforce側でMFAを行う。
  • データローダでユーザ名、パスワード入力方式(Password Authentication)のログインを行ってもMFAなしでログインできる。
  • Salesforceログイン画面経由でログインした場合はMFAを行う。

結論

以下すべての設定を行えば全条件を満たせました。

  • プロファイル設定にて [ログインに必要なセッションセキュリティレベル] を [高保証] に設定する。
  • プロファイル設定、または権限セットにて「ユーザインターフェースログインの多要素認証」権限を付与する。またはセッションの設定にて「Salesforce 組織へのすべての直接 UI ログインに多要素認証 (MFA) が必要」を有効化する。
  • セッションの設定のセッションセキュリティレベルにて「高保証」に「多要素認証」と「ユーザ名とパスワード」を設定する。

「セッションセキュリティレベル」設定画面

検証の流れ

そもそも [ログインに必要なセッションセキュリティレベル] を [高保証] にしたときにユーザ名・パスワード形式のAPIログインが失敗するのは、セッションセキュリティレベルにて「高保証」に「多要素認証」しかないことが原因です。
しかし、セッションセキュリティレベルにて「高保証」に「ユーザ名とパスワード」も設定できるのを見て、【「高保証」に「ユーザ名とパスワード」を追加すればAPIログインも成功するはず。ログイン画面経由のMFA対応は「ユーザインターフェースログインの多要素認証」権限付与でできるのでは】と思い、試してみました。
以下、試した流れです。

  • 検証①：プロファイル設定にて [ログインに必要なセッションセキュリティレベル] を [高保証] に設定し、セッションセキュリティレベルの「高保証」を「多要素認証」だけにする
    • この場合、SSOログイン時にSalesforce側でMFAを行うことは成功しましたが、データローダでユーザ名、パスワード入力方式によるログインを行うと失敗しました。（前述の投稿と同じ動作）
  • 検証②：検証①＋セッションセキュリティレベルの「高保証」を「多要素認証」と「ユーザ名とパスワード」にする
    • この場合、データローダでユーザ名、パスワード入力方式によるログインは成功しましたが、Salesforceログイン画面経由でログインした場合はMFAなしになりました。
      これはセッションセキュリティレベルの「高保証」に「ユーザ名とパスワード」が追加されたため、ログイン画面経由でもMFA不要になったことが原因です。
  • 検証③：検証②＋権限セットにて「ユーザインターフェースログインの多要素認証」権限を付与する
    • この場合、Salesforceログイン画面経由でログインした場合でもMFA必須になりました。
      「ユーザインターフェースログインの多要素認証」権限はログインに必要なセッションセキュリティレベルの高保証とは別枠で判断されるようです。
      この状態でデータローダログインを試すと成功し、またSSO経由ログインでもSalesforce側でMFAが必要な動作になりました。
  • 検証④：検証②＋セッションの設定にて「Salesforce 組織へのすべての直接 UI ログインに多要素認証 (MFA) が必要」を有効にする
    • この方法でも検証③同様、3条件全てを満たすことができました。

注意事項

そもそもセッションセキュリティレベルの「高保証」は、このヘルプにもある通り機密情報の操作に制限をかけることを目的とした機能です。
「高保証」セッションセキュリティレベルを操作制限に使用している場合は今回の設定はおすすめできません。（実際に設定されているかは「ID検証」設定画面をご確認ください。）

また、今回はSSO経由ログイン時にMFAを求められましたが、Salesforceにとっては高保証のログイン方法でログインできればよいので、「SSO後通常のログイン画面同様ユーザ名とパスワードを求められ、入力すればMFAなしでログイン成功となる」場合がないとは言い切れません。
ただ「ユーザインターフェースログインの多要素認証」権限があるので、この場合は「通常のログイン画面同様ユーザ名とパスワードを求められる→MFAを求められる」流れになる、結果MFA対応OKになるのではないかと予想しています。
（この場合IdP側のパスワードとSalesforceのパスワード両方覚える必要があるので、手間的にNGとなりそうですが）

いずれにしても今回の検証内容はSalesforce側で今後変更されるかもしれない動作ですので、事前の検証を強くお勧めいたします。

認定 Platform アプリケーションビルダー資格の更新 (Winter '23)で"Please make sure the prework is configured in the playground."が出たら

Trailheadノウハウ

はじめに

Winter '23の資格更新モジュールが出ていますが、認定 Platform アプリケーションビルダー資格の更新 (Winter '23)のハンズオンで「正しい設定をしているはずなのに"Please make sure the prework is configured in the playground."というエラーが出てクリアできない」という問題が起きたのでメモします。

内容

該当モジュールはこちらです。

trailhead.salesforce.com

このChallengeの課題を簡単に説明すると、

  • ユーザ管理設定の「有効期限のある権限セットおよび権限セットグループ」を有効にする（これがprework）
  • 有効期限のある権限セットを有効ユーザに設定する

になります。
詳細な課題内容を日本語で知りたい方は公式日本語訳を参照してください。

が、実際に正しい設定をしているはずなのに、"Please make sure the prework is configured in the playground."（「有効期限のある権限セットおよび権限セットグループ」が有効でない）というエラーが出る場合があります。

エラーメッセージ

対応策

この画面が出た場合は、一度ユーザ管理設定の「有効期限のある権限セットおよび権限セットグループ」を無効にし、再度有効に変えてからChallenge確認ボタンを押してください。

「有効期限のある権限セットおよび権限セットグループ」設定

参考

この事象について、Trailhead Playground作成時に「有効期限のある権限セットおよび権限セットグループ」が最初から有効になっていることが原因との考察があります。
（実際に私の環境も「有効期限のある権限セットおよび権限セットグループ」が最初から有効でした。）

また、問題なくChallenge成功したとの報告もあります。

ちなみに「有効期限のある権限セットおよび権限セットグループ」を有効にして、権限セットを有効期限なし、また30日以外の有効期限に設定すると"The expiration date is not correct."エラーになります。

正しい有効期限にしない場合のエラー

だったら「有効期限のある権限セットおよび権限セットグループ」の内容チェックせずに最初から権限セットの有効期限だけ確認すればよかったんじゃ…

Java18以降の環境でDataLoaderにてShift-JISを扱う方法

Salesforce Tips

はじめに

2022/9に、Salesforceヘルプ：Zulu 18 以降をインストールすると、Windows 版のデータローダで文字化けが発生というヘルプが公開されました。
これはShift-JISのCSVファイルを使用すると文字化けが発生する、というもので、Java18以降のバージョンにて文字セットの指定がない場合、UTF-8をデフォルトの文字セットとして扱うという動作変更が原因です。
Java全体ではこの動作変更により「動作環境によってデフォルトの文字コードがバラバラな状態から固定できる」というメリットがあるようですが、DataLoaderでは起動時に文字セットの指定を行っていないため、Java18以降の環境ではDataLoaderはUTF-8以外は扱えない動作となりました。

現在、DataLoaderの動作環境はJava11以降となっているため、引き続きShift-JISのCSVを使用したい場合はJava11を使用する、というのがSFDCの見解のようですが、Java18以降でもこれまで通りDataLoaderを動作させる方法はないのか調査したところ、 -Dfile.encoding=COMPAT というオプションを付与することでこれまでと同様の動作にできるとのことでした。
ここではDataLoaderで -Dfile.encoding=COMPAT を使う方法と動作確認結果を書いていきます。

オプション付与の方法

環境変数を追加する

Java実行時にオプションを追加するための環境変数として JAVA_TOOL_OPTIONS があります。
この環境変数を使用して、DataLoader起動時に -Dfile.encoding=COMPAT オプションを追加します。
具体的にはコントロールパネル→システム→システムの詳細設定→環境変数の順にアクセスし、システム環境変数に以下の形で追加します。

システム変数として追加

追加した後にDataLoaderを起動すると、コマンドプロンプト（背景が黒い画面）に以下のようにオプションが設定されたことを表す文言が表示されます。

環境変数追加後のDataLoader起動画面

環境変数が追加できない、同じPCでJavaでの開発を行うので影響されたくないなどの理由がなければこちらの利用をお勧めします。

DataLoader起動用batファイルに記載する

DataLoaderとJavaを別にインストールするようになってから、DataLoaderインストールフォルダには dataloader.bat というDataLoader起動用ファイルが存在します。
そのファイルの中にある、 java から始まる行に -Dfile.encoding=COMPAT オプションを以下のように直接書き込みます。

DataLoader Ver56 でのdataloader.bat書き換え

こちらの場合、書き換える場所が分かりにくい*1、DataLoaderの新しいバージョンをインストールするごとに書き換えないといけないという問題があるため、環境変数追加の対応が難しい方のみ行うのがよいかなと思います。

動作確認

ここでは、 -Dfile.encoding=COMPAT オプション有無による動作の違いを確認します。

環境

  • OS: Windows11
  • Java: Zulu OpenJDK バージョン 19.0.1
  • DataLoader: バージョン 56.0.6

動作結果

Export

DataLoaderのオプション、 -Dfile.encoding=COMPAT オプションの有無とExportで出力される文字コードの一覧です。

DataLoaderオプション Javaオプションなし 環境変数追加 dataloader.bat編集
Write all CSVs with UTF-8 encoding 有効 UTF-8 UTF-8 UTF-8
Write all CSVs with UTF-8 encoding 無効 UTF-8 Shift-JIS Shift-JIS
Insert

〇はインポート後のSalesforce側の文字が正常なこと、×は文字化けしたことを表します。

  • CSVにShift-JISを使用
DataLoaderオプション Javaオプションなし 環境変数追加 dataloader.bat編集
Read all CSVs with UTF-8 encoding 有効 × × ×
Read all CSVs with UTF-8 encoding 無効 × 〇 〇
  • CSVにUTF-8を使用
DataLoaderオプション Javaオプションなし 環境変数追加 dataloader.bat編集
Read all CSVs with UTF-8 encoding 有効 〇 〇 〇
Read all CSVs with UTF-8 encoding 無効 〇 × ×

まとめ

動作結果から、以下が分かりました。

  • Java18以降でJavaオプション -Dfile.encoding=COMPAT がない場合、"Read/Write all CSVs with UTF-8 encoding"オプションは意味をなさず、全てUTF-8で処理される
  • Javaオプション -Dfile.encoding=COMPAT を追加してDataLoaderを起動した場合、これまで通り"Read/Write all CSVs with UTF-8 encoding"オプションにチェックがなければShift-JIS、あればUTF-8で処理される

現状、このような面倒なことを考えずに済むJava11の利用をお勧めしますが、どうしてもJava18以降を使用しないといけないなどの事情がある場合は本投稿を参考にしていただければ幸いです。

参考資料

qiita.com

mail.openjdk.org

openjdk.org

www.gwtcenter.com

docs.oracle.com

*1:DataLoader Ver53のdataloader.batのコードは上記キャプチャと異なりました

MFA自動有効化後の動作を確認してみた

Salesforce Tips

はじめに

SalesforceでのMFA必須化もついに自動有効化目前となりました。
Salesforceヘルプでは、セッション設定ページにある[Salesforce 組織へのすべての直接 UI ログインに多要素認証 (MFA) が必要] 設定を自動で有効にすることで対応するとのことです。

さて、MFA FAQではChatter External、Chatter Free ユーザ、コミュニティのみアクセスできる外部ユーザ、SSOログインではSalesforce側のMFAは必須対象外となっています。*1
本当に[Salesforce 組織へのすべての直接 UI ログインに多要素認証 (MFA) が必要] 設定を有効にしてもこれら対象外のものはMFA不要なのか、それとも除外用権限を設定しないといけないのか気になったので検証してみました。

確認対象

Developer Edition組織にて[Salesforce 組織へのすべての直接 UI ログインに多要素認証 (MFA) が必要]を有効にした場合の以下ユーザのログイン動作を確認しました。
なお、Salesforceライセンスユーザ・login.salesforce.com からのログイン以外の場合は全て[除外ユーザの多要素認証を放棄] 権限なしです。

  • Salesforceライセンスユーザ
    • login.salesforce.com からのログイン
      • [除外ユーザの多要素認証を放棄] 権限あり、なし両方確認
    • APIでのログイン
    • SSOでのログイン
  • Chatter Freeライセンスユーザ
  • Chatter Externalライセンスユーザ
  • Partner Communityライセンスユーザ
  • Customer Community Plusライセンスユーザ

結果

ユーザ 結果
Salesforceライセンスユーザ
（login.salesforce.com からのログイン、
[除外ユーザの多要素認証を放棄] 権限なし）		 MFA必要
Salesforceライセンスユーザ
（login.salesforce.com からのログイン、
[除外ユーザの多要素認証を放棄] 権限あり）		 MFA不要
Salesforceライセンスユーザ
（APIでのログイン）		 MFA不要
Salesforceライセンスユーザ
（SSOでのログイン）		 MFA不要
Chatter Freeライセンスユーザ MFA不要
Chatter Externalライセンスユーザ MFA不要
Partner Communityライセンスユーザ MFA不要
Customer Community Plusライセンスユーザ MFA不要

ということで、ライセンス、ログイン方法にて判断可能なものについてはFAQの通りMFA不要となっていることが分かりました。
コミュニティをお持ちの方や外部の方とChatterでやり取りされている方も安心ですね。

なお、UI への自動テストおよび RPA アカウントはMFA不要となっていますが、これらは[除外ユーザの多要素認証を放棄] 権限を用意しないとダメだと思います。
気になる方は事前の検証をお勧めします。

*1:SSOログインはIdP側のMFA対応が必須

失敗から学ぶTrailblazer.meアカウントのマージ

Salesforce Tips

はじめに

Trailblazer.me アカウントをご存知でしょうか。
もともとはTrailheadのアカウントだったのですが、いつからかSalesforce関連サイトの統一アカウントとなるような動きを見せ、今ではTrailheadのみならずTrailblazer CommunityやAppExchangeでもTrailblazer.me アカウントが使われています。
今回はTrailblazer.me アカウントのマージでやらかした失敗と、そこから学んだTrailblazer.me アカウント関連について書いていきます。

失敗の経緯

当時、以下のアカウントがありました。

  • アカウントA（マージ元）：前の会社で作成したアカウント。TrailheadバッジやいくつかのTrailblazer Community投稿あり。
  • アカウントB（マージ先）：今の会社で作成したアカウント。Trailheadバッジが数個。Trailblazer Community投稿はなし。

マージ前イメージ図

で、「アカウントBにアカウントAのTrailheadバッジを移したい」と思ったんですね。
正直Trailblazer Community側がどうなるか分からなかったのですが、試しにやってみるとこうなりました。

  • Trailhead

期待通り、アカウントBにアカウントAのTrailheadバッジがマージされました。

マージ後イメージ図（Trailhead）

  • Trailblazer Community

しばらくはアカウントAでもTrailblazer Communityを使えていたのですが、マージから数か月後にアカウントAにログインしようとするとアカウント新規作成画面が出るようになり、アカウントAのプロファイルページにログインできなくなりました。
Trailhead Helpに問い合わせると、「アカウントBにアカウントAのSalesforceアカウントを紐づけてください。アカウントAのTrailblazer.meアカウントは二度と使えません。（意訳）」と回答されました。
ただしアカウントAのプロファイルページ自体は公開されたまま残っていました。

マージ後イメージ図（Trailblazer Community）

正しいTrailblazer.meアカウントの運用を考える

今回の一件から、Trailblazer.meアカウントは以下のようにした方がいいと思いました。

  • 自分用のTrailblazer.meアカウントを1つ決める。
  • 他のSalesforceアカウントでTrailhead等Trailblazer.meアカウントが必要な場合は、以下の手順を踏む。
    • 自分用のTrailblazer.meアカウントにログイン
    • アカウント設定画面から「接続済みのアカウント」で紐づけたいSalesforceアカウントを紐づける

下手に複数のTrailblazer.meアカウントを持つと、どれかを捨てる判断を迫られることがあります。
それよりは1つのTrailblazer.meアカウントにアカウントをどんどん接続させた方が良いと思います。

追記：紐付きが消えたアカウントのデータ削除

上記の失敗によりアカウントAに紐づいていたプロファイルにはログインできなくなりました。
しかし、プロファイルは公開状態で個人情報がそのまま残っています。
正直これはよろしくない、ということで削除依頼をしました。

結果としては、Trailhead Helpにて「プロファイルにある情報を全削除してほしい」と依頼することで削除可能でした。
ただし、削除にはアカウントの本人確認が必要、ということで「紐づけていたメールアドレスからメールを送ってほしい」と言われました。
ここで問題なのがアカウントAのメールアドレスは前の会社のメールアドレスなので、「退職した会社なので無理。他の方法はないか。」と問い合わせると、「前の会社を退職した証明書を送ってくれ」との回答。
たまたま離職票が手元にあったので写真を撮って送ったところ、無事削除されました。
やり取りは英語ですが日本語の書類でもOKのようです。

アカウントを削除した場合、Trailblazer Community側では投稿及びメンション部分の名前がランダムな数字列になり、名前のリンクは404状態になります。
しかし、プロファイル情報削除後も「Trailblazer Communityのコメントに顔写真が残っている」とか「一部のコメントの名前部分に名前が残っている」ということがあり、逐一指摘して削除してもらう必要があったので面倒でした。
また、他の人のコメントで名前をメンションではなく直書きされている場合はおそらく消せない*1ので、活動内容によってはTrailblazer.meアカウントを削除しても自分の痕跡は残ってしまいます。

正直プロフィール非公開ができればここまで面倒な思いをしてまで全削除する必要はなかったのですが、これも経験としてやってみました。
この投稿が皆様の参考になれば幸いです。

*1:さすがに無理だろうと思って依頼しなかった

個人的なSalesforceサポートケースの作り方

Salesforce Tips

以前、Twitterでこんな投稿をしました。

せっかくなので、ここで解説してみます。

よくあるケース

自分が利用している組織で見慣れないエラーや動作がある場合、ヘルプ&トレーニングからケースを作成すると思います。
普通にやると、こんな流れになります。

ユーザ「使っているときにこんなエラーが出ました。」
サポート「確認しますので、ログインアクセス許可と再現手順をいただけますか。」
ユーザ「設定しました。」
サポート「エラーを確認しました。ちなみにSandboxでも再現しますか。」
ユーザ「再現します。」
サポート「より詳細な調査をしたいので、Sandboxのログインアクセス許可をいただけますか。合わせてレコード作成、削除なども行ってよいでしょうか」
…

…見てもらったら分かりますが、長いですね。
さらにサポートとユーザのやり取りは大体1日に2回程度です。つまりこのやり取りだけで1日以上かかります。
このあたりのやり取りはスキップして、早く調査に取り掛かってもらいたいですよね。

時間をかけずに調査に進んでもらうには

Salesforceサポートがエラー調査のために求めてくる情報は、大体以下です。

  • エラー画面、エラーメッセージ
    • 画面キャプチャを取って添付するとよいです。
    • メールで来た場合はメール本体を添付するとよいです。（調査にはメールヘッダが必要な場合もあり、本文のコピペだけでは不足と言われるかもしれません。「メッセージをダウンロード」とかしてファイル形式で送ると喜ばれます。）
  • エラーが再現する環境とその環境のログインアクセス許可
    • システム管理者（問い合わせる人）とエラーが発生する人が別の場合は、両方のログインアクセス許可を用意してあげてください。
    • ログインアクセス許可はこちらのヘルプを参照ください。
    • ログインアクセス許可にてSalesforceサポートが行ったログイン、設定変更は設定変更履歴に全部残ります。（レコード参照、編集、削除は残りません。）
    • 本番でエラーが発生する場合、余裕があればSandboxを作成して同じ手順でエラーが発生するか確認すると喜ばれます。ただ手間なので問い合わせ前にそこまでやらなくてもいいです。
      • ちなみにSandboxでの調査は、エラー調査に必要な設定変更、レコード作成・削除などが本番環境よりやり易いために行われます。
  • エラー再現手順
    • 例として「このレコードで」「このボタンを押すと」「こんなエラーが起きる」みたいな感じですね。
    • この時エラーが起きるレコードとかのURLも合わせて記載するとよいです。
    • 合わせて「ログインアクセス許可を使ってSalesforceサポート側でこの操作を行っていいか」もYes/Noで回答しましょう。時間経過によりエラーが解消した場合、Salesforceサポート側の操作で正常処理が行われてしまうかもしれないので、その点は注意しましょう。

この他にも「エラーが発生しないユーザの有無」などあるのですが、大体のポイントは上記で抑えています。
実際の問い合わせにて、上記の情報を最初の問い合わせの時に書くと以下のようになります。

○○の画面で××を行ったときに△△エラーが発生します。
エラー画面を添付します。
エラー再現手順：
1. https://sample.lightning.force.com/lightning/r/Account/001xx00000UUUUUAAA/view にアクセス
2. ○○ボタンをクリック
3. エラー

システム管理者ユーザ: xxxxxx@yyy.com とエラー発生ユーザ: zzzzzz@yyy.com にてログインアクセス許可を付与しています。
上記再現手順は実施いただいて問題ありません。

おわりに

見たことがないエラーが発生すると、多くの場合は慌ててしまいます。
ただ、その場合に「エラーが起きました」だけでなく上記のような情報も添えるとより早い解決につながることがあると思っていただければ幸いです。

Trailhead日本語要約を今後ストップします

お知らせ

お世話になっております。本ブログ管理者のMark Hammerです。
いつも本ブログをご参照いただきましてありがとうございます。

本ブログは2017年3月より英語しかなかったTrailheadモジュールのChallengeを日本語要約するサイトとしてスタートしました。
その後2019年よりはてなブログに場所を移し、TrailheadのみならずSalesforceに関するノウハウも投稿するようになり皆様より多くのアクセスをいただきました。
まことに感謝しております。

お知らせですが、表題の通り、今後Trailhead日本語要約を投稿することを一旦止めます。
理由は以下の通りです。

  • だいたい1年前からChallengeの日本語要約作成がストレスとなり、Challengeを含むTrailheadモジュールの手を止める要因となっていること。
  • そもそもChallengeの日本語要約に関する投稿へのアクセス数が少なく、上記のストレスを受ける割に需要が見込めないこと。
  • 比較的多いアクセスを頂いている資格更新モジュールのChallengeについてもSalesforce公式の日本語訳、解説があり1ユーザの投稿が必要とは思えないこと。
  • Trailhead本体にChallengeの日本語版が掲載されるようになり、必要性が薄れてきたこと。

現在投稿済みのTrailhead日本語要約についてはしばらく残しますが、今後非公開化する場合があります。
本ブログ自体は引き続き継続し、Salesforce関連の投稿を行う予定です。

なお、「このChallengeの日本語要約を作ってほしい！」という依頼がありましたらTwitterにてご連絡ください。
作成するとは明言できませんが、価値があると思えば作成する場合があります。

引き続き本ブログをよろしくお願いいたします。