Mark Hammer's Blog

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

Trailhead モジュール:Lightning Experience の Service Cloud

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

サービスジャーニーの開始

https://trailhead.salesforce.com/ja/content/learn/modules/service_lex/service_lex_cloud

  • 説明:日本語
  • Challenge:日本語選択問題

Service Cloud の管理

https://trailhead.salesforce.com/ja/content/learn/modules/service_lex/service_lex_connect

  • 説明:日本語
  • Challenge:日本語選択問題

ケース管理の自動化

https://trailhead.salesforce.com/ja/content/learn/modules/service_lex/service_lex_case_manage

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

【Challenge要約】

  • ケースオブジェクト用のキュー「Panel1」を作成してください。
  • ケースを「Panel1」キューに割り当てるためのケース割り当てルール「Assign Panel1」を作成してください。
  • ケース割り当てルール「Assign Panel1」にて、「ケース: 説明」に「Panel1」を含む場合に「Panel1」キューに割り当てるよう設定してください。
  • エスカレーションルール「Panel1」を作成してください。
  • エスカレーションルール「Panel1」にて、30分経過後もクローズされなかったケースをエスカレーションするよう設定してください。なお、「営業時間の設定」は「ケースに指定された営業時間を使用」、「エスカレーション時刻の設定方法」は「ケースの作成時」としてください。
  • エスカレーションアクションではあなたのユーザにケースが割り当てられるよう設定してください。
  • 作成したケース割り当てルール、エスカレーションルールはどちらも有効にしてください。

複数のチャネルでのデジタルエンゲージメントの作成

https://trailhead.salesforce.com/ja/content/learn/modules/service_lex/service_lex_channels

  • 説明:日本語
  • Challenge:日本語選択問題

フローで項目値を空文字に更新しようとしたけど更新されなかった話

これは以前の投稿の続編です。
フローの要件等は↓を読んでいただいた前提で進みますのでご了承ください。 sfblog.markhammer.net

はじめに

以前、行動の被招集者のうち、ユーザ一覧をテキスト項目に投入するフローを作成したのですが、実際は投入先のテキスト項目は100文字制限がありました。
そのため、被招集者が20人程度になるとエラーを返すようになります。

f:id:mark-hammer:20200906004234p:plain

そこで、作成したテキストが100文字を超える場合は100文字に切り捨てるよう、以下のように変更しました。

  • 変更前
    • 「同行者」項目に作成したテキスト変数をそのまま割り当てる
  • 変更後
    • LEFT(<作成したテキスト変数>, 100) で100文字に切り捨てたテキストを「同行者」項目に割り当てる

その後動作確認をすると、確かに100文字切り捨ては正しく動作したのですが…、
空文字更新しようとしても前のデータが残ってしまう動作になってしまいました。

f:id:mark-hammer:20200906010047p:plain

デバッグログで動作を確認する

なぜこうなってしまったのか、デバッグログで更新中の動作を確認すると…。

  • 変更前(LEFT関数未使用)
    • FLOW_VALUE_ASSIGNMENT|xxx|$Record|{Id=00U2w000006slhNEAQ,(中略), doukousya__c=, ...(後略)
  • 変更後(LEFT関数使用)
    • FLOW_VALUE_ASSIGNMENT|xxx|$Record|{Id=00U2w000006slhNEAQ,(中略), doukousya__c=null, ...(後略)

つまり、

  • 変数に空文字を代入すると、レコード項目も空文字で更新される
  • 変数にnullを代入すると、レコード項目は更新されない

という動作だったのです。

どうすればよかったのか

そもそも100文字以下の場合はLEFT関数を使用する必要はなかったのですから、「同行者」項目に割り当てる内容を IF(LEN(<作成したテキスト変数>) > 100, LEFT(<作成したテキスト変数>, 100), <作成したテキスト変数>) の数式にすればよかったのです。*1

IF関数を用いた数式に変更した後は、無事空文字更新も行われるようになりました。

おわりに

今回の話は、

  • LEFT関数で空文字の変数を設定すると、nullが返却される
  • nullをフローの割り当てでレコード項目に割り当てると、項目値は変更されない

ということが原因でした。
nullと空文字の違いは初めて知りましたが、今後このようなフローを作るときは気にしないといけませんね。

*1:最初はこちらにすべきか少し悩んだのですが「100文字以下でも動作変わらないからまとめてLEFT関数でいいだろ」と思ったのです

Salesforceサポートで紙での申請が必要なケース

はじめに

Salesforceサポートのやり取りは、基本的にはケース上のコメントで行います。
そのため、個人取引先の有効化のようなリクエストも、ケースを起票して依頼します。

その一方、実はリクエストに紙(PDF)が必要なパターンもいくつか存在します。
今回はそのパターンについて書いてみます。

注:以下の情報は私が把握している範囲で正しい情報を記載していますが、現在の運用が異なっている場合はごめんなさい。その場合は何かしらの方法で連絡いただけますと幸いです。

システム管理者のメールアドレス変更

これは以下の条件を満たす場合にリクエストします。

  • システム管理者アカウントに誰もログインできない
  • システム管理者アカウントに設定されているメールアドレスに届くメールを誰も受信できない
    • つまりパスワードリセット後のメールを誰も受信できない

申請の詳細はSalesforceヘルプ: Salesforce のシステム管理者を変更することができない に記載されています。
注意事項として、この申請を行う際の承認者欄には最高経営責任者レベルの役員(たとえば、CEO、CIO、CFO、または事業主 )の署名が必要になる、という点です*1
なので大企業など、最高経営責任者レベルの役員の押印を頂くのが難しいような会社では、複数名システム管理者を設定するなどして依頼をしないような体制を取ることが大事です。

ちなみに、「システム管理者アカウントに誰もログインできないが、メールは受信できる」場合は上記の申請をしなくても、電話でSalesforceサポートに依頼すればパスワードリセットしてもらえます。*2

ログインIPアドレス制限の解除

これは、システム管理者用プロファイルにログインIPアドレス制限を設定しているが、社内のIPアドレスが変更したなどでシステム管理者が誰もログインできなくなった場合にリクエストします。
リクエスト方法はSalesforceサポートに電話で問い合わせた後に、こちらのファイルに必要事項を記載してメール or FAXで送付する形になります。
ちなみにこれも承認者の欄がありますが、この場合は申請者の上長などで大丈夫です。

ちなみに一般ユーザ用のプロファイルに設定したログインIPアドレス制限のため一般ユーザがログインできなくなっているが、システム管理者がログインできる場合は、システム管理者にてログインIPアドレス制限の解除ができるのでこの申請は不要です。
あくまでSalesforceサポートへのリクエストは「ログインできない原因となっている設定の変更が誰もできない」場合のみ可能、ということです。*3

メールアドレス変更時の確認メール送信を停止

Salesforce上でメールアドレスを変更するときは、通常以下の手順になります。

  • Salesforceでユーザのメールアドレスを変更する
  • 変更前、変更後メールアドレスに確認メールが送信されるので、変更後メールアドレスに届いたメールに記載されたURLにアクセスする

しかし、会社のドメインを変更したなどの理由で全ユーザのメールアドレスの変更が必要になった場合、全ユーザに「Salesforceから届くメールアドレス変更のメールに記載されたURLにアクセスしてください」と伝える必要があり、システム管理者、Salesforceユーザいずれにとっても面倒です。
このような、メールアドレス変更時の確認メール送信を停止してメールアドレス変更を即反映したい場合にこのリクエストを行います。

申請の詳細はSalesforceヘルプ: メールアドレスの変更通知の無効化 に記載されています。
なお、上記ヘルプには「設定変更依頼書」について記載されていませんが、こちらのファイルに必要事項を記載の上、ケースで依頼する流れになります。(ファイルはケースに添付する)
承認者については「ログインIPアドレス制限の解除」同様、申請者の上長などでよいです。

おわりに

上記ケースのうち、「システム管理者のメールアドレス変更」、「ログインIPアドレス制限の解除」が必要なケースではシステム管理者が誰もログインできない状態のため、混乱するかと思います。
そういった場合はSalesforceサポートに電話して、対応策を検討した方がよいでしょう。*4

*1:この申請を行うと申請者がシステム管理者の権限を持つことができるので、Salesforceサポートは通常のリクエストより厳しい制約をつけています

*2:他のシステム管理者がいない、または誰もログインできない状態であることが条件です

*3:反対に一般ユーザはログインできますがシステム管理者がログインIPアドレス制限のためログインできない場合は、一般ユーザはログインIPアドレスの制限を解除できないためSalesforceサポートへの申請ができます。

*4:Basicサポートは緊急度1のみ電話サポート可能と記載されていますが、システム管理者がSalesforceにログインできないなど、ケース起票できない場合は電話を受け付けてもらえます

行動のActivityDateとActivityDateTimeの関係

はじめに

このブログの基となったのはこちらの投稿です。

sf.forum.circlace.com

この投稿を読んだ当時、仕事で行動のActivityDateを利用したプロセスビルダーを作成した頃だったため、

「『終日行動にチェックを入れない → ActivityDateTime に開始時刻が保存される』…?あれ、仕事で作ったプロセスビルダー、終日行動関係なしにActivityDateを条件に使用してたよマズいよ。」

「あれ、でも動作確認では期待通り動作したよな。あれ?」

ということで、詳しく調べてみることにしたのでした。

ActivityDate はいつ保存される?

まず、終日行動にチェックを入れた行動とチェックを入れていない行動を作成し、SOQLで内容を確認します。
すると以下表の通り、ActivityDateは終日行動の内容にかかわらず値が入っていることが分かります。

項目 終日行動=TRUE 終日行動=FALSE
ActivityDate 値あり 値あり
ActivityDateTime 空白 値あり

f:id:mark-hammer:20200830145551p:plain
終日行動とActivityDate, ActivityDateTime の差

(なんだ、やっぱりActivityDateは必ず値が入るんじゃないか)と思いましたが、念のためActivityDateに関する入力規則を作成し、動作を見ることにしました。
すると…、

確かに、ActivityDateだけを見る入力規則では、終日行動のチェックがない行動をスルーしてしまいました。

何故だ、と思いデバッグログで入力規則の判定部分を見ると…、

  • 終日行動のチェックあり
VALIDATION_FORMULA|ActivityDate + 2 <= TODAY()|ActivityDate=2020-08-25 00:00:00
VALIDATION_FAIL
  • 終日行動のチェックなし
VALIDATION_FORMULA|ActivityDate + 2 <= TODAY()|ActivityDate=null
VALIDATION_PASS

終日行動のチェックがない場合、入力規則時点でのActivityDateはnullになっていたため、入力規則がスルーされていました。

ちなみに入力規則に用いる項目がActivityDateTimeの場合、以下の通り終日行動のチェックがない場合のみ判定されます。

  • 終日行動のチェックあり
VALIDATION_FORMULA|ActivityDateTime + 2 <= NOW()|ActivityDateTime=null
VALIDATION_PASS
  • 終日行動のチェックなし
VALIDATION_FORMULA|ActivityDateTime + 2 <= NOW()|ActivityDateTime=2020-08-25 07:00:00
VALIDATION_FAIL

終日行動のチェックがない行動レコードのActivityDateはいつ登録されているのか?

終日行動のチェックがない行動のActivityDateは入力規則判定時点では空でした。
一方、SOQLで検索した場合はActivityDateに値は入っているので、どこかのタイミングで値は入っているはずです。
そこで、フロー、ワークフロー、プロセスビルダーでActivityDateの内容を他項目にコピーするよう設定し、動作を確認してみます。

結果は以下のようになりました。

設定内容 結果
フロー(保存前更新) 空白
フロー(保存後更新) 値が設定される
ワークフロー 値が設定される
プロセスビルダー 値が設定される

これをトリガと実行の順序に当てはめてみると、おそらく「7. レコードはデータベースに保存されますが、まだ確定されません。」の時点でAcitivityDateが登録されているのではないか、という推測ができます。

終わりに

AcitivityDate はSalesforce側が登録する「システム項目」に近いものですが、その登録のタイミングは必ずしも想定と合わない、ということが分かりました。
この投稿が皆様の役に立てれば幸いです。

おまけ

本動作について、行動オブジェクトからのありがたいお言葉をどうぞ。

ありがとうございました。

行動の被招集者をまとめたテキスト項目を作りたい

要件

行動には、「被招集者」という標準項目があります。

f:id:mark-hammer:20200801223946p:plain
行動レコード画面

「被招集者」項目には同じ行動に参加予定のユーザを追加しています。

さて、行動と被招集者をレポート表示する場合、標準レポートタイプの「被招集者が関連する行動」だと、以下のように被招集者の人数分の行ができてしまいます。

f:id:mark-hammer:20200801224206p:plain
「被招集者が関連する行動」レポートタイプの表示

こんな表示はいやだ、下記キャプチャのように行動ごとに被招集者のユーザを一覧できる項目を作ってくれ、というのが今回の要件となります。

f:id:mark-hammer:20200801224431p:plain
期待するレポート表示

具体的な要件

  • 「被招集者」項目に表示されているユーザの氏名をまとめてテキスト項目「同行者」にカンマ区切りで設定してほしい。同行者の並び順は任意とする。
  • 「被招集者」項目に行動任命先ユーザ以外の値を設定していない場合は「被招集者が関連する行動」レポートタイプのレポートには表示されないので、「同行者」項目もそれに合わせ空白とする。
  • 「被招集者」項目にはユーザの他にリード、取引先責任者、リソースも設定できるが、今回はユーザ以外のものは「同行者」項目に反映しない。

「被招集者」項目の内容はどうやって保存されるのか

Salesforce標準オブジェクトの中でも、ToDo、行動は特殊なオブジェクトです。
以下のオブジェクトER図を見てもそれが分かります。(出典元)

f:id:mark-hammer:20200801225237p:plain
ToDo・行動オブジェクトER図

このうち、「被招集者」項目のデータはEventRelationオブジェクトに保存されています。
例えば、ある行動にユーザ、取引先責任者、リード、リソースを保存した場合、以下のように保存されます。

EventId RelationId 備考
00U112222233333AAA 005aaBBBBBcccccZZZ 被招集者のユーザ
00U112222233333AAA 003bbCCCCCdddddYYY 被招集者の取引先責任者
00U112222233333AAA 00QccDDDDDeeeeeXXX 被招集者のリード
00U112222233333AAA 023ddEEEEEfffffWWW 被招集者のリソース

ここで問題は、【「被招集者が関連する行動」レポートタイプのレポートには任命先ユーザも表示されるが、EventRelationオブジェクトには任命先ユーザは入っていない】ことです。
行動を作成すると、「被招集者」項目にはデフォルトで任命先ユーザが入りますが、この任命先ユーザはEventRelationオブジェクトには存在しないのです。

実現方法

以上を踏まえ、要件に合う仕組みを考えると、以下となりました。

  • 要件実現にはEventRelationオブジェクトのデータを取得する必要があるが、プロセスビルダーでは取れないのでフローの利用が必須。
  • フロー処理内容は以下のようにする。
    • 作成/編集された行動オブジェクトのレコードIDに紐づくEventRelationオブジェクトのデータを全て取得する
    • 取得したデータからユーザのデータだけ取り出し、ユーザ氏名を変数に代入する。
    • EventRelationオブジェクトのデータにユーザのデータが1つ以上あった場合は、任命先ユーザ氏名も追加して「同行者」項目を更新する。
    • EventRelationオブジェクトのデータにユーザのデータがない場合は、「同行者」項目を空白で更新する。

作成したフロー

全体図

f:id:mark-hammer:20201123181433p:plain
フロー全体図

EventRelationオブジェクトデータ取得処理部分

f:id:mark-hammer:20201123181516p:plain

当初は「EventRelationオブジェクトのデータからユーザだけ取り出す」処理は、以下の通り最初のレコード取得要素で処理しようと考えていました。

f:id:mark-hammer:20200801231801p:plain

しかし、「ID項目は【次の文字列で始まる(starts with)】は使用不可」というエラーが出て、この方法は不可となりました。*1

f:id:mark-hammer:20200801231922p:plain

最終的に、ここでの条件は「行動レコードIDに紐づくEventRelationオブジェクトのデータを全て取得する」だけにしました。

f:id:mark-hammer:20200801232325p:plain
修正後の条件

EventRelationオブジェクトデータからユーザ情報抽出処理部分

f:id:mark-hammer:20200801232529p:plain

一部文字被りがありますが、ここでの処理は以下です。

  • 前の処理で取り出したRelationIdが005以外から始まる場合はループ要素に戻す。
  • RelationIdが005から始まる場合はユーザオブジェクトから名前(Name)を取り出し、変数に保存する。
  • RelationIdが005から始まるレコードが複数存在する場合は、名前をカンマ区切りでつなぎ合わせる。

ユーザオブジェクトからのレコード取得要素を入れている場合は、RelationIdが複数オブジェクトのレコードを受け入れる仕様のため、RelationId.Name という取り出し方ができないためです。*2

ユーザ情報抽出後処理部分

f:id:mark-hammer:20200801233420p:plain

ここでの処理は、以下となります。

  • 前の処理で名前保存用変数が空白の場合は、「任命先以外に被招集者となったユーザが存在しない」ため、「同行者」項目を空白で更新する。
  • 名前保存用変数が空白ではない場合は、任命先ユーザの名前も追加し、「同行者」項目を変数の内容で更新する。

ToDoの場合は任命先にキューも設定できるため、「任命先がユーザか否か」の決定要素も必要ですが、行動は現状キューが使えないため、決定要素は外しました。

終わりに

改めて、どのオブジェクトレコードも項目値に設定できる項目を持つToDo、行動に対する自動処理を考えるのが難しいことを学びました。
標準オブジェクトのER図も把握した上でデータの取得方法を考えるのはなかなか大変でした。

Trailheadではない、独自の要件からフローを作ったのは今回が初ですが、Flow Builderになってかなり機能拡張され、直感的にわかりやすくなったと思います。
ただ、要素を組み合わせることによる自由度の高さと、複雑さどちらも備える機能のため、使いどころは考えたいと思います。

*1:プロセスビルダーだと「行動の関連先が003から始まる(取引先責任者)」を条件にできますが、フローだとダメなんですね

*2:ループ内にレコード取得要素を入れるのはガバナ制限を考えるとよくないというヒントも表示されましたが、やむなしとしました

コミュニティとSalesforceサポートの使い分け方

はじめに

もう半年以上前になりますが、2019年10月に行われましたてきめし #07『Salesforceビアバッシュ with ライトニングトーク』に「コミュニティとSalesforceサポートの使い分け方」という内容で発表してきました。


発表時間は5分のため、発表資料はかなり内容を省いていますが、ブログで補完していきたいと思います。

※この内容はSalesforceサポートにケースが起票できる(有償アカウントを持っている)人を対象としています。
Developer Edition しかもっていない人はSalesforceサポートは使えないため、コミュニティへの質問となります。

Salesforceに関する分からないことがあった場合の質問先

  • Salesforceの設定してもうまく動かない
  • この機能どう使うのか分からない
  • 社内で聞いても分かる人がいない

こういった場合にどこに質問するのが良いでしょうか。
通常、考えられる質問先は「Salesforceサポートに質問用ケースを作る」か「コミュニティに質問する」だと思います。

なお、コミュニティの場合は日本語と英語で分かれており、主だったものは以下になるでしょう。

では、それぞれプラス点、マイナス点としてどのようなものがあるでしょうか。

コミュニティへの質問のプラス点、マイナス点

プラス点

  • 24時間365日、いつでも回答がつく可能性がある
  • Salesforce MVP からコメントがつくこともある
    • Salesforce MVPとは、コミュニティに大きく貢献し、Salesforce の製品とエコシステムについて深く理解しているとSFDCから認定された方に贈られるものですが、そのような方からコメントがつくこともあります。
  • 他の会社の事例を見ることができる
    • 例えば「商談オブジェクトというのはどのように使えばいいのか」「ToDoと行動をどのように使い分ければいいのか」について、「うちの会社ではこのように使っている/使い分けているよ」という活用例を教えてもらえる場合があります。
  • Apex、Visualforce、Lightning Component などの開発に関する質問も答えてもらえる。
    • Salesforceサポートの場合、開発に関する質問はプレミアサポートが必要ですが、コミュニティの場合はそのような制限はありません。
      またTrailbrazer Community の質問広場 グループを見ると、結構開発者から回答がつくことが多い印象を受けます。

マイナス点

  • 回答が全くつかない可能性がある
    • 一番のマイナス点はこれになるでしょう。数十分で回答がつく質問がある一方で、1週間以上たっても回答がつかない質問も珍しくはありません。
    • 印象としては、AppExchangeの特定パッケージに関する質問、他システムとの連携に関する質問は回答がつきにくいと思います。
  • 設定の詳細が分からないので、的外れの回答になる場合がある
    • 例えば「プロセスビルダーが思った通り動かない」という質問があった場合、原因として「『有効化』を忘れた」「プロセスビルダーの開始条件を満たしていない」など単純なものもあれば、「他Apexトリガ、プロセスと干渉している」といった複雑なケースもあります。
      このような場合に、自分の全ての設定を質問文の中に書くのは難しいので、結果として的外れの回答が返ってくる可能性があります。

Salesforceサポートへの質問のプラス点、マイナス点

プラス点

  • 必ず何らかの回答が返ってくる
    • ただし、前述のAppExchangeの特定パッケージに関する質問、他システムとの連携に関する質問は「サポート範囲外です」となってしまうかもしれません。
  • 組織設定や実際の動作を見て回答してもらえる
    • Salesforceサポートは、ログインアクセスを付与することで組織設定や実際の動作を確認することができます。
      これにより、前述の「プロセスビルダーが思った通り動かない」という質問も、実際にプロセスビルダーやその他設定、また問題が発生している編集を実際に行っての動作確認を行うことができます。
  • 機能の問題が原因の場合、改善してもらえる(かも)
    • サポート問い合わせの結果、機能の修正が必要となった場合は修正対応が行われます。
      また、既知の問題としてKnown Issuesに掲載されることがあります。
    • なお、後日「修正なし」と判定されることもあります。

マイナス点

  • 平日営業時間以外は回答をもらえない
    • 例えば、土日にサポートから連絡が来ることはプレミアサポートの緊急ケース以外ありません。
      土日に確認したいことがある場合は、コミュニティへの質問も選択肢に入るでしょう。(運が良ければ答えてくれるかもしれません。)
  • ユーザ事例については回答しない
    • Salesforceサポートは他のユーザがSalesforceをどのように使っているかは回答しません。
      ユーザ事例を確認したい場合はコミュニティの他、イベントへの参加を検討した方がよいでしょう。

具体的な質問例

コミュニティへの質問例としては、以下がよいと思います。

  • 簡単な機能に関する質問
  • 他の会社がオブジェクトや機能をどう使っているか?という質問

一方、以下のような不具合系の質問はSalesforceサポートの方がいいでしょう。

  • バージョンアップ後から動作がおかしい
  • リンクをクリックすると、白い画面に”〇〇Error”(例: Internal Server Error)が表示されます

おわりに

コミュニティとSalesforceサポート、どちらもプラス点、マイナス点があります。
それぞれが得意とする質問内容を知ることで、より早い問題解決につなげることができれば幸いです。

ちなみに、Salesforceサポートは、アンケートの高評価とコメントが大好きです。
「いい対応をしてもらえた」と思ったら、アンケートに高評価をつけてあげてください。

Community Cloud でのURLパラメータを用いたレポート絞り込み

はじめに

Lightning Experienceでは、URLパラメータを用いたレポート絞り込みは以下の流れで設定します。(公式ヘルプ)

  • レポートに対し、事前に絞り込み対象項目を設定する。
  • URLパラメータ fvX (Xには数字が入る) を設定したURLを用いて、レポートにアクセスする。

しかし、Community Cloudのレポート画面にてURLパラメータ fvX を設定しても、パラメータの内容は無視されます。

レポートで、商談のフェーズが"Closed Won"である商談を絞り込み表示する場合、URLパラメータ fvXを使うと

https://apXX.lightning.force.com/lightning/r/Report/00Oxxxxxxxxxxxx/view?fv0=Closed%20Won

となります。

一方、Community Cloudでのレポート表示URL末尾に?fv0=Closed%20Wonを追加しても、「商談のフェーズが"Closed Won"」の絞り込み条件は追加されません。

Community Cloud でのレポート絞り込み

Community Cloud でURLパラメータを用いたレポート絞り込みをする場合は、reportFiltersパラメータを使用します。
reportFiltersは以下3項目で構成されています。

  • column: 絞り込み項目名
  • operator: 演算子
  • value: 値

例えば、「フェーズが"Closed Won"と一致する商談」が条件の場合は以下のように指定します。

?reportFilters=[{"column":"STAGE_NAME","operator":"equals","value":"Closed Won"}]

また、「完了予定日が2020/8/1以降、かつ確度が50%未満の商談」が条件の場合は以下のように指定します。

?reportFilters=[{"column":"CLOSE_DATE","operator":"greaterOrEqual","value":"2020-08-01"},{"column":"PROBABILITY","operator":"lessThan","value":"10"}]

column の指定方法

先述した例の通り、columnで指定する項目名はAPI参照名とは微妙に異なっています。なので設定画面を見ても分かりません。
これを開発者コンソールで調べる方法は以下の通りです。

  • まず、columnで指定したい項目をレポート検索条件、またはレポート表示項目に指定したレポートを作成して、保存します。その時、URLからレポートIDを取得します。
    • レポート検索条件の値は何でもよいですが、後で確認しやすいよう、特定しやすい値にすることをお勧めします。
  • 開発者コンソールを開き、Debug->Open Execute Anonymous Window (または Ctrl+Eキー) でApexコード実行画面を開きます。
  • 以下Apexコードを入力し、[Execute]をクリックします。
String reportId = '<レポートID>'; 

Http http = new Http();
       HttpRequest httpReq = new HttpRequest();
       HttpResponse httpRes = new HttpResponse();      
       httpReq.setMethod('GET');
       httpReq.setHeader('Authorization', 'Bearer ' + UserInfo.getSessionId());
       httpReq.setEndpoint(
           URL.getSalesforceBaseUrl().toExternalForm()+
           '/services/data/v47.0/analytics/reports/' + reportId +
           '?includeDetails=true'
       );
       httpRes = http.send(httpReq);
       System.debug(httpRes.getBody());
  • 画面下のLogsタブに実行ログが表示されるので、右クリックし[Open Raw Log]をクリックします。
  • DEBUGログの中から「reportFilters(対象項目をレポート検索条件に指定した場合)」、または「detailColumns(対象項目をレポート表示項目に指定した場合)」を探し、対象項目のcolumn指定値を確認します。
    • reportFiltersの場合は、先述の通り"value"に検索条件の値が記録されるため、この値で対象項目を含む条件を判別できます。
    • detailColumnsの場合は、レポート項目表示順に項目が並びます。

operator の指定方法

レポートで使用可能な演算子と、reportFiltersで指定するoperatorの関係は以下表の通りです。

レポートの演算子 対応するoperator
次の文字列と一致する equals
次の文字列と一致しない notEqual
< lessThan
> greaterThan
<= lessOrEqual
>= greaterOrEqual
次の文字列を含む contains
次の文字列を含まない notContain
次の文字列で始まる startsWith

カスタムリンクを用いた Community Cloud でのレポート絞り込み

これまでは検索条件の値が固定の場合を考えてきましたが、実際はレコードの値に沿って検索条件を指定したい場合が多いと思います。
この場合はカスタムリンクを使って指定しますが、fvXパラメータとは違い必要な書式に記号を含むため、事前に記号をURLエンコードする必要があります。
手順は以下のようになります。

  • reportFiltersで指定する条件を書式に合わせて書き出します。この時、value部分は適当な文字列で埋めます。
    • 「フェーズが表示している商談と一致する」が条件の場合は、[{"column":"STAGE_NAME","operator":"equals","value":"AAAAAAA"}] とします。
  • 書きだした文字列をURLエンコードします。方法は外部サイトを用いる、コマンドプロンプトでコマンド実行するなどありますが、必ずUTF-8形式でエンコードしてください。
    • 先の例の場合は %5B%7B%22column%22%3A%22STAGE_NAME%22%2C%22operator%22%3A%22equals%22%2C%22value%22%3A%22AAAAAAA%22%7D%5D となります。
  • value部分の文字列を消し、カスタムリンクの差し込み項目に差し替えます。
    • 先の例の場合は「AAAAAAA」を「{!Opportunity.StageName}」に差し替え、%5B%7B%22column%22%3A%22STAGE_NAME%22%2C%22operator%22%3A%22equals%22%2C%22value%22%3A%22{!Opportunity.StageName}%22%7D%5D となります。
    • URLエンコード後に差し込み項目に差し替える理由は、カスタムリンクURLの差し込み項目は「{!Opportunity.StageName}」の形を保つ必要があり、差し込み項目設定後にURLエンコードをしてしまうと項目値が差し込まれない(「{!Opportunity.StageName}」の文字列がそのまま検索条件として使用される)ためです。
  • 対象コミュニティのURL、対象レポートID、先に作成した検索条件から、カスタムリンクURLを /<コミュニティURL>/s/report/<レポートID>?reportFilters=<先に作成した検索条件> のように指定します。
    • 対象コミュニティURLが /sampleCommunity の場合は /sampleCommunity/s/report/00Oxxxxxxxxxxxx/?reportFilters=%5B%7B%22column%22%3A%22STAGE_NAME%22%2C%22operator%22%3A%22equals%22%2C%22value%22%3A%22{!Opportunity.StageName}%22%7D%5D のようになります。
  • 作成したカスタムリンクをページレイアウトに配置します。

追記

reportFiltersを用いた検索条件の指定は、Lightning Experience でも可能です。
Lightning Experience の場合、 カスタムリンクのURLに /lightning/r/Report/00Oxxxxxxxxxxxx/view?reportFilters=%5B%7B%22operator%22%3A%22equals%22%2C%22value%22%3A%22{!Opportunity.StageName}%22%2C%22column%22%3A%22STAGE_NAME%22%7D%5D と指定すれば、事前にレポートへ検索項目を設定しなくても、好きな項目で検索条件を指定できます。

Appendix

Salesforce Report Parameters in a Community URL | Salesforce Chris

Data connector for Salesforce でカスタムロングテキストエリア項目の内容が切れる

はじめに

Salesforceのデータを Google スプレッドシートに表示、及び編集することが可能なData connector for Salesforce。 具体的な使用方法はこちらを参考にしていただければと思いますが、今回は某所で質問を受けた、Data connector for Salesforce でロングテキストエリア項目を出すための方法を書いていきます。

Salesforce レポートでのロングテキストエリア項目の制約

まず、今回の前提となる「Salesforce レポートでロングテキストエリア項目はどう表示されるか」書いていきます。

レポートにおけるロングテキストエリア項目の制限は、ヘルプには以下のように書かれています。

レポートには、リッチテキストエリアまたはロングテキストエリアの最初の 999 文字が表示されます。レポートをダウンロードしたら、すべての項目を使用できるようになります。

一方、カスタムロングテキストエリア項目の場合、レポートに表示される文字数は255文字まで*1となります。
この動作については、改善要望がIdeaExchangeに上がっていますが、Not Plannedとなっており、改善の見込みがありません。*2

Data connector for Salesforce でのロングテキストエリア項目の動作

Data connector for Salesforce では、レポートのデータをGoogle スプレッドシートに出力することができます。
しかし、Data connector for Salesforce による出力は、データローダのような「項目の値をそのまま出力する」ではなく「レポートの表示のまま出力する」動作のため、255文字以上は表示されません。

下の画像は、同じ文字列を「説明」項目とカスタムロングテキストエリア項目に設定し、レポートとData connector for Salesforce経由で出力した画面です。

f:id:mark-hammer:20200611142827p:plain
「説明」項目とカスタムロングテキストエリア項目のレポート表示

f:id:mark-hammer:20200611145845p:plain
「説明」項目とカスタムロングテキストエリア項目のスプレッドシート表示

今回出した改善案

相談内容は、「取引先にロングテキストエリア項目を作成しており、その内容をData connector for Salesforce でGoogle スプレッドシートに出力したいが、スプレッドシート上では途中で切れる」というものでした。

確認したところ、上記のカスタムロングテキストエリア項目の動作は変更の余地がないため、「取引先の標準ロングテキストエリア項目である『説明』項目を代用できないか」とお伝えしました。
先ほどのキャプチャの通り、「説明」項目は標準ロングテキストエリア項目のため、255文字制限ではなく999文字制限が適用され、表示数が増えます。

おわりに

今回は Data connector for Salesforce の動作に関する質問から、標準項目とカスタム項目でのロングテキストエリア項目の差を知ることができました。
この内容はヘルプに書いておいてもいいなと思ったのですが、探した範囲では先述したIdeaExchangeしか見つけることができませんでした。
この内容が皆様の参考になれば幸いです。

*1:253文字以上の場合は「...」を含めて255文字とする動作のため、全文字が表示されるのは項目値が252文字以下の場合となります。

*2:Salesforce公式ヘルプでは、Not Plannedは「短期または長期の実装計画に含まれず、将来の実装計画が変更されない限り、そのアイデアに対するそれ以上の更新はない」ものとなります。

Trailhead モジュール:Einstein Analytics and Discovery 認定資格の更新 (Spring '20)

※この内容は2020/5時点のものです。

Spring '20 の Einstein Analytics の新機能の学習

https://trailhead.salesforce.com/ja/content/learn/modules/einstein-analytics-and-discovery-certification-maintenance-spring-20/learn-whats-new-for-einstein-analytics-in-spring-20

  • 説明:日本語
  • Challenge:日本語選択問題

フォーマッティングと通知のハンズオン

https://trailhead.salesforce.com/ja/content/learn/modules/einstein-analytics-and-discovery-certification-maintenance-spring-20/get-handson-with-formatting-and-notifications

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

【Challenge要約】

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

  • 事前に、Einstein Analytics 開発組織にサインアップしてください。
  • Analytics Studio で以下の通り空白のダッシュボードを作成してください。
    • タイトル:Opportunities Analysis
    • アプリケーション:Shared App
  • DTC Opportunity Dataset を使い、以下の通り新しいクエリを作成してください。
    • クエリ表示ラベル:OppQuery
    • グラフ:横棒
    • 横棒:Industry
    • 棒の長さ:Amount 合計
      • 数値を書式設定:「カスタム」を選び、以下の通り設定してください。
        • 形式:£#,###.00
        • 1000:.
        • 小数点:,
  • 以下の通り、新規通知を作成してください。
    • 条件
      • 項目:Amount合計:
      • 条件:次の値より大きい
      • 値:30000000
    • 受信者:自分と他の任意のユーザ

注意:Challenge成功後、不要なメールを受け取らないために作成した通知は削除してください。

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

※この内容は2020/5時点のものです。

Spring '20 の新機能の学習

https://trailhead.salesforce.com/ja/content/learn/modules/administrator-certification-maintenance-spring-20/learn-whats-new-in-spring20

  • 説明:日本語
  • Challenge:日本語選択問題

権限セットグループのハンズオン

https://trailhead.salesforce.com/ja/content/learn/modules/administrator-certification-maintenance-spring-20/get-handson-with-permission-set-groups

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

【Challenge要約】

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

  • 以下の通り、ケース用の権限セットを作成してください。
    • 表示ラベル:Case Read Only
    • API参照名:Case_Read_Only
    • ケースオブジェクト権限:「参照」のみチェックを入れる
    • 項目:以下項目に対し、「参照アクセス権」のみチェックを入れる
      • 取引先名
      • 原因
      • 説明
  • 以下の通り、リード用の権限セットを作成してください。
    • 表示ラベル:Manage Leads
    • API参照名:Manage_Leads
    • リードオブジェクト権限:「編集」にチェックを入れる
    • アプリケーション権限:「リードの取引の開始」、「リード所有者の移行」にチェックを入れる
  • 以下の通り、権限セットグループを作成してください。
    • 表示ラベル:Sales Ops
    • API参照名:Sales_Ops
    • 「グループ内の権限セット」から、権限セット「Case Read Only」、「Manage Leads」をグループに追加してください。