#Flow157 utenti parlano di questo argomento

@durgam santhosh

Yes - the native no-Apex route is an Email Alert (the core 'Send Email' Flow action won't render a template's merge fields). Create an Email Alert on Opportunity (Setup > Email Alerts) that uses your Opportunity Lightning template, then call it from your record-triggered Flow as an Action - the alert sets the triggering Opportunity as the Related To, so all your Opportunity merge fields resolve. 

For recipients you can pick Opportunity Owner directly; to send to that custom email field it has to be an Email-type field, then it shows up under Recipient Type 'Email Field'. 

If this helps, please mark it as the Best Answer so it helps the next person - thanks!

Hi Greg, 

The Debug window's screen only lists fields that are directly writable and accessible to your own user's Field-Level Security — not every field on the page layout. Fields that are read-only, formula, roll-up summary, system fields or fields where FLS for your own profile isn't set to Edit won't show up. Please check the FLS and what type of field it is. 

I hope this help!!

@Mario Santellan

your flow is basically right — the only broken piece is the GetFileName filter value. In that resource picker you're currently on 'Related Record ID', which is the record you attached the files to, not the uploaded file. Instead pick the Upload File component's 'Content Document IDs' output (Upload File > Content Document IDs) — that's the list of the uploaded files' Ids. Also change the operator from Equals to In, since that output is a collection: the condition should read Content Document ID In → Upload File > Content Document IDs. Equals against a collection is exactly why nothing matched. Your Title mapping is already right — Title lives on the ContentDocument record, which is why 'Content Document from GetFileName > Title' works in AddAttachmentName (Title = file name without the extension; add FileExtension if you need the .pdf/.docx part). On multiples: with 'Only the first record' selected you'll capture just the first file's name. If a partner uploads 2+ files and you want them all, switch GetFileName to 'All records', add a Loop over it, and in an Assignment append each 'Loop > Title' (plus a comma) into a Text variable, then map that variable into File Name. If one name is enough, first-record is perfect as-is. Give that a try — it should populate.

Hey Misty, 

Your read is accurate: per Salesforce's own docs, Related Record Matching is an org-wide, all-or-nothing setting, when it's on, ECI runs its own algorithm (participant email/domain matching against Contact, Lead, Account) and populates the Related Record field automatically. If you want to run your own Flow-based matching logic instead (your name-against-Contact/Lead + subject line idea), you have to turn Related Record Matching OFF entirely, then a Flow becomes the only thing setting that field. You can't layer a supplemental Flow on top of the native matching to "catch the extra 10-20%", it's one or the other, not additive. 

Given that, your options really are: 

1. Turn off native matching, build your own Flow to replicate ECI's built-in logic PLUS your extra fallback rules (name-against-Contact/Lead, subject line parsing). This means you inherit responsibility for the baseline matching ECI already does well, not just the edge cases, that's a bigger lift than it initially sounds. 

2. Keep native matching on, and instead build a separate Flow/batch job that runs afterward on unmatched records only, checking if Related Record is null, then applying your own supplemental logic to update it. This avoids fighting the native system since you're only touching records ECI already gave up on, not replacing its matching entirely. 

3. Turn on Einstein Activity Capture integration alongside ECI, per Salesforce's own guidance, this specifically enhances guest participant matching quality, which sounds directly relevant to your "joining from a car/conference room" problem, worth testing before building custom logic at all. 

On

or similar tools: since ECI's matching is a Salesforce-side process, not tied to which video/transcription vendor recorded the call, a third-party transcription add-on wouldn't conflict with ECI's matching logic, but it also wouldn't replace or feed into it automatically. It solves a different problem (better transcript quality) than record-matching itself. 

Given the scale you're describing, option 2 (supplement only nulls, don't disable native matching) is usually the least disruptive path, worth prototyping that before considering a full matching rebuild. 

Reference:

@Duncan Taylor

It's neither a bug nor a pending feature — by design the Email Alert action needs a real, committed record Id (that's the SObjectRowId input) to resolve the template's merge fields and the alert's recipients. Your error shows SObjectRowId = {!input_bla.Id} (null), so in that run input_bla was never saved and has no Id — which is exactly why it fails there but works when you pass a real record manually in debug. Fix: make sure the record actually exists (has an Id) before the alert runs. If it should fire after a save, build it as (or call it from) a record-triggered after-save flow and pass {!$

Hi John, 

Per Salesforce's own documentation on Predefined Field Values for Quick Actions: "A predefined field value for a lookup field must be a reference to a record Id field or another lookup field." The predefined-value formula editor on a Quick Action only accepts Id/lookup-type field references for lookup fields, it doesn't expose Custom Metadata Type fields as valid merge field options in that specific context, even though CMDT works fine in regular formula fields elsewhere in the org. That's exactly why you got "does not exist," the formula editor there simply doesn't recognize CMDT as a valid source for a lookup predefined value, regardless of your CMDT being perfectly valid. 

Official reference:

Given this limitation, and since you're already moving toward the Visual Picker + Screen Flow approach for your switchboard, it's worth solving the "default Primary Campaign Source from CMDT" problem inside a Screen Flow's Create Records element instead of a Quick Action: 

1. In your Screen Flow, add a Get Records element to query your Custom Metadata Type record. 

2. Use an Assignment or directly reference the CMDT field in your Create Records element for the Opportunity, Flow's Create Records doesn't have the same restriction, you can reference any accessible field, including CMDT values, when building the record to insert. 

This sidesteps the Quick Action limitation entirely and keeps everything native, no Aura/LWC workaround needed for this particular piece. Combined with the Visual Picker switchboard, this gives you a fully declarative solution for both original problems.

和人様 

こんにちは。リストビュー上で画面フローを使ってコメント作成・追記を行う実装は可能です。以下、標準機能のみで完結する構成で解説します（今回は「1件ずつコメントを追記する」パターンを前提とし、複数選択して一括処理したい場合の応用も併記します）。 

■ 全体構成 

1. スクリーンフロー（画面フロー）を作成 

2. Task（活動記録）オブジェクトの リストビューボタン からこのフローを起動 

3. フローで対象レコードのIDを受け取り、コメント入力用の画面を表示、既存の内容に追記して更新 

■ フロー構築手順 

1. 「新規フロー」→「画面フロー」を選択 

2. 変数を作成 

   ・名前: recordId（1件選択の場合）または ids（複数選択チェックボックスの場合） 

   ・データ型: テキスト（recordIdの場合）またはテキストのコレクション（idsの場合） 

   ・「入力のみで使用可能にする」にチェック 

   ※ この変数名は仕様として決まっており、リストビューの詳細ページボタンからは「recordId」、リストビューのチェックボックス選択（一括処理）からは「ids」という変数名で自動的にIDが渡されます。 

   参照:

3. 「レコードを取得」要素を追加 

   ・オブジェクト: Task 

   ・条件: Id が {!recordId} と等しい 

   ・「複数のレコードを取得するように選択されている場合のみ、複数レコードを自動的に格納」のオプションは今回は単一取得でOK 

   ・取得した Description（活動内容）などの既存フィールドをそのまま画面に引き継ぎます 

4. 「画面」要素を追加 

   ・長文テキストの入力コンポーネントを配置（例: 「追記コメント」） 

   ・初期値に、手順3で取得した既存の Description の内容を表示させておくと「追記」らしくなります 

     例: {!Get_Task.Description} & " 

" & （ここにユーザー入力用の空欄を用意） 

   実際には「既存内容を表示する読み取り専用テキスト」＋「新規コメント入力欄」の2つに分けたほうが、ユーザーが誤って過去の記録を消してしまうミスを防げます 

5. 「代入」要素を追加 

   ・新しいDescriptionの値 = 既存のDescription & 改行 & 日時 & ユーザー名 & 新規コメント入力内容 

   ・{!$Flow.CurrentDateTime} や {!$User.FirstName} などのグローバル変数を使うと「誰がいつ追記したか」が残せます 

6. 「レコードを更新」要素を追加 

   ・対象: 手順3で取得したTaskレコード 

   ・Description項目に手順5で組み立てたテキストを設定 

7. フローを保存・有効化 

■ リストビューへのボタン設置手順 

1. 設定 → オブジェクトマネージャ → タスク（Task）を開く 

2. 「ボタン、リンク、およびアクション」→「新規ボタンまたはリンク」 

3. 表示種別: 「リストボタン」、コンテンツソース: 「URL」 

4. URL欄に以下を設定: 

   /flow/あなたのフローAPI名?retURL=/lightning/o/Task/list 

5. 保存後、「検索レイアウト」または「リストビューボタンレイアウト」の編集画面で、作成したカスタムボタンを「選択されたボタン」に追加して保存 

参照（同じ仕組みの公式標準コンポーネント解説）: 

■ 補足（複数レコードへの一括コメント追記がしたい場合） 

手順2の変数を「ids（テキストのコレクション）」にし、手順3を「ループ」要素で回して1件ずつ同じ処理を繰り返す構成にすれば、リストビューでチェックボックスにより複数選択→一括コメント追記も実現できます。この場合はガバナ制限（SOQL・DML回数）に注意し、ループ内では都度Get Recordsを呼ばず、事前に一括取得してからループするのが定石です。 

まずは「1件ずつ追記」の構成から作ってみて、動作確認できたら複数選択対応に拡張するのがおすすめです。不明点があれば、どのステップで詰まったか教えてください。