承認プロセスの否認時に申請者にメールが飛ばないのを何とかしてみた
この記事は「Salesforce Advent Calendar 2023」の4日目の記事です。
皆さんご無沙汰しております。
最近はSalesforceの標準機能がリッチなばかりに開発者なのにほぼノーコード＋フロー開発を行っております、かなさんです。
今回は承認プロセスで最近実現した機能の話をしたいと思います。
●メールの宛先に申請者がない問題
Salesforceにはいろいろな標準機能が存在します。
承認プロセスもその一つで、商談や経費申請などのにおける承認処理を自動化することができます。
申請が承認・却下された際に通知のメールを自動で送ることができ、送信先にはレコードの所有者や作成者を指定することが可能です。
ただ残念なことに、承認プロセスの申請者は指定することができません。
※メール受信者（メールの宛先）に承認申請関連の項目はない
●なければ作ろう申請者項目
メールの送信先にカスタムで作成したユーザ項目は設定可能です。
そのため、承認申請の開始時に操作ユーザを予め作成した「承認申請者」項目（ユーザの参照項目）に設定し、否認時には「承認申請者」宛にメールを送信することとしました。
ただ、承認プロセスで使用できる「項目自動更新」ではユーザー項目に動的な値が設定できませんでした。
●結局どうしたのか
「項目自動更新」とフロートリガの合わせ技で「承認申請者」項目を設定することができました。
順書は以下の通りです。
1．承認申請開始時に「項目自動更新」で対象レコードの何れかの項目を更新する
※今回は承認申請中かどうか判定用のカスタム項目「承認申請中フラグ」（チェックボックス）を作成し、申請開始時にTrue、最終承認・最終却下・取り消し時にFalseとしています
2．新規のフロートリガを作成し、1．により起動させる
※開始条件は申請開始時のみ合致するもので、今回は「承認申請中フラグ」項目がTrueになった場合のみを指定
3．フロートリガの処理で「承認申請者」（ユーザーの参照項目）に実行ユーザーを設定する
※ユーザのIdを設定
4．メールの宛先（メール受信者）に作成した「承認申請者」項目を設定します
※受信者種別「関連ユーザ」を指定することで、指定したオブジェクトに存在するユーザ項目を表示可能
以上の設定により、以下の承認プロセスでは申請が却下された場合、
承認申請者にメールが送信されます。
これで却下時の見落としも減って承認がはかどりますね。
●まとめ
いかがだったでしょうか。
承認申請はレコードの作成者や所有者以外からも可能なため、参考になれば幸いです。
SalesforceのWorld Tour Tokyoで登壇します
SalesforceのWorld Tour Tokyoの２日目に、
Salesforce Developer Group Tokyoとしてハンズオンをさせていただくことになりました。
うれしいことにすでに満員となっておりますが、興味のある方はぜひ覗いてみてください。
SALESFORCE 認定 SHARING AND VISIBILITY アーキテクト合格しました
TrailheadのQuestでいただいたバウチャーを期間内に消費すべく、ゴールデンウィークを利用して久々にSalesforceの認定試験を受験してきました。
今回受験したのは、SALESFORCE 認定 SHARING AND VISIBILITY アーキテクト。
詳細は以下のリンクに譲りますが、Salesforceのオブジェクト・項目、レコードがユーザにどのように見えるか、どうすれば思った通りに表示することができるのかが問われる試験です。
何とか合格することはできましたが、範囲が広く、特に自分が今まで利用したことのない機能については学習時にイメージしにくい部分がありました。
そんな時、とても参考になったのが「Salesforce Architect Group」で紹介された以下の動画と動画のスライド資料です。
https://trailhead.salesforce.com/trailblazer-community/download/file/0694S000001qxaOQAQ
試験に出るであろうポイントがまんべんなく押さえられていて、この動画・資料を確認してから学習することでよりスムーズに進めることができました。
試験を受験予定の方はもちろん、共有について理解を深めたい方はぜひご参照ください。
Salesforceのフローから承認申請してみよう
この投稿はSalesforce Advent Calendar 2022の4日目の記事です。
こんにちは。昨年はクリスマスイブに風呂場で足を滑らせて骨折し、メリー苦しみマスを体現してしまったうっかり者、かなさんです。
突然ですが、みなさんはSalesforceの「承認プロセス」を使ってますか？
●承認プロセスとは
部署によっては「売り上げ見込みが100万円以上の場合は、上長の承認が必要」だったり、「取引先のランクがC以下の場合は、ダブルチェックが必要」などのルールがあるかもしれません。
そんな時に便利なのが「承認プロセス」です。
事前に設定した条件（「売り上げ見込みが100万円以上」など）を満たした際に、承認を自動化することができます。
※承認プロセスの詳細についてはSalesforceのヘルプを参照ください
●承認プロセスの弱点
しかしながら、Salesforce承認プロセスには3つの弱点があります。
- 承認プロセスの開始は基本ユーザが行う
- 承認が必要でない場合もページに「承認申請」ボタンが表示される
- 承認が必要な条件が表示されない
そのため、
『承認必要だと思って「承認申請」ボタンを押して、コメントも入れたのに、いざ送信してみたら「該当する承認プロセスは見つかりませんでした。」と表示される』
という、大変もやっとする事態が発生したりします。
●どうする？
では、どうすればいいのでしょうか？
『「承認申請」ボタンを押す前に承認が必要かどうかが分かればいい』ですよね。
画面フローから「承認申請」を起動することで実現可能です。
●手順
ざっくりとした手順は以下の通りです。
- 「承認申請」を起動する画面フローを作成する
- 承認申請を行うオブジェクトのLightningレコードページに1.で作成したフローを設置する
●「承認申請」を起動する画面フローの例
今回は承認プロセスを使う機会が多そうな「商談」の承認申請を行うフローを作成してみました。
ポイントは以下の3つです。
1．「決定」要素で承認プロセスの開始条件を満たしているか判定を行う
今回は金額が1000万円以上か判定しています
2．条件を満たす場合にアクションで「承認申請」を行う
必須なのは承認申請を行うレコードのIdのみです
3．条件を満たさない場合には「承認申請は不要」である旨を表示する
●Lightningレコードページにフローを設置
フローを設置したいLightningレコードページをLightningアプリケーションビルダーで開き、作成したフローを設置します。
●動作イメージ
商談の金額が1000万円の場合と1000万円未満の場合の表示は以下の通りです。
・商談の金額が1000万円（承認が必要）の場合
・商談の金額が1000万円未満（承認は不要）の場合
●まだある利点
フローから承認申請を行う場合、開始条件をスキップできます。
そのため、承認プロセスを絶対に起動しない条件で複数作成しておき、
フロー側で承認の条件を判定し、起動する承認プロセスを振り分けることが可能です。
●注意点
承認プロセスで初回の承認者を「申請者が承認者を手動で選択する。」としている場合、承認申請アクションの「次の承認者 ID」を設定する必要があります。
その場合「次の承認者 ID」に指定できるのはユーザを1名のみです。
●最後に
注意点に気を付けつつ、便利なフローからの承認申請を試してみてください。
1000バッジ達成！
Trailheadのバッジ取得数1000達成しました。
最近あまりバッジが取れていなかったものの、
TrailheadQuestの締め切り（※）に押されてようやく達成しました。
※10月末締め切りのTrailheadQuestの数がものすごく多かった。
DreamforceのQuestだけで5つあるのにさらに畳みかけてくるとか、Trailhead恐ろしい子・・・。
去年の大みそかに900だったので、100個取るのにほぼ10ヶ月かかっているため、
コンプリートに向けてペースを上げたいと思います。
Salesforceの設定的な内容はもちろん、
プロジェクトマネジメントや統計学などについても学べるので、
みなさんもTrailheadで色んなバッチを取得してみてください。
フローの設置個所の特定方法
お客様組織でFlowが複数個所に設置されているものの、場所がわからない！
ということがあり、Flowの設置個所を特定してみました。
方法は以下の通り。
●フローの設置個所の特定方法
1．フローの詳細を表示し、URLからIdを取得する
※画像のフローのIdは300Iw0000004L7bIAEです
２．開発者コンソールのQuery Editorを開き、User Tooling APIにチェックを入れる
３．以下のSOQLのXXXXXXXXXXXXXXXXXX部分に検索したいフローのIdを設定する
Select MetadataComponentId,MetadataComponentName,MetadataComponentType,RefMetadataComponentId,RefMetadataComponentName,RefMetadataComponentType
from MetadataComponentDependency
where RefMetadataComponentId = 'XXXXXXXXXXXXXXXXXX'
4．３．のSOQLを開発者コンソールのQuery Editorに張り付け、「Excute」をクリックする
4．フローがどこに設定されているか表示される
５．コンポーネントのタイプごとに更にSOQLを発行する
※画像のフローの設置個所はすべてFlexiPageのため、4．で取得したMetadataComponentIdをキーに以下のようなSQOLでレコードを取得する
Select Id,DeveloperName,Type,EntityDefinitionId
from FlexiPage
where Id IN('0M0Iw000002F26RKAS','0M0Iw000002F26hKAC','0M0Iw000002F26mKAC','0M0Iw000002FBsmKAG')
６．５．の実行結果より設置個所が特定できる
※実行結果より、1行目はケースのLightningレコードページ、2行目は取引先のLightningレコードページ、3行目は取引先責任者のLightningレコードページ、4行目はホームページであることが特定できた
●注意事項
今回利用したMetadataComponentDependencyはまだベータの機能であり、今後変更される可能性があります。
●まとめ
フローの設置個所が不明で困っている方は使ってみてください。
翻訳STFファイルでキー重複が発生した原因と対策
●発生した状況
・多言語組織
・項目の翻訳などにトランスレーションワークベンチを使用
・リリース時に開発環境から翻訳STFファイルをエクスポートし、リリース先の組織でインポートしている
・とあるオブジェクトの項目に関する翻訳STFファイルをインポート時にエラーが発生
●発生したエラー
・翻訳STFファイルインポート時のキー重複
●推定される原因
・翻訳STFファイルではカスタム項目のAPI名の末尾の「__c」が削除されて出力される
・標準項目と同じ名前で作成していた場合、キーが重複する
（例）同じオブジェクトにAPI名がNameとName__c項目が存在した場合、翻訳STFファイル出力後は両方ともNameになる
・取り込みでエラーが発生しても、エラーとなった項目を含めて翻訳は設定される
※ただし、キー重複の場合は誤った項目に翻訳が設定される場合がある
●対策
1．標準項目と同じAPI名を持つカスタム項目を作成しない
2．1．が不可（項目の作成・稼働済み）の場合、インポート後に該当の項目の翻訳を手動で行う
