#Agentforce373 utenti parlano di questo argomento

@Reno Redaja

Document Processing runs as an Agentforce agent action, so it isn't on a separate meter - it draws from your Agentforce Flex Credits (the same metered pool your agent actions use, billed monthly in arrears). Data Cloud has its own Flex Credits for Data Cloud operations, but the agent-action invocation itself is Agentforce credits. 

To see it, go to Setup > Digital Wallet - that's the central, near-real-time dashboard for Flex Credit consumption (agent actions, usage, balances). You won't find a line literally labelled 'Document Processing'; it shows up as the consuming agent's action usage, so read it there by agent/action. You can also add Consumption Threshold Alerts via a Flow to get notified as usage climbs. 

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

@Manas Datta

Thanks for testing that - a correct id still landing on the bare panel actually rules the id out and points to an enablement gap. open() drives the SAME native Agentforce side panel you'd get manually, and botId is only optional targeting - if that agent isn't the one wired to the panel for your running user, open() falls back to the default panel/picker no matter which id you pass. 

Quick way to confirm: open the native Agentforce panel manually (the Agentforce icon, not your LWC). If it also drops you on a picker or the wrong agent, it's the setup, not your code - check the agent is Active, is the one enabled for the Agentforce panel in that org, and your running user has access to it (permission set + the agent's assigned users). Fix that and open(botId) will land on it. 

If you need a specific agent guaranteed every time regardless of the panel, skip accApi and use the Agent API instead (Connect REST /einstein/ai-agent, or its Apex wrapper): you start a session against the exact agent id server-side and render the replies in your own LWC chat UI - no panel, no picker, fully deterministic.

@Commerce Trailblazers @* B2C Commerce * @* Commerce Salesforce Order Management * @Serviceblazer Community Group @MomentMarketer Community Group @* Salesforce Developers * @Trailblazer Community Cove @Trailblazer Community Cove@* Salesforce Administrators *@* Salesforce Developers * @* Salesforce Platform * @* Trailhead Academy * @Newbie Tableau User Group Desktop @Tableau Analytics @Tableau Announcements @Slack Beginners @Slack + Agentforce @Salesblazer Community Group @Agentblazer Community Group @* B2C Commerce * @* Salesforce Commerce for B2B & D2C * @* Salesforce Revenue Cloud * @* Data 360 * @* Sales Cloud - Getting Started * @* Sales Cloud - Best Practices * #Trailhead #AI #Agentforce #Salesforce Developer #Salesforce Admin

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 Asika, 

If I'm reading this right: when naming your agent in Agentforce Builder, the Developer Name field isn't auto-populating from the Agent Name, or it's rejecting the name because it's not unique. Here's how to fix that: 

1. On the "Name Your Agent" screen, the Developer Name (API Name) field is separate from the display Agent Name. It doesn't always auto-generate, especially if you're reusing a name that's close to an existing agent's API name in your org. 

2. Developer Names must be unique across your entire org (not just among agents), no spaces, and must start with a letter. If your typed name has spaces, special characters, or matches something already used (even a deleted/inactive agent's leftover API name), Salesforce will block it and ask for a different one. 

3. Manually edit the Developer Name field directly, click into it and type a clean, unique value (letters, numbers, underscores only, e.g. My_Service_Agent_2). Don't rely on auto-generation if it's not populating from your display name. 

4. If it keeps rejecting even a name you're sure is unique, check Setup > Agentforce Agents (or Bots in Setup) to see if a previous draft/deleted agent already used that Developer Name, deleted agents can still hold the API name reserved in some cases. 

If this isn't quite the issue you're hitting, could you share the exact error message or a screenshot? That'll help me point to the precise fix instead of a general one.