Flowに関するまとめページに戻る

フローの要素では「メールアラートを送信」を使えば元々作成しているClassicメールテンプレートを使用出来、「アクション」要素ではテンプレートを作らずにフローの中でメールのひな形作成や送付先を選択できると聞きました。結果どちらの方法でも作成出来るのかなと思いますが、それぞれのメリット/デメリット等はございますでしょうか？

フロー作成時に使用する要素の違いについて

そうですね、以下にあるようにメール送信アクションだとアクティブティのメールログとして記録できることが一番の違いだと思います。

The send email action has gotten very good and allows you to log it as activity (which alerts don’t do) against a record if you want.

https://www.reddit.com/r/salesforce/comments/1fz2soz/best_practice_question_email_alerts_vs_send_email/

値がない場合や NULL の場合、テキストテンプレートのメール本文のフィールドを条件付きで非表示にします。

Conditionally hide field in text template email body if no value/NULL.

この場合はメールテンプレートでIF文を使わずに、数式リソースでIF文を使って行う。

フローで送信しているメールが改行されない

フローで送信しているメールが改行されない

アクションの「リッチテキスト形式の本文」をOFFにすることで解決しました。

フローから送信したメールの返信

How to reply to email message related to case from salesforce flow?

I want to say this is handled natively if you have the newer email threading option enabled and are using Case Email Alerts where the sender is equivalent to your email-to-case address. This should tie your Case Email Alerts in the Emails related list on that Case, and when customers respond, it should also back into Salesforce.

フローを使ったメールの配信

ＤＭメール送信の自動化フローの相談

承認通知や、承認の機能、待機の機能を簡単に作ろうと思えば、

私ならこれらのためにカスタムオブジェクトを１つ作成します。

このカスタムオブジェクトにメールの本文用の項目（ロングテキスト、リッチテキストでうまくメールの本文になるかはちょっと不安ですが...）を作って置きます。

承認については作成されて、承認していないレコードを表示するビューをつくれば、１レコードずつ通知しないでも担当者には分かると思います。

担当者が内容を確認して、OKなら、チェックボックス型の項目（確認済み）をtrueにします。

時間になればスケジュールフローを起動して、未送信で確認済みのレコードを対象にメール送信処理を行います。

送信対象者が複数あってもいように、もう１つカスタムオブジェクト（ジャンクションオブジェクト）を作っておき、上記メール本文オブジェクトのIdと取引先責任者のIdを保存させておきます。

メール送信用のスケジュールフローでも、このジャンクションオブジェクトを使ってレコードの取得を行えば、宛先用のコレクション変数を作成できると思います。

未分類

This error occurred: CIRCULAR_DEPENDENCY: This case is parented by a case that is also its child.

共有していただいた例から、親として保持するものを選択する必要があることがわかりました。メールオブジェクトでフローを実行することはやめて、代わりに、他のフローを介してケースオブジェクトのスレッド識別子を更新した後、ケースオブジェクト (作成済み) でフローを実行しています。現在、このフローは 0 分後に実行する必要があります。各決定結果の後、同じスレッド識別子を持つケースを取得し、子として更新しています。フローは、問題となっている他の親に対してケースが作成されたかどうかを調べ (レコードを取得)、作成された場合は停止します。そうでない場合は、画像の各結果からわかるように、さらに先に進みます。

insufficient access rights on cross-reference id

原因は、受信者IDにメールアドレスの変数を入れていたことでした。
正しくは、取得した人物情報IDを入れることでした。