ポスト
via pixabay.com
今回の内容
Salesforce の自動化機能「フロー」は大変便利な機能ですが、意図したとおりに動作しなかったり、想定外のエラー対応に追われたりするようなこともあるのではないかと思います。
今回はそんなフローのトラブル解決にとても役立つ「デバッグ」という機能についてお話をさせていただきます。
今回はそんなフローのトラブル解決にとても役立つ「デバッグ」という機能についてお話をさせていただきます。
例えばこんなシーンで…
Salesforce のシステム管理者であるあなたは、営業部門からの依頼で、営業担当または営業マネージャーが商談の「フェーズ」を更新した時に、商談の所有者を割り当て先として、そのフェーズで必要なアクションが記された ToDo を自動作成するフロー (レコードトリガーフロー) を作成しました。
実装からしばらくして、営業マネージャーの一人から
「全部ではないが、商談のフェーズを更新して保存しようとしたらエラーになる時がある」
と連絡がありました。エラーの内容は
「画面に表示されたが英語だったしすぐに消えてしまったので覚えていない」
とのことです。
エラーで更新できなかった商談レコードをいくつか教えてもらえましたが
「業務に影響がでるかもしれないのでテスト目的で更新を試したりすることは極力避けてほしい」
とも言われました。
調査を行うために、まずはエラーが発生したレコードと同じ構成でテストレコードを作成して、エラーが再現するかを確認して…としていくのももちろん良いのですが、フローで起こったエラーを調べたい場合にはもっと良い方法があります。
実装からしばらくして、営業マネージャーの一人から
「全部ではないが、商談のフェーズを更新して保存しようとしたらエラーになる時がある」
と連絡がありました。エラーの内容は
「画面に表示されたが英語だったしすぐに消えてしまったので覚えていない」
とのことです。
エラーで更新できなかった商談レコードをいくつか教えてもらえましたが
「業務に影響がでるかもしれないのでテスト目的で更新を試したりすることは極力避けてほしい」
とも言われました。
調査を行うために、まずはエラーが発生したレコードと同じ構成でテストレコードを作成して、エラーが再現するかを確認して…としていくのももちろん良いのですが、フローで起こったエラーを調べたい場合にはもっと良い方法があります。
フローで何が起こっているかを「デバッグ」で調べる
フローの作成や編集の時に使用する「Flow Builder」には「デバッグ」という機能が備わっています。
デバッグではフローが行った処理を詳細に確認することができますので、エラーが発生した箇所やその時に行われた処理についてなんらかの情報を得られるはずです。
では早速、今回のフローを見ていきましょう。
デバッグではフローが行った処理を詳細に確認することができますので、エラーが発生した箇所やその時に行われた処理についてなんらかの情報を得られるはずです。
では早速、今回のフローを見ていきましょう。
1. Flow Builder で「デバッグ」をクリック
Flow Builderでフローを 開き「デバッグ」をクリックします。
2. トリガーの起点となるレコードを選択
表示された「フローをデバッグ」の「商談」の欄に、営業マネージャーから聞いたエラーで更新できなかった商談レコードの 1 つを選択します。
＜ ワンポイント！ ＞
レコードトリガーフローのデバッグでは、既存レコードの情報を使ってテストを行うことができますが、デバッグの結果が選択したレコードなどに影響を及ぼすことはありません。
(デバッグオプションで「ロールバックモードでフローを実行します」が有効になっています。)
一方、画面フローなどデバッグオプションに「ロールバックモードでフローを実行します」がなかったり、あってもチェックが外れたりしている場合には、操作や処理の結果がそのままシステムに反映されてしまいますのでご注意ください。
レコードトリガーフローのデバッグでは、既存レコードの情報を使ってテストを行うことができますが、デバッグの結果が選択したレコードなどに影響を及ぼすことはありません。
(デバッグオプションで「ロールバックモードでフローを実行します」が有効になっています。)
一方、画面フローなどデバッグオプションに「ロールバックモードでフローを実行します」がなかったり、あってもチェックが外れたりしている場合には、操作や処理の結果がそのままシステムに反映されてしまいますのでご注意ください。
3. 選択したレコードの内容が表示される
「商談」を選択すると、その下にレコードの内容が表示されます。
4. レコードの内容をフローがトリガーされる条件に変更してデバッグを実行する
このフローでは商談の「フェーズ」の値が更新された時、条件に一致する値である時に ToDo レコードが作成される設定になっています。
「フェーズ」項目を見ると、現在は「02-ニーズの把握」という値です。
これを (フェーズの進行上に次に ToDo が作成される条件となっている)「04-意思決定者の賛同」に変更します。
これで準備ができましたので「実行」をクリックしてデバッグを実行してみましょう。
「フェーズ」項目を見ると、現在は「02-ニーズの把握」という値です。
これを (フェーズの進行上に次に ToDo が作成される条件となっている)「04-意思決定者の賛同」に変更します。
これで準備ができましたので「実行」をクリックしてデバッグを実行してみましょう。
5. デバッグの結果を確認してみる
デバッグの結果が表示されました。
①まず上の方に「失敗」と表示されているので、今回の処理についてなにか問題があったことがわかります。
②次にフローを見てみると、フェーズの値を判定するところまでは上手く進んだようですが、ToDo を作成するところで止まっていることがわかります。
③最後に「デバッグの詳細」を追っていくと、結果としてレコードの作成に失敗したことと、そのときに発生したエラーについての情報が見つかりました。
①まず上の方に「失敗」と表示されているので、今回の処理についてなにか問題があったことがわかります。
②次にフローを見てみると、フェーズの値を判定するところまでは上手く進んだようですが、ToDo を作成するところで止まっていることがわかります。
③最後に「デバッグの詳細」を追っていくと、結果としてレコードの作成に失敗したことと、そのときに発生したエラーについての情報が見つかりました。
6. エラーの原因を特定する
エラー内容の
「operation performed with inactive user [0055h0000037ls0] as owner of task」
を Google 翻訳で訳してみると
「タスクの所有者として非アクティブなユーザー [0055h0000037ls0] を使用して操作が実行されました」
という結果になりました。
ちょっと解りにくいですが、ここは Salesforce のシステム管理者としての経験をフル動員して想像してみましょう。
・タスク (task) というのは ToDo のことだな…
・ToDo の所有者 (割り当て先) として、非アクティブなユーザーを使用しているからダメだよ、と書かれている…
・非アクティブなユーザー…活発ではないユーザー？…あ、無効なユーザーということか！
デバッグで選択した商談レコードを確認すると、所有者は「鈴木 一郎」さんになっていました。
クリックしてユーザー情報を確認してみると…
「operation performed with inactive user [0055h0000037ls0] as owner of task」
を Google 翻訳で訳してみると
「タスクの所有者として非アクティブなユーザー [0055h0000037ls0] を使用して操作が実行されました」
という結果になりました。
ちょっと解りにくいですが、ここは Salesforce のシステム管理者としての経験をフル動員して想像してみましょう。
・タスク (task) というのは ToDo のことだな…
・ToDo の所有者 (割り当て先) として、非アクティブなユーザーを使用しているからダメだよ、と書かれている…
・非アクティブなユーザー…活発ではないユーザー？…あ、無効なユーザーということか！
デバッグで選択した商談レコードを確認すると、所有者は「鈴木 一郎」さんになっていました。
クリックしてユーザー情報を確認してみると…
無効ユーザーでした！
ToDo は無効ユーザーを割り当て先にできないので、今回のエラーは、商談の所有者が無効なユーザーである場合に発生していることがわかりました。
7. どんな対応が必要かを考える
原因がわかったので、どんな対応が必要なのかを考えてみましょう。
・営業部門に商談の所有者を最新の情報に更新してもらおう
・フローの処理に考慮が足りてないので見直しが必要
・入力規則を設定して、所有者が無効ユーザーのまま保存しようとすると「所有者が無効ユーザーです」とわかりやすく表示されるようにしたらどうだろうか
などなど、エラーの原因を解消することも大切ですが、新しいアイデアでより使いやすいシステムに改善していく視点も大切です。
システムに変更を加えるときは、Sandbox でしっかりテストを行ってから本番組織へリリースしましょう！
・営業部門に商談の所有者を最新の情報に更新してもらおう
・フローの処理に考慮が足りてないので見直しが必要
・入力規則を設定して、所有者が無効ユーザーのまま保存しようとすると「所有者が無効ユーザーです」とわかりやすく表示されるようにしたらどうだろうか
などなど、エラーの原因を解消することも大切ですが、新しいアイデアでより使いやすいシステムに改善していく視点も大切です。
システムに変更を加えるときは、Sandbox でしっかりテストを行ってから本番組織へリリースしましょう！
(Advanced!) もっといろんなパターンでテストすることはできる？
今のところレコードトリガーフローのみで使える機能になりますが、フローには「テスト」という機能があります。
「テスト」では、例えば「この処理を行ったとき結果としてはこうなるはず！」というテストパターンを複数作成して、詳細な動作検証を行うことができます。
詳しくは↓こちらのブログでご紹介しておりますので、せひ合わせてお読みください！
=> TerraSky TechBlog - Salesforceフローの「テスト」を使ってみた！
「テスト」では、例えば「この処理を行ったとき結果としてはこうなるはず！」というテストパターンを複数作成して、詳細な動作検証を行うことができます。
詳しくは↓こちらのブログでご紹介しておりますので、せひ合わせてお読みください！
=> TerraSky TechBlog - Salesforceフローの「テスト」を使ってみた！
おわりに
最後までご覧いただきありがとうございました。
「デバッグ」はフローを作成したときに最初のテストとして使われることが多いのですが、稼働後も動作確認やエラーの調査にとても役立ちますので、ぜひご活用いただければと思います。
今後も Salesforce の便利な機能を紹介していきますので TerraSky Tech Blog をどうぞよろしくお願いします！
「デバッグ」はフローを作成したときに最初のテストとして使われることが多いのですが、稼働後も動作確認やエラーの調査にとても役立ちますので、ぜひご活用いただければと思います。
今後も Salesforce の便利な機能を紹介していきますので TerraSky Tech Blog をどうぞよろしくお願いします！
37 件
