#Salesforce Developer381 人正在讨论

I am not able to disable the PKCE settings, asks me to contact support. Any workaround for this?  

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:

Hi CM Seb, 

Two separate root causes here, both well-documented, and both explain your exact symptom (works as admin in Debug, silently does nothing for guest users on the live site). 

1. Record creation not happening: most likely the flow isn't actually enabled for the Guest User profile, even if it "worked" in Debug. 

Profile-level object permissions (Read/Create on Application) are necessary but not sufficient. You also need to explicitly grant the flow itself to guest users, this is a separate step from object permissions: 

   - Experience Builder > Settings (gear icon) > General tab > confirm "Guest users can see and interact with the site without logging in" is checked, then click the guest user profile link. 

   - Under Enabled Flow Access, click Edit, and confirm your Transitional Coach Application flow is moved into the Enabled Flows column (not just present in the Available list). 

   Reference:

   This is the single most common cause of "works when I test it logged in, does nothing for actual guest visitors", the flow needs this explicit enablement separate from object CRUD permissions. 

2. Emails not sending: this is a hard platform restriction, not a config you're missing. 

As of Spring '23, Salesforce permanently removed the "Send Email" system permission from the Guest User profile across ALL orgs, and since permission sets can't be assigned to guest users either, there is no way to grant this back declaratively. This is intentional (anti-spam/abuse prevention for public-facing guest contexts), not a bug. 

   Workaround: don't send the email directly from the guest-context flow. Instead: 

   - Have the guest flow create the Application record only. 

   - Use a separate Record-Triggered Flow on the Application object (After Save), running as an internal/system context, not the guest user, to send the confirmation email. Since this second flow runs on the object trigger rather than in the guest user's session, it isn't restricted by the Guest User "Send Email" removal. 

Given your record creation is also failing (not just email), I'd fix #1 first, that's likely blocking everything, and once records start getting created successfully, wiring up a Record-Triggered Flow for the email (per #2) will resolve the email gap cleanly without depending on guest user email permissions at all.

Hi @Hitesh Sharma

 You can handle this using an after-update Opportunity trigger + Queueable Apex. First, collect the unique Account IDs where the Opportunity changes to Closed Won, then pass those IDs to a single Queueable job. 

In the Queueable, query the related Accounts and Opportunities, determine the latest Closed Won Opportunity for each Account, and update the Account Description in one bulk DML operation. 

This approach avoids SOQL/DML inside loops and handles bulk updates safely. Salesforce recommends bulkifying both SOQL and DML operations. 

Also, use a Set<Id> for Account IDs to ensure the same Account is processed only once.  

Code: 

trigger OpportunityTrigger on Opportunity (after update) { 

    Set<Id> accountIds = new Set<Id>(); 

    for (Opportunity opp : Trigger.new) { 

        Opportunity oldOpp = Trigger.oldMap.get(

opp.Id

); 

        if (opp.StageName == 'Closed Won' && 

            oldOpp.StageName != 'Closed Won' && 

            opp.AccountId != null) { 

            accountIds.add(opp.AccountId); 

        } 

    } 

    if (!accountIds.isEmpty()) { 

        System.enqueueJob(new UpdateAccountDescriptionQueueable(accountIds)); 

    } 

} 

Then the Queueable can query the latest Closed Won Opportunity per Account and perform one bulk update on the Accounts. 

One important consideration: because the requirement is “latest Opportunity Name”, don't simply use the Opportunity from Trigger.new; if multiple Opportunities for the same Account are updated in the same transaction or an older Closed Won Opportunity already exists, the Queueable should determine the latest record from the database. 

This follows Salesforce's bulk-processing guidance and keeps the trigger lightweight.  

Hope This Helps!!

和人様 

こんにちは。リストビュー上で画面フローを使ってコメント作成・追記を行う実装は可能です。以下、標準機能のみで完結する構成で解説します（今回は「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件ずつ追記」の構成から作ってみて、動作確認できたら複数選択対応に拡張するのがおすすめです。不明点があれば、どのステップで詰まったか教えてください。