Mark Hammer's Blog

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

Trailhead モジュール:Flow Troubleshooting

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

Review Flow Terminology and Sign Up for a Special Org

https://trailhead.salesforce.com/ja/content/learn/modules/flow-troubleshooting/review-flow-terminology-and-sign-up-for-a-special-org

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

【Challenge要約】

Fix Access Issues in a Flow

https://trailhead.salesforce.com/ja/content/learn/modules/flow-troubleshooting/fix-access-issues-in-a-flow

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

【Challenge要約】

重要:このチャレンジを完了するには、最初のユニットでサインアップした本モジュール用 Developer Edition 組織を使用してください。通常の Trailhead Playground 組織ではこのチャレンジを完了することはできません。

  • 事前にプロセスの自動化設定にて、「システム管理者が他のユーザとしてフローをデバッグできるようにする」を有効にしてください。
  • 「ケースを作成」フローを確認してください。
  • 以下内容でフローをデバッグしてください。
    • 別のユーザとしてフローを実行 にチェックを入れ、ユーザにMario Cruz*1を指定
    • あなた自身の情報を画面フローの各項目に入力してください
  • フローのエラー結果を確認してください。
  • ユーザ:Mario Cruzでもこのフローが実行できるよう、適切な権限を付与してください。
  • ユーザ:Mario Cruzへの権限付与後、再度以下内容でフローを実行し、成功することを確認してください。
    • 実行ユーザ:Mario Cruz
    • 名:Avi
    • 姓:Green
    • 電話番号:(212) 842-5500
    • ケース件名:Broken Laptop
    • ケースの詳細:Faulty power button

Fix Issues Caused by a Null Value in a Flow

https://trailhead.salesforce.com/ja/content/learn/modules/flow-troubleshooting/fix-issues-caused-by-a-null-value-in-a-flow

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

【Challenge要約】

  • 「Alert Acct Owner of New Case Added」フローを有効化してください。
  • 取引先、取引先責任者を関連付けせずにケースを作成してください。
  • フローのエラー内容を確認してください。
  • フロー内のケースオブジェクトに条件の要件を追加して、エラーの原因を修正してください。
  • 以下内容で新規ケースを作成し、フローが成功することを確認してください。
    • 状況:New
    • 発生源:Phone
    • 件名:Server Offline
    • その他の項目はそのままにしてください。

*1:ユーザ地域が日本の場合、「Cruz Mario」と表示されます。以下同様。

Spring'21から使えるダッシュボードのURLパラメータフィルターの制約がレポートより厳しい話

はじめに

本投稿の基となったのはこちらの投稿です。(お役立ちコンテンツの数々、いつも見ております。) sf.forum.circlace.com

簡単に言うと、Spring'21からダッシュボードもレポート同様、URLパラメータによるフィルター指定ができるようになった、とリリースノートにはあるのですが、期待通り動作しないという話です。

Spring'21 リリースノート:検索条件 URL パラメータを使用したダッシュボードの結果の保存 より

Lightning Experience でダッシュボードを表示するたびに、同じ検索条件を設定する必要はありません。検索条件パラメータを含むカスタム URL を作成します。これにより、URL にアクセスしたときに、検索条件がすでに設定された状態でダッシュボードが開きます。たとえば、各取引先に異なる URL を使用して商談フェーズダッシュボードをカスタマイズしたり、取引先所有者またはリードソースのカスタム URL を作成したりできます。

最初に見たときは Idea Exchange でも「プレリリース環境で動かない」という投稿があったので未リリースなのかな、と思ったのですが、その後Salesforce担当者から使えるようになったとの投稿がありましたので、実際の動作を調べてみました。

実際の動作

結論から言うと、ダッシュボードのURLパラメータによるフィルターはリリースノート通りに動くのですが、レポートより制約が強い形でした。
具体的な動作の差は以下の通りです。

  • レポート
    • 検索条件の値の部分をfv0, fv1, ...パラメータで指定する。fv0=...の値の部分は何を入れてもよい。*1
  • ダッシュボード
    • 検索条件の値の部分をfv0, fv1, ...パラメータで指定する。fv0=...の値の部分はダッシュボードで設定した検索条件値しか許可されない。それ以外の値を入れると "This filter URL is invalid." エラーになる。

動作確認

以下は2021/2/1時点のSpring'21プレリリース環境で試しています。

レポートの場合

まず、フェーズと取引先名を検索条件としたレポートを作成します。

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

このレポートのURLに、 &fv0=Closed%20Won&fv1=Edge を追加すると、以下のようにURLパラメータを検索条件に反映したレポートが表示されます。

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

ダッシュボードの場合

ダッシュボードの場合、まず編集画面で検索条件を設定します。
ここでは、以下2つの条件を設定します。

  • フェーズ:「"Prospecting"と一致する」、「"Qualification"と一致する」の2つ
  • 取引先名:「"United"を含む」の1つ

フェーズの検索条件設定

取引先名の検索条件設定

次に、ダッシュボードのURLに&fv0=Prospecting&fv1=United を指定すると、指定された検索条件に沿ったダッシュボードが表示されます。

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

一方、ダッシュボードに設定していない検索条件、例えば&fv0=Closed%20Wonを指定すると以下のように "This filter URL is invalid. Please try again." が表示されます。

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

&fv0=Closed%20Won を指定したい場合は、事前にフェーズの検索条件に Closed Won を追加する必要があります。

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

おわりに

ダッシュボードのURLパラメータフィルターは確かに使えるようにはなっていましたが、レポートほどの自由度はありませんでした。
これは複数のコンポーネントを制御するダッシュボードでは、レポートほどの自由度を持たせることができなかったからかもしれません。
とは言っても検索条件さえ設定すれば期待通り動作しますので、従来より使いやすくなったとは言えるでしょう。

*1:スペースを"%20"に、といったパーセントエンコーディングは必要です

カスタム項目の作成日をまとめて取得したい

今回は、会社で依頼された「特定オブジェクトにあるカスタム項目の作成日を一覧化してほしい」という要望について手順を追って記載いたします。

f:id:mark-hammer:20210201013401p:plain
黄色線の部分を各項目ごとに取得したい

全体の手順

  • 開発者コンソールを起動し、CustomFieldオブジェクトからSOQLにて項目作成日を取得
  • 開発者コンソールのSOQL結果をコピーし、Excelに表形式で貼り付け
  • 必要に応じて、貼り付けた結果をExcel上で加工

手順詳細

CustomFieldオブジェクトから項目作成日を取得

CustomField オブジェクトに対し、以下SOQLを発行します。

標準オブジェクトの場合
  • Lightning Experience の場合はオブジェクトマネージャから対象オブジェクトのAPI参照名を取得する。
  • Salesforce Classic の場合は設定|カスタマイズ|(オブジェクト)から対象オブジェクトを選択し、URLから対象オブジェクトのAPI参照名を取得する。 -- 例: Salesforce Classic で商談オブジェクトを選択した場合、URL https://XXX.salesforce.com/ui/setup/Setup?setupid=OpportunityOpportunity の部分
  • 取得したAPI参照名を使用し、開発者コンソールで以下SOQLを実行する。この時、[Use Tooling API]にチェックを入れてから[Execute]をクリックする。

例:商談(Opportunity)の場合

SELECT TableEnumOrId, DeveloperName, CreatedDate, LastModifiedDate 
FROM CustomField 
WHERE TableEnumOrId = 'Opportunity'

f:id:mark-hammer:20210129010351p:plain
実行後の開発者コンソールキャプチャ

カスタムオブジェクトの場合
  • Lightning Experience の場合はオブジェクトマネージャ、Salesforce Classic の場合は設定|作成|オブジェクトから対象オブジェクトを選択し、URLからカスタムオブジェクトIDを取得する。
    • 例1: Lightning Experience の場合、URL https://XXX.lightning.force.com/lightning/setup/ObjectManager/01IxxXXXXXxxxxx/Details/view01IxxXXXXXxxxxx の部分
    • 例2: Salesforce Classic の場合、URL https://XXX.salesforce.com/01IxxXXXXXxxxxx?setupid=CustomObjects01IxxXXXXXxxxxx の部分
  • 取得したカスタムオブジェクトIDを使用し、開発者コンソールで以下SOQLを実行する。
SELECT TableEnumOrId, DeveloperName, CreatedDate, LastModifiedDate 
FROM CustomField 
WHERE TableEnumOrId = '01IxxXXXXXxxxxx'

f:id:mark-hammer:20210129010421p:plain
実行後の開発者コンソールキャプチャ

開発者コンソールの結果をExcelにコピー

残念ながら、開発者コンソールにはSOQLの結果をCSV等にエクスポートする機能がありません。
そこで、Chromeデベロッパーツールを使ってSOQLの結果をExcelに貼り付けます。

  • F12キーを押してChromeデベロッパーツールを開く
    • この時、別タブの結果を取得しないよう開発者コンソールのタブは1つにすることが望ましい。

f:id:mark-hammer:20210201012653p:plain
Chromeデベロッパーツールを開く

  • Ctrl+F キーを押して検索窓を開き、 grid-table と入力する

f:id:mark-hammer:20210201012822p:plain
検索窓に"grid-table"を入力

  • grid-table 検索結果のうち一番上の行を右クリックし、 Copy -> Copy Element をクリック

f:id:mark-hammer:20210201012734p:plain
Copy Elementを選択

  • Excelを起動し、適当なセルに貼り付ける
    • この時の注意事項は以下の通りです。
      • ヘッダがないため、必要であれば手作業で追加してください。
      • カスタム項目名はAPI参照名から __c がないものになっています。必要に応じて追加してください。
      • 日付/時間はUTC基準です。日本時間に直したい場合は9時間追加する必要があります。
        Excel数式だと =DATEVALUE(MIDB(<元データのセル>,1,10))+TIMEVALUE(MIDB(<元データのセル>,12,8))+TIME(9,0,0) とすれば修正できます。

f:id:mark-hammer:20210201012839p:plain
Excelに貼り付け

f:id:mark-hammer:20210201012850p:plain
Excelに貼り付けた内容を加工

おわりに

開発者コンソールでSOQL取得するまでは想定通りでしたが、そこからの加工が思っていたより大変でした。
開発者コンソールのクエリエディタにエクスポート機能を付けるIdeaExchangeもありますが、ぜひ実装いただきたいと思った一件でした。

trailblazer.salesforce.com

Appendix

今回参考にしたリソース一覧です。

salesforce.stackexchange.com

developer.salesforce.com

www.youtube.com

a1-style.net

Salesforce Tips: ゲストユーザの有無を調べたい

はじめに

楽天、PayPayにてSalesforceの設定不備により不正アクセスを受け、情報流出があったとの報道がありました。

xtech.nikkei.com

xtech.nikkei.com

これを受けてか、セールスフォース・ドットコム社でもプレスリリースを発表。
「当社製品の脆弱性に起因するものではなく、ゲストユーザに対する情報の共有に関する設定が適切に行われていない場合に発生する事象」と、設定の不備による点を強調しています。 www.salesforce.com

本件のまとめとしては以下Blogが参考になります。

piyolog.hatenadiary.jp

ここでは、改めて今回話題となったゲストユーザとは何か、そしてゲストユーザの有無をチェックする方法を記載します。

ゲストユーザとは

通常Salesforceはログイン画面からユーザ名、パスワードを入力してログインして使うものですが、Salesforceサイト、Experience Cloud(旧 Community Cloud)では公開Webサイトを作ることができます。
このとき、Salesforce認証を必要とせずにSalesforceの情報にアクセスさせることができます。

Salesforce ヘルプ: Salesforce サイト より

Salesforce サイトでは、公開 Web サイトとアプリケーションを作成できます。それらは Salesforce 組織と直接統合されるため、ユーザがログインする場合にユーザ名やパスワードは必要ありません。組織に保存された情報を任意のブランド URL を介して公開し、サイトのページを会社のブランドのデザインと一致させることができます。

Salesforce ヘルプ: ゲストユーザプロファイルを使用して認証されていないユーザに安全なアクセスを提供 より

公開コミュニティは、B2C (企業対消費者) での活用に適しており、幅広い利用者にアプローチできます。ゲストユーザプロファイルを使用して、コミュニティ内の認証を必要としないデータ、コンテンツ、オブジェクトへの公開アクセスを制御できます。たとえば、既存の顧客と見込み客がログインせずに他のメンバーまたはサポートによって投稿された公開ディスカッション、既知の問題、およびソリューションを参照できる、カスタマーサポートコミュニティを作成できます。

この「Salesforce認証を必要とせずにSalesforceの情報にアクセスさせる」時に使われるのがゲストユーザです。
ちなみに Experience Cloudではコミュニティユーザライセンスによりコミュニティ専用のユーザを作成することができますが、このユーザはSalesforce認証(ユーザ名、パスワード入力など)を行ったうえでコミュニティにアクセスするため、ゲストユーザとは別のものです。

ゲストユーザの有無チェック

ゲストユーザは Salesforceサイト、Experience Cloudを使用することで自動的に作成されます。
そのため、有効なSalesforceサイト、Experience Cloudがなければ今回の情報流出と同じことが起きる心配はありません。

ここでは、自分のSalesforce組織でSalesforceサイト、Experience Cloudを使用しているか否かを確認する方法を記載します。

Salesforceサイトの使用有無チェック

  • Salesforce設定画面左上にあるクイック検索ボックスに「サイト」と入力し、設定メニューの「サイト」をクリック。
  • この時に以下のようなドメイン名を登録する画面が表示された場合は、Salesforceサイトを利用していません。

f:id:mark-hammer:20201229113736p:plain
Salesforceサイトを利用していない場合

  • 一方サイト一覧が表示された場合、そのサイト一覧のうち「有効」にチェックが入った行があればSalesforceサイトを利用しています。「有効」にチェックが入った行が一つもなければSalesforceサイトを利用していません。

f:id:mark-hammer:20201229114109p:plain
サイト一覧に「有効」なサイトがある場合

f:id:mark-hammer:20201229113959p:plain
サイト一覧に「有効」なサイトが一つもない場合

Experience Cloud(旧 Community Cloud)の使用有無チェック

  • Salesforce設定画面左上にあるクイック検索ボックスに「コミュニティ」と入力し、設定メニューの「コミュニティ設定」をクリック。
  • この時に以下のようなコミュニティを有効化するための画面が表示された場合は、Experience Cloudを利用していません。

f:id:mark-hammer:20201229114221p:plain
コミュニティを有効化していない場合

  • 一方「コミュニティ設定」がこの画面ではなく設定一覧が表示される場合は、設定メニューの「すべてのコミュニティ」をクリック。
  • この時に表示されるコミュニティ一覧に「状況」が「有効」か「プレビュー」の行があればExperience Cloudを利用しています。コミュニティ一覧に何も表示されない、または「状況」が「無効」の行しかない場合は現在Experience Cloudを利用していません。

f:id:mark-hammer:20201229114540p:plain
有効なコミュニティがある場合(状況がプレビュー)

f:id:mark-hammer:20201229114623p:plain
有効なコミュニティがある場合(状況が有効)

f:id:mark-hammer:20201229114712p:plain
有効なコミュニティがない場合(状況が無効)

ゲストユーザがあった場合

上記の手順で有効なSalesforceサイト、Experience Cloudが自分のSalesforce組織にあった場合、次にそのサイト、コミュニティで作成されているゲストユーザの権限を確認します。
セールスフォース・ドットコム社が公開している Trailblazer Community: ゲストユーザセキュリティベストプラクティスの解説 (※要Salesforceアカウント) では具体的な確認手順を含め記載されているため、こちらを参考にされることをお勧めいたします。
資料に書かれていた、主に確認すべき内容は以下の通りです。

  • ゲストユーザプロファイルに対し不要なオブジェクト権限(参照など)を付与していないこと
  • ゲストユーザプロファイルに対し「APIの有効化」権限を付与していないこと
  • ゲストユーザプロファイルに対し不要なApexクラスへのアクセスを許可していないこと*1
  • ゲストユーザに対し不要な個別共有ルールを設定していないこと*2
  • ゲストユーザに対し権限セットが設定されていないか確認すること
    • 権限セットが設定されている場合は、その権限セットに対してもゲストユーザプロファイルと同様の内容を確認すること

ちなみに問題を紹介したブログではauraエンドポイントを用いた情報取得を行っているため、一部ブログでは対策としてSalesforceサイトの「ゲストユーザのLightning機能」設定の無効化を案内していますが、セールスフォース・ドットコム社としては根本を断つ設定を案内しており、資料では「ゲストユーザのLightning機能」設定については触れていませんでした。

おわりに

今回はインパクトが大きい報道のため不安になった方も多いですが、まずはSalesforceサイト、Experience Cloudの状況を確認することをお勧めします。
そのうえでSalesforceサイト、Experience Cloudを使用している場合は、改めてゲストユーザの確認を行いましょう。
また、不明点はセールスフォース・ドットコム社の案内通り、サポートへ問い合わせて不安を解消されることをお勧めいたします。

*1:オブジェクト権限を付与していなくても、Apexクラス経由で情報を取得できる場合があるため

*2:セールスフォース・ドットコム社の資料によれば、ゲストユーザに対する組織の共有設定は現在「非公開」で固定されているとのことです

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

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

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

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

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

Lightning Web コンポーネントと Visualforce の新機能の学習

https://trailhead.salesforce.com/ja/content/learn/modules/platform-developer-i-certification-maintenance-winter-21/learn-whats-new-in-lightning-web-components-and-visualforce

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

項目レベルとオブジェクトレベルのセキュリティや安全なナビゲーション演算子を使ってみる

https://trailhead.salesforce.com/ja/content/learn/modules/platform-developer-i-certification-maintenance-winter-21/get-handson-with-field-and-objectlevel-security-and-safe-navigation-operator

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

【Challenge要約】

※このChallengeには、Salesforce公式解説があります。
注意:Challengeの前にこのユニットの「ハンズオン Challenge の準備」節の作業を完了してください。

  • 新規Apexクラス「ApexSecurityRest」を作成してください。
  • Apexクラス「ApexSecurityRest」に、「ハンズオン Challenge の準備」節にあるApexSecurityRest コードブロックのコードをコピーアンドペーストしてください。
  • results 変数に対し Security.stripInaccessible メソッドを使用して、ユーザに参照アクセス権がない項目を削除してください。
  • Name 項目と Top_Secret 項目に対するオブジェクト権限、項目レベル権限のチェックは冗長となるため削除してください。
    • 注意:不要なコードはコメントアウトではなく削除してください。
  • null 参照を回避するために、安全なナビゲーション演算子機能を取引先(Account)を参照している箇所に適用してください。

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

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

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

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

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

特定のレコード変更時のフローの保存前トリガのハンズオン

https://trailhead.salesforce.com/ja/content/learn/modules/platform-app-builder-certification-maintenance-winter-21/get-handson-with-flow-before-save-trigger-when-certain-record-changes-are-made

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

【Challenge要約】

※このChallengeには、Salesforce公式解説があります。
注意:このChallenge用に新しいTrailhead playgroundを用意することをお勧めします。既存の組織やPlayground組織を利用するとChallenge判定時に問題が発生する恐れがあります。

取引先オブジェクトに以下選択リスト項目を作成してください。

  • 項目の表示ラベル:Onboarding Status
  • 値:以下の通り設定してください。
    • Not Started
    • In Process
    • Complete
  • 項目名:Onboarding_Status

以下の通り、新規フローを作成し、有効化してください。

  • 初期設定
    • フロータイプ:レコードトリガフロー
  • 開始要素
    • フローをトリガする条件:レコードが作成または更新された
    • フローを実行:レコードが保存される前
    • [+ オブジェクトを選択]をクリックし、以下の通り設定してください。
      • オブジェクト:取引先
      • 条件の要件:すべての条件に一致 (AND)
      • 項目:Onboarding_Status__c
      • 演算子:次の文字列と一致する
      • 値:Complete
    • 更新されたレコードでフローを実行するタイミング:条件の要件に一致するようにレコードを更新したときのみ
  • 割り当て要素を画面に配置し、開始要素と繋いでください。
  • 割り当て要素を以下の通り設定してください。
    • 表示ラベル:New Assignment
    • API参照名:New_Assignment
    • 変数値を設定
      • 変数: {!$Record.Active__c}
      • 演算子:次の文字列と一致する
      • 値:Yes
  • 保存をクリックし、以下の通り設定して保存してください。
    • フローの表示ラベル:Onboarding
    • フローのAPI参照名:Onboarding
  • フローを有効化してください。

週末を表す数式を簡潔に書きたい

「Salesforceで、日付が週末か否かを見分ける数式を書きたい。」と言われたとき、どういう数式を書けばよいでしょうか。

WEEKDAY関数とOR関数を使う

一番簡単な方法がこれです。
ヘルプを参考に、date__cが対象の日付項目とすると

OR(
WEEKDAY( date__c ) = 1,
WEEKDAY( date__c ) = 7
)

とすれば出来上がりです。

数式を1行にしたい

しかし、これだと対象の項目が増えるごとにOR関数ごと増えていくため、「なんとか1行にできないか」と考えました。
日曜日(1)~土曜日(7)までをしばらく眺めると…。

曜日 WEEKDAY関数の返り値 返り値÷6の余り
日曜日 1 1
月曜日 2 2
火曜日 3 3
水曜日 4 4
木曜日 5 5
金曜日 6 0
土曜日 7 1

WEEKDAY( date__c ) の返り値を6で割ったときに1余れば土日」であることが分かりました。

Salesforceの数式で表すと、以下の通り1行で書くことができました。

MOD( WEEKDAY( date__c ), 6 ) = 1

コンパイラ後のサイズを比べる

合わせて数式のコンパイラ後のサイズを比べてみます。

WEEKDAY関数とOR関数を使った数式のコンパイラ後のサイズは104文字。

f:id:mark-hammer:20201210004551p:plain
WEEKDAY関数とOR関数を使った数式のコンパイラ後のサイズ

1行にしてOR関数を除いた数式のコンパイラ後のサイズは57文字。

f:id:mark-hammer:20201211225627p:plain
1行にしてOR関数を除いた数式のコンパイラ後のサイズ

コンパイラ後のサイズを見ると、1行にしてOR関数を除いた数式の方が使い勝手がよさそうです。

おわりに

WEEKDAY関数とOR関数を使った数式の方が意図は伝わりやすいですので、数式の分かりやすさを取るか、コンパイラ後のサイズを取るかはケースバイケースとなるでしょう。
せっかく検証したので、簡単ですが投稿してみました。

Salesforceがサポートするクイックテキスト利用ケース

はじまり

Salesforceには、クイックテキストという定義済みメッセージを項目に挿入できる機能があります。

trailhead.salesforce.com

どの項目に挿入できるかは条件があるのですが、会社では行動の「説明」項目にテンプレートを挿入するために使用していました。

ところが、Winter'21がリリースされてからユーザより「クイックテキストを挿入しようとするとエラーが出てしまう。」という問い合わせが入るようになりました。

f:id:mark-hammer:20201209222433p:plain
実際のエラー画面

試したところ、行動の編集画面*1で差し込み項目を含むクイックテキストを挿入するとエラーが再現しましたのでSalesforceサポートに問い合わせることにしました。

Salesforceがサポートするクイックテキスト利用ケースとは

Salesforceサポートに問い合わせた結果、以下の回答を得ました。

5.メッセージを使用可能にするチャネルを選択します。
組織で有効な機能に応じて、次のチャネルを利用できます。
メール — メールアクション用
行動 — 行動アクション用
内部 — 状況の変更アクションなど、内部項目で使用します
ナレッジ — Lightning Experience のナレッジ記事用
チャット — サービスコンソールのチャットで使用します。
メッセージング — サービスコンソールのメッセージングで使用します。
電話 — 活動の記録アクション用
ポータル — コミュニティまたはカスタマーポータルで使用します
ソーシャル — ソーシャル投稿用
ToDo — ToDo アクション用

  • Salesforceがサポート対象とする行動オブジェクトへのクイックテキスト利用は「新規行動」などの行動アクションのみであり、行動の編集画面はサポート対象としない。
  • したがって、今回の事象はサポート対象外の行動の編集画面のみで発生するため、不具合ではない。

確かに「新規行動」などの行動アクションでは差し込み項目を含むクイックテキストが利用できるため、この回答でクローズとしました。

サポートからこの回答を得るまでの経緯

上記回答はヘルプの内容に沿った回答だと思っておりますが、実はこの回答を得るまで約半月掛かっており、しかもサポートからの回答が二転三転しました。
ここではその経緯を書いてみます。

1回目の回答

最初に問い合わせた時の回答は以下でした。

差し込み項目の考慮事項
クイックテキストでは、差し込み項目は、取引先、ケース、取引先責任者、カスタムオブジェクト、リード、商談、組織、ユーザ、作業指示のオブジェクトに挿入できます。

  • 上記に行動オブジェクトは含まれない。
  • よって行動オブジェクトへの差し込み項目を含むクイックテキストはサポート対象外なので本件は不具合ではない。

この回答には「それはクイックテキストの『差し込み項目の挿入』で関連先として選べるオブジェクトですよね。」「その回答が正しいなら組織に対して挿入可能な差し込み項目を含むクイックテキストを作成する方法を教えてください。」と返しましたがサポートからの回答は全く変わらず、結局「これ以上の進展が見込めないのでクローズします。」と返しました。

2回目の回答

こちらは質問が異なり、会社で「選択可能なチャネルに『商談』ってあるけど、商談でクイックテキスト利用してましたか?」という話が発端でした。
そこから、「選択可能なチャネルに『商談』がありますが、商談ではクイックテキスト利用可能でしょうか」というケースを作りました。

その回答は「Salesforce ヘルプ:クイックテキストの挿入と使用に商談のチャネルがないので商談では利用できません。」でしたが、「1回目の回答が正しいなら、商談にも差し込み項目を含むクイックテキストが作れるはずです。この矛盾はどこからきているのでしょうか。」と追加質問。
最終的に、「Salesforce ヘルプ:クイックテキストの挿入と使用に行動のチャネルがあるので、行動にも差し込み項目を含むクイックテキストは使える。」という回答を得ました。

3回目の回答

2回目の回答をもってもう一度行動の編集画面で発生するエラーについてケースを作りました。
するとまた1回目の回答と同じ回答を出してきたので*3、「その回答は2回目の回答と矛盾しています。どちらが正しいかはっきりさせてください。」と返し、別担当者*4に変わった後の回答が冒頭に書いた回答となります。

おわりに

今回のようにSalesforceサポートの回答を変えさせるのは結構難しいと感じました。
今回の場合だと

顧客「私にはこのヘルプの文面はこう読める」
Salesforceサポート「いや、その認識は誤りでこれが正しい」

となってしまうと平行線のまま先に進めなくなってしまいます。
今となっては1回目の回答の際に「その回答が正しいなら組織に対して挿入可能な差し込み項目を含むクイックテキストを作成する方法を教えてください。」で粘ればよかった*5かなぁと思いますが、当時はこのやり取りで疲れてしまったので終わらせた経緯がありました。

Trailblazer Communityでもこの問題は取り上げられていますので、困っている人はそれなりにいそうです。

trailblazers.salesforce.com

この投稿がお役に立てれば幸いです。

*1:インライン編集含む

*2:他のヘルプにもサポート対象の条件が記載されているため、引用部分を満たせばどのような利用方法でもサポートされるわけではありません

*3:ちなみに1回目、2回目、3回目のサポート担当者は全員違う人です

*4:おそらく上位サポートエンジニア

*5:組織に対してクイックテキストが作成できない矛盾を突く意図

システム管理者はヘルプメニューの非表示ができない

はじめに

Lightning Experience画面右上にある「?」マークをクリックすると表示されるヘルプメニュー。
このメニューは 設定|ユーザエンゲージメント|ヘルプメニュー でカスタマイズでき、一番上に独自のコンテンツを掲載することができます。

f:id:mark-hammer:20201130235418p:plain
追加した独自のヘルプメニュー

Salesforce標準のヘルプメニューを非表示にすると…

会社にこの独自のヘルプメニューを導入する際、「一般ユーザにはSalesforce標準のヘルプメニューはいらないな…。」と思い、「Salesforce ヘルプコンテンツ」を全てオフにしました。

f:id:mark-hammer:20201130235648p:plain
標準のヘルプメニューを全てオフに

その後、「?」マークをクリックしましたが…、
Salesforce標準のヘルプメニューが非表示にならない。

f:id:mark-hammer:20201209013146p:plain
全てオフにしても標準のヘルプメニューが消えない

キャッシュかと思い、ブラウザキャッシュを消しても1日置いても標準のヘルプメニューが表示される状況。
不具合かと思い、Salesforceサポートに問い合わせたところ「システム管理者は標準のヘルプメニューを全てオフにしても表示されたままになる」とのこと。

実際にヘルプを確認すると、Salesforceヘルプ:Lightning Experience ヘルプメニューのカスタムヘルプの定義 より、

Salesforce が作成したセクションおよびコンテンツへのリンクをユーザに対して非表示にすることができます。
[Salesforce ヘルプコンテンツ] セクションで、非表示にするセクションとリンクを無効にします。
システム管理者には、リリースノートへのリンクをはじめ、すべてのリソースが常に表示されます。

…確かに書いてありました。

追加検証:標準ヘルプメニューが表示される条件

上記ヘルプには「システム管理者」としか書いてありませんが、権限として「システム管理者」があるわけではありません。
具体的にどの権限を付与すれば「システム管理者」と判定されるか確認したところ、「すべてのデータの編集」か「ユーザの管理」権限をもつユーザはシステム管理者として判定され、標準のヘルプメニューが消えない環境となります。*1

ヘルプメニューをカスタマイズしても標準のヘルプメニューが消えない方は、権限を確認することをお勧めします。

*1:「すべてのデータの参照」のみではシステム管理者として判定されません。

フローの投稿をどうするべきか考えた

はじめに

先日フローに関する投稿に関するアンケートを実施しました。
お答えいただいた皆様、ありがとうございました。

ここでは、このアンケートを取った理由と、意見を反映した結果を書いてみます。

フロー作成以前

私がフローを自分で考えた要件のために作成したのは↓が初めてです。

sfblog.markhammer.net

それまではTrailheadの課題で作成したことはありましたが、実際の要件に合わせて作成する場合にどう作ればいいのか全く分かりませんでした。
特にフローにおける変数の扱いについて、「これどう使ったらいいの…?」というぐらい使い方が分かっていませんでした。
フローで要件を実現した投稿なども当時見たのですが…

「フローでその要件を実現できるのは分かったの。具体的にどうするのか知りたいの。

とずっと思っていました。

フロー作成後にブログを書いてみて

その後仕事でフローを作成するにあたり、情報共有としてブログ投稿をします。
「フローを作る前の自分が見ても役立つような投稿にしよう」と思いながら書いてみたのですが…、実際に出来上がったのはフローの概要しか書けていない投稿でした。

「ダメだこれ…、当時の自分が見て『具体的にどうするの?』と聞くやつだこれ…。」

ただこれには理由があり、先ほどリンクを貼った投稿を見ていただくと分かるのですが、概要の時点で投稿量が多いんです。

これに各要素の設定値を付け加えると、書くのも大変だし長すぎて誰も読まないような投稿になってしまうと思い、フローの概要までで留めたのでした。

アンケートを取ってみて

フローの設定値まで細かく書いた投稿は需要があるのか。
過去の自分はそれを求めていましたが、実際の需要を見るためにTwitterでアンケートを取ってみました。
ちなみに「概要と設定値両方見たい」という意見もありましたが、「アンケートに『両方』と書いたらほぼ全員それ選ぶでしょ」ということで、より重要視するものはどちらか、という意図で2択にしました。

結果は約2/3が「具体的な設定値を見たい」となり、実際に書いてみることに。
ただし概要と同じページに書くのは長くなりすぎるので却下。
投稿を分けるにしても、おそらくはてなブログでは見やすい投稿にならないと思い、zenn.dev で書いてみました。

zenn.dev

今後も改善しながらこのような形式で書いていければと思います。