#Salesforce Developer토론 중인 항목 382개

Hi @Jean Baptiste, 

Here are my thoughts: 

 1. Apex — no built-in fuzzy/semantic matching. You can have some options for typo-tolerance, but that wont serve the purpose for your example usecases. Apex can be skipped for this. 

2. SOQL/SOSL

 — SOSL gives you basic fuzzy text search (stemming, wildcards) but won't catch reordered/paraphrased meaning like your examples. Fine for simple "contains this keyword roughly" checks, not for what you're describing. 

3.  Einstein/NLP — this is the right layer. If data is already in Data360, then creating semantic layers could help. If data is in CRM, i suggest you to try prompt templates that  could classify/compare intent semantically. I personally like Prompt Templates as they are easy to debug and work with. Much less overhead than building your own embedding/cosine-similarity layer.  

4. AppExchange  — a few text-analytics/NLP AppExchange packages exist but most just wrap external NLP APIs, and supposedly would incure additional costs as well.  

Hope this helps. 

Thanks for testing those, Souvik - since browser, My Domain, and admin are all ruled out, that error is almost certainly coming from one specific org-wide setting: 'Require Proof Key for Code Exchange (PKCE) Extension for Supported Authorization Flows' in Setup > OAuth and OpenID Connect Settings. 

Here's the trap: you mentioned enabling PKCE there. When that org-wide toggle is on, the org forces a code_challenge on every supported authorization flow - but the internal namespace-linking flow doesn't send one, so it fails with exactly 'missing required code_challenge'. So that setting being enabled is what's breaking the link, not something you're missing. 

The fix: turn that setting off (Setup > OAuth and OpenID Connect Settings) in the org that owns the namespace - and in the Dev Hub too if it's enabled there - then retry the namespace link. Once it's linked, you can switch it back on if you want PKCE enforced for your own apps. Note this org-wide toggle is separate from the greyed-out PKCE box on the Salesforce-managed connected app you can't edit - this one you do control. 

If it's already off and still fails, then it's on Salesforce's side (the managed linking app), and the right path is a Partner Support case referencing the error - it's a managed flow you can't patch yourself. But I'd bet on the org-wide setting; toggle it off and the link should go through. 

Hope that finally clears it! 

And if this resolves it, please mark it as the Best Answer so it helps the next person who hits this - thanks! 🙂

Hi @Shubham Kukreti,  

As far as I know, Salesforce doesn't provide a supported LWC API to directly launch the standard Change Owner modal that appears on record pages.

The standard dialog is tied to Salesforce's internal UI actions and isn't exposed through NavigationMixin, Lightning Data Service, or Apex.

Your can try below options:

• Use the standard Change Owner action on the record page.
• Navigate users to a standard Salesforce page/action if the object supports it.
• Build a custom LWC modal that updates the OwnerId field and handles any additional options such as email notifications.

One thing I'd be interested to know is whether anyone has found a supported navigation pattern similar to standard quick actions that opens this specific dialog. I haven't seen documentation exposing the Change Owner popup directly to custom LWCs.

Hi Kanchana,

This is one of the most frustrating discrepancies when moving from the isolated testing harness to live channel execution.

Here is the breakdown of why this happens, what Miscellaneous_Category represents, and how to fix it:

Why Builder Test Works While SCRT2 / Embedded Messaging Fails

• The Test Harness Bypasses the Channel Ingestion Pipeline: In Agentforce Builder Live Test, you are testing in a sanitized, pre-scoped runtime sandbox. The canvas test runner directly feeds your input text into the agent runtime orchestrator with start_agent already instantiated in memory.

• The SCRT2 Intake Pipeline Injects Channel System Metadata: When an inbound message arrives via SCRT2 / Embedded Messaging, Salesforce's runtime prepends channel, transcript, and identity metadata envelopes into the initial LLM prompt payload.

• What Miscellaneous_Category Actually Is: In the underlying Service Cloud Real-Time / SCRT2 classification tier, Miscellaneous_Category (or "General / Uncategorized") is the default intent catch-all evaluated before intent handoff to specialized subagents occurs.

• If the pre-routing classifier cannot determine intent with high statistical confidence—or if the prompt framing triggers ambiguity due to the channel context wrapper—it flags the utterance as Miscellaneous_Category. Because that fallback category owns no actions or subagents, execution gets trapped in root-level generation (Subagents: NOT_SET, InstructionAdherence: LOW).

Direct Answers to Your Questions

1. Why does it select Miscellaneous_Category?

The initial classifier evaluates the combined message payload and context against topic/subagent descriptions. Because Live Test lacks the SCRT2 wrapper, the raw prompt directly matched your subagent. In live chat, the presence of the channel wrapper diluted the match confidence, tripping the platform's default fallback guardrail.

2. Is there a configuration requirement for custom subagents on this channel?

Yes: Explicit Channel / Topic Scope Definition and Context Mapping. On live channels, if an agent has only one subagent and no broader system scope, the classifier struggles to resolve context. The top-level agent must contain an overarching instruction set that defines the agent's core identity and explicitly delegates execution to the subagent.

3. Can Miscellaneous_Category be removed or disabled?

No. It is a hardcoded system fallback inside the SCRT2/Einstein AI runtime layer designed to prevent an agent from invoking unvetted actions when semantic confidence falls below threshold. You cannot turn it off in Setup, but you can prevent the model from landing in it.

4. Is this a known limitation?

It is a known architectural nuance between the low-level Agent Script runtime and the enhanced channel gateway (SCRT2).

How to Fix It

Step 1: Elevate Intent Scope to the Top-Level Agent Instructions

Do not rely exclusively on the description within the subagent. The channel router evaluates the Top-Level Agent Instructions first.

• In your top-level Agent definition, explicitly define the domain boundary:

Step 2: Check Pre-Chat & Transcript Passing in Omni-Channel Flow

• In your Omni-Channel Flow, inspect the Route Work element.

• Verify if you are passing the input_transcript or Chat Transcript record properly into the Agent input variables. If the routing payload delivers an empty or malformed string on initial handshake, the classifier evaluates an empty prompt, automatically dumping the session into Miscellaneous_Category.

Step 3: Add a Fallback Classification Rule

If the subagent is still ignored on turn 1, configure a secondary topic or instruction:

• Under your Agent's primary topic instructions, add:

Hi Lena, since both orgs are on the same laptop/browser and your Salesforce config in Org B genuinely looks correct, this is very likely a browser/Windows-side caching issue tied to the different origin (domain), not a Salesforce policy difference. A few things worth checking: 

1. Check Windows' own Passkey manager for a stale entry. Go to Windows Settings → Accounts → Passkeys (or Sign-in options → Passkeys). Look for any existing entry tied to Org B's domain — even a partial/failed registration attempt from earlier can cause Windows to skip the "create new" platform flow and jump straight to the cross-device/roaming flow instead. Delete any entry there for Org B's domain, then retry from Salesforce. 

2. Clear the browser's per-site permissions for Org B's domain. Chrome/Edge cache a "last used transport" preference per relying-party origin. In Chrome: Settings → Privacy and security → Site settings → search for Org B's domain → Clear data/reset permissions. This forces the browser to re-evaluate available authenticators instead of defaulting to whatever you (or a prior session) picked before. 

3. Confirm Org B's My Domain is fully deployed, not just the default login URL. WebAuthn ties credentials to the Relying Party ID (essentially your domain). If Org B is still on a default/undeployed domain or recently changed its My Domain, the RP ID Salesforce sends can differ from what you'd expect, which changes how the browser matches existing/available authenticators. 

4. Try a fully fresh browser profile/incognito window against Org B only, to rule out any extension (you mentioned Microsoft Authenticator extension is on in both — try disabling it just for this test) or cached state interfering specifically with that origin. 

5. As a last resort, use "Disconnect a passkey that isn't working" from your Salesforce personal settings (Advanced User Details → Built-In Authenticators → Del on any existing/broken entry for Org B), then try Add again from a clean state. 

If none of that breaks the loop, this is worth escalating to Salesforce Support directly with both orgs' IDs — a same-device, same-browser, config-identical discrepancy between two orgs isn't something Setup-level settings can explain, and Support can check server-side registration options (like exclude-credential lists) that aren't visible from the UI. 

Reference:

•  Metered: Agentforce usage is charged based on consumption; for agentic usage, the main unit is generally actions, not simply tokens or conversations.  
• Flex Credits: A standard Agentforce action currently consumes 20 Flex Credits, while custom actions are also measured by the number of actions called. 
• Unmetered: Certain licensed users/features can use qualifying Agentforce capabilities without consuming Flex Credits, when the required licensing, permissions, and execution conditions are satisfied. 
• Important: “Unmetered” does not mean everything in the agent is free; underlying services such as Data 360 can still consume credits. 
• Employee Agents: Agentforce add-ons provide unmetered Agentforce usage for employees; the Agentforce User License, by contrast, provides metered employee usage and requires Flex Credits. 
• Customer-facing Agents: Salesforce currently offers both Flex Credits (pay per action) and Conversations (pay per conversation) for customer-facing agents. 
• High-volume usage: Consumption-based pricing makes the cost depend on actual usage, so action/conversation volume and the specific features used need to be estimated rather than assuming one fixed cost. 
• Monitoring: Use Digital Wallet to monitor Agentforce consumption and usage in the org. 
• Forecasting: Salesforce recommends reviewing actual Digital Wallet consumption and working with your Salesforce Account Executive for contract-specific pricing and usage estimates. 
• Bottom line: Metered = pay according to usage; Unmetered = qualifying usage included through specific licenses/permissions. Which is more cost-effective depends on your users, volume, features, and contract—not simply whether the agent is internal or external. 

Also, go through the doc it helps you--->

 Agentforce and Generative AI Usage and Billing | Salesforce Help

Considerations for Agentforce Employee Agent | Salesforce Help

Metering for Agentforce and Generative AI Usage | Salesforce Help

Salesforce Agentforce Pricing | Salesforce 

Hi @Uma Kotha

You can explore KnowWho for Salesforce, which provides elected official and staff contact data within Salesforce.

For tracking roles, term start/end dates, and election-cycle changes, you could also consider creating a custom Election Term object related to Accounts and Contacts, with Salesforce Flow to automate updates.

🔗 KnowWho for Salesforce

Please verify whether KnowWho supports your specific term-management requirements.

Hope this helps!  

 If you find this response helpful, please mark it as the Accepted Answer, as it may also help other Trailblazers. 😊