行動のActivityDateとActivityDateTimeの関係

はじめに

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

sf.forum.circlace.com

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

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

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

ActivityDate はいつ保存される？

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

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

終日行動と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側が登録する「システム項目」に近いものですが、その登録のタイミングは必ずしも想定と合わない、ということが分かりました。
この投稿が皆様の役に立てれば幸いです。

おまけ

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

行動「ActivityDateに日付は入れる。入れるが…今回 まだその時と場所の指定まではしていない。そのことをどうか諸君らも思い出していただきたい。つまり…我々がその気になれば、入力規則判定後にActivityDateTimeからActivityDateへ日付をコピーすることも可能だろう…ということ…！」

— Mark Hammer (@Mar9Hammer) 2020年8月20日

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

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

要件

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

行動レコード画面

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

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

「被招集者が関連する行動」レポートタイプの表示

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

期待するレポート表示

具体的な要件

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

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

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

ToDo・行動オブジェクトER図

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

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

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

実現方法

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

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

作成したフロー

全体図

フロー全体図

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

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

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

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

修正後の条件

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

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

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

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

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

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

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

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

終わりに

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

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

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

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

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

はじめに

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

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

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

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

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

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

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

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

• 日本語
  • Trailbrazer Community の質問広場 グループ がメインになります。
• 英語
  • Trailbrazer Community のAnswers
    • 日本語でもOKですが、日本語の質問に対する回答はあまり活発でない印象です。
  • Salesforce 開発者コミュニティ の Forums
    • こちらも日本語でもOKですが、日本語の質問に対する回答はあまり活発でない印象です。
  • Salesforce Stack Exchange

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

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

プラス点

• 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経由で出力した画面です。

「説明」項目とカスタムロングテキストエリア項目のレポート表示

「説明」項目とカスタムロングテキストエリア項目のスプレッドシート表示

今回出した改善案

相談内容は、「取引先にロングテキストエリア項目を作成しており、その内容を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」をグループに追加してください。

認定デベロッパー試験受験記（Admin向け）

TL; DR

• Admin側の知識に自信があるがDev側は自信がない人は、Admin向けの問題は全問正解するつもりでいきましょう。
• コードを書く試験ではないですが、Trailheadの認定デベロッパー試験向けTrailmixは一通り進めることをおすすめします。
• Apex、Visualforce、Lightning Web Componentのコード記述、デプロイに自信がない人は、ある程度できるようになってから受験したほうがいいかも。

はじめに

Salesforce認定デベロッパー試験。
Salesforce開発者向けの試験であることはもちろんですが、認定テクニカルアーキテクトの前提資格となる認定システムアーキテクト、認定アプリケーションアーキテクト両方の取得必須資格でもあります。

認定テクニカルアーキテクトは、最近は #JourneyToCTA というハッシュタグとともに Salesforce Architect Group が活動を行っている他、Dreamforce2019では "Become a Salesforce Architect without a Developer Background" の発表も行われており、開発者だけでなくシステム管理者(Admin)も目指せる目標となっています。
認定テクニカルアーキテクトを取得したいシステム管理者(Admin)にとって認定デベロッパー試験は、開発者向け知識を問われる最初の関門でもあります。

2019年8月、私は力試しとして受験したSalesforce認定デベロッパー試験に合格しました。

I passed Salesforce Certified Platform Developer I exam!
Hooray! pic.twitter.com/25EGvEd14K

— Mark Hammer (@Mar9Hammer) 2019年8月18日

ちなみに私は以前の仕事で扱っていた関係上Salesforce管理者側（標準機能）の知識はありますが、開発者側の知識は主にTrailheadでの自習で身につけていました。
今回は仕事でSalesforce開発（Apex、Visualforce、Lightning [Aura/Web] Component）をしない人向けに、認定デベロッパー試験について書いていきます。

受験記

受験前の準備

当時は Trailhead で 600 バッジ程度取得しており、さらに Apex Specialist と Data Integration Specialist を取得しました。

ただ、その後は特にコードを書くことはありませんでした。

試験結果

受験結果で確認できる各分野の正答率、及び正答率から予想できる問題数、正答数が以下の表になります。
ちなみに受験ガイド(PDF)では問題数60問、合格点は65%（=39問正解）と記載されています。

分野	割合	正答率	問題数(予想)	正答数(予想)
Salesforceの基本	10%	100%	6	6
データモデリング及び管理	12%	71%	7	5
ロジックとプロセスの自動化	46%	44%	29	13
ユーザインターフェース	10%	83%	6	5
テスト	12%	85%	7	6
デバッグツールとリリースツール	10%	80%	5	4
合計	100%		60	39

結果は、予想正答数＝合格点という、本当にギリギリの合格でした。
受験時は本当に不合格を確信しており、分からなかった問題をメモして、次回の受験に備えていましたので、終了ボタンを押して「合格」が表示されたときは本当に驚きました。

各分野の内容

以下、認定デベロッパー受験ガイドを参考に記載しております。

認定デベロッパー出題分野と、私が考える傾向は以下の通りです。

分野	傾向
Salesforceの基本	システム管理者 / 開発者向け
データモデリング及び管理	システム管理者向け
ロジックとプロセスの自動化	システム管理者 / 開発者向け
ユーザインターフェース	開発者向け
テスト	開発者向け
デバッグツールとリリースツール	開発者向け

以上の傾向、及び実際に受験した感想から、Adminが認定デベロッパーを取ろうとするのであれば以下がアドバイスとなります。

• Admin向けの問題は絶対落とさないようにしましょう。
  • 具体的には「各種リレーション（主従関係、参照関係）の違い」「数式項目で扱う関数」「積み上げ集計項目」「ワークフロー/プロセスビルダー」などがあげられます。
• Dev向けの問題はTrailheadのモジュール、プロジェクトをやりながら手順、関数を覚えていきましょう。
  • 実際にコーディングをする必要はないですが、開発者コンソールのメニュー名や各種関数名など、丸暗記では非常に厳しいです。

資格維持に向けて

Salesforce認定アドミニストレータ、認定Platformアプリケーションビルダー同様、認定デベロッパーもリリースごとに資格更新を行う必要があります。
以前はWebAssessorでの選択式試験でしたが、現在はTrailheadにて対象モジュールをクリアし、バッジを取得することで資格更新となります。 なお、Winter'19より認定デベロッパーにはコード記述を含むハンズオンが含まれるため、現在の認定デベロッパーは「コードを書けなくても合格はできるが、コードを書けないと維持ができない」資格になっています。

そして、現在最新（Winter'20）となる認定デベロッパー資格更新モジュールのハンズオンは、Lightning Web Componentを使ったカスタムタブの実装がテーマとなっています。
「現在システム管理者側だけど、テクニカルアーキテクトになるために認定デベロッパーを受験しようかな」とお考えの方には、ぜひ一度認定デベロッパー資格更新モジュールのハンズオンをやってみて、資格更新できそうか試していただくことをお勧めします。

ちなみに私は認定デベロッパー試験前に資格更新モジュールのハンズオンをやっており、「資格更新できそうだ」と思ったので受験した背景もあります。
ただそれまで Apex や Lightning Aura Component、つまり開発者コンソールで対応できたものから Lightning Web Component （現在開発者コンソールで開発不可） にテーマが変わったことは衝撃を受けました。
新しい言語、開発手法についていくことも、認定デベロッパー資格維持には必要となります。

おわりに

認定デベロッパー試験を受験してみて思ったのは、「かなり難しかった」という感想です。
これまでコード実装をそれほど行っていないAdminが認定デベロッパー試験に合格するには、「今まで知らなかった範囲をどれだけ勉強することができるか」これに尽きます。
ただ、「今まで知らなかった範囲をどれだけ勉強することができるか」はどの分野でもあるため、CTAを目指すAdminの方にはぜひ頑張っていただきたいです。

MetadataComponentDependency クエリを使ってみた

※この記事は Salesforce 開発者向けブログキャンペーンへのエントリー記事です。

はじめに

2020/2にリリースされた Spring'20。
今回はSpring'20にリリースされた開発者向け機能のうち、MetadataComponentDependency クエリを触ってみました。

内容

以下、リリースノートより抜粋。

多くの組織には、使用しなくなったさまざまなメタデータコンポーネント (カスタムオブジェクトや項目など) が散乱しています。Tooling API の MetadataComponentDependency オブジェクトを使用する Dependency API 機能を使用して、組織内のメタデータコンポーネント間の連動関係を表示できます。この情報を基に、コンポーネントを削除しても問題ないかどうかを判断することができます。コンポーネント間で連動関係を見つければ、メタデータをパッケージに分割する場合にも役立ちます。単一の組織を操作する代わりにパッケージのセットを操作することで、変更の管理やバージョン管理の使用、継続的インテグレーションシステムの使用が容易になります。

簡単にいうと、Winter'20で正式リリースとなった項目の参照の確認をAPI経由でも利用可能になった、と理解しています。

実際に利用してみる

それでは、実際にSOQLを実行してみましょう。
MetadataComponentDependency クエリを管理者コンソールから実行する際は、「Use Tooling API」を有効にする必要があります。
今回はキャンペーンメンバーオブジェクトのカスタム項目を対象にしています。

SELECT MetadataComponentId, MetadataComponentName, MetadataComponentType, RefMetadataComponentName, RefMetadataComponentType, RefMetadataComponentId
FROM MetadataComponentDependency
WHERE RefMetadataComponentId = '00N2800000FHCbbEAH'

SOQL実行結果

ちなみに、この時指定した項目のページで「使用場所」ボタンをクリックすると以下の通り、SOQLと同様の結果が表示されます。

「使用場所」ボタンクリック時

使い道を考えてみる

上記のように、 RefMetadataComponentId にカスタム項目を指定した場合は「使用場所」ボタンを押したときと同じ結果が得られる（リンクがある「使用場所」ボタンの方が使い勝手がよい）のですが、反対に MetadataComponentId を指定してみます。
以下例では、先ほどの結果で得られた使用場所のうち「キャンペーンメンバー複数選択」プロセスビルダーのIDを RefMetadataComponentId に指定しています。

SELECT MetadataComponentId, MetadataComponentName, MetadataComponentType, RefMetadataComponentName, RefMetadataComponentType, RefMetadataComponentId
FROM MetadataComponentDependency
WHERE MetadataComponentId = '301280000006oNVAAY'

特定のプロセスビルダーで使用されているカスタム項目をチェック

こうすると、特定のプロセスビルダーで使用されているカスタム項目一覧を取得できました。
今回は2項目だけですが、例えば複雑になったプロセスビルダーやフローで、どの項目が使用されているか知りたくなった時に、要素1つずつチェックせずとも使用項目一覧が確認できる、とは言えると思います。

ちなみに、「ID確認は難しいのでプロセスビルダー名を指定すればもっと使いやすくなるのではないか」ということで以下のようなSOQLを指定してみます。

SELECT MetadataComponentId, MetadataComponentName, MetadataComponentType, RefMetadataComponentName, RefMetadataComponentType, RefMetadataComponentId
FROM MetadataComponentDependency
WHERE MetadataComponentType = 'Flow' AND MetadataComponentName = 'キャンペーンメンバー複数選択'

すると、以下のようにエラーが返ってきます。

MetadataComponentName 指定時エラー

これは、リリースノートにも書いてあるように、MetadataComponentName はWHERE句指定のサポートをしていないことが原因です。

次のクエリはサポートされていません。
(中略)
- SOQL WHERE 句 — MetadataComponentName を使用した任意の検索条件の種別

おわりに

今回は、Spring'20にリリースされた開発者向け機能のうち、MetadataComponentDependency クエリについていろいろSOQLを実行して試してみました。
現時点では、MetadataComponentDependency クエリによる SOQL の結果を得るには対象コンポーネントのIDが必要となるため、使いどころは限られる機能といった印象を受けました。
今後、MetadataComponentName や RefMetadataComponentName 、また利用可能な演算子の拡張があれば、WHERE句による幅広い検索が可能となるため、今後のアップデートに期待したいところです。

Lightning ExperienceでレポートエクスポートをURL指定で実現する（Spring'21版）

Spring'21 リリースノート にて、レポート詳細エクスポートの選択肢に xlsxエクスポートが追加されました。
ここでは、Spring'21 Lightning環境でのURLアクセスによるレポートエクスポート方法を記述します。

Lightning環境でのレポートエクスポート

Lightning環境でレポートエクスポートを行う場合、「フォーマット済みレポート」と「詳細のみ」の2パターンが存在します。

フォーマット済みレポート

詳細のみ

• フォーマット済みレポート
  • Lightningレポート画面に表示される画面のフォーマットに沿って表示される。(列グルーピング、ソート順、検索条件も表示される。グラフは表示されない。)
  • 出力形式は.xlsx固定。文字コード指定不可。
• 詳細のみ
  • 従来のレポートエクスポート同様、レポートの詳細行を出力する。
  • 出力形式は .xlsx、.xls、.csv。xls、csvは文字コードも指定可。

レポートエクスポート用URL

フォーマット済みレポート

https://[your_instance_name].lightning.force.com/servlet/PrintableViewDownloadServlet?isdtp=p1&reportId=[your_report_Id]

「Lightning環境でのレポートエクスポート」節の通り、出力形式は.xlsx固定です。

Appendix

Custom Link to Download/Export Detail Report in Lightning - Salesforce Stack Exchange

詳細のみ(xlsx)

https://[your_instance_name].lightning.force.com/servlet/PrintableViewDownloadServlet?isdtp=p1&reportId=[your_report_Id]&detailsOnly=true

詳細のみ(xls、csv)

https://[your_instance_name].salesforce.com/[your_report_Id]?isdtp=p1&export=Export&enc=MS932&xf=localecsv&skipFooter=true

パラメータ

• export
  • おそらくエクスポートを実行することを表すパラメータと思われます。
    SalesforceのGUIから実行した場合の値は export=Export ですが、 export= のみとした場合でもエクスポートは実行できるようです。
    ただし、このパラメータを外した場合はエクスポートできないため、必須パラメータとなります。
• enc
  • エンコード指定となります。
    指定しない場合でもエクスポートは可能です。
• xf
  • エクスポートファイル形式の指定となります。
  • SalesforceのGUIにて.xls形式を選んだ場合は xf=xls、.csv形式を選んだ場合は xf=localecsvが指定されます。
  • xf=csvでもcsvファイルがエクスポート可能です。
  • xfパラメータを指定しない場合はcsvファイルがエクスポートできます。
• skipFooter
  • エクスポートファイルの行末にフッタを付与するか否かを指定する項目となります。（skipFooter=trueの場合はフッタなし）
  • SalesforceのGUIからエクスポートを実行した場合はskipFooter=true(フッタなし)となります。
  • skipFooterパラメータを指定しない場合はフッタありとなります。