#Agentforce523 debatiendo

Hey @Tushar Jadav

, 

It's in my initial post. I'm sharing it here: 

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:

Thanks @Kundan Kumar Jha — that matched what we later confirmed against Salesforce's official SIP setup docs. Quick progress update for anyone following this:

We've since built the SIP trunk on the Genesys side (Site, Number Plan, Generic BYOC Carrier trunk pointing at the Salesforce SBC FQDN, Outbound Route) and confirmed connectivity via SIP trace.

Where we're stuck now is the step Salesforce's guide describes before the actual transfer: adding a Function/Lambda Data Action in the Genesys flow that calls the voiceCalls Telephony Integration API (JWT-signed, RS256) to create a VoiceCall record

transferring the call via SIP to the Agentforce agent. The only ready-made sample Salesforce links to is built for Amazon Connect and doesn't map onto Genesys's Data Action model — so we'd need to write our own. 

Two questions before we build this from scratch: 

1. Is creating the VoiceCall record actually a hard prerequisite for the SIP transfer to reach an Agentforce Voice agent, or can it work without it?
2. Has anyone here already built the equivalent of that Lambda for a non-Amazon-Connect telephony vendor (Genesys or otherwise)? Happy to compare notes rather than reinvent it.

That error is the grader telling you two specific things about your agent: it must be Active, and its Type must be Flex. 

1. Type = Flex: this step expects an Agentforce (Flex) agent, not a Service Agent template or another type. In Agent Builder, check the agent's type — if it is not Flex, create a new agent and choose the Flex (general/customizable) type, then rebuild your topic and actions on it. 

2. Activate it: open the agent in Agent Builder and set it to Active (the Activation toggle / Activate button). The grader only sees it once the status is Active. 

Two prerequisites that quietly block activation: 

- You must be in the special Agentforce-enabled Developer Edition org for this badge, with Einstein turned on (Setup, Einstein Setup, On). 

- Any Flow you added as an agent action must itself be Active, or the agent will not activate. 

Fix the type and activate, then recheck. 

if this helps, please mark it as the Best Answer so it helps the next person — thanks 🙂

Hi Ivo,

When a case is created through email to case you can utilize Agentforce for service email.

How it works is based on email content Agentforce will reply back to end user. It will also have a disclaimer that it's sent via Agentforce agent.

Automatic Case Creation: When a customer sends an email, Agentforce uses Email-to-Case functionality to automatically convert it into a case within the Salesforce help desk system.

AI Analysis & Grounding: The AI analyzes the email's subject and description, identifies the request type, and grounds its responses in trusted data such as Knowledge articles and CRM data.

Context-Aware Responses: Using generative AI, Agentforce crafts natural, human-like, and context-aware responses that align with the business's rules and tone of voice.

Seamless Handoffs: For complex or sensitive issues that require human intervention, the AI seamlessly transfers or escalates the conversation to a live service agent.

Agent Support: Agentforce handles repetitive queries and tasks, allowing human agents to focus their time on high-value, complex issues.

Reference -