Skip to main content

#Agentforce553 discussing

Agentforce is an umbrella term of the set of tools to create and customize agents as well as the collection of agents Salesforce provides across the Customer 360. Agents can either be autonomous or assistive.

***POLL IS CLOSED***

 

Lantern Astro won across every poll and will be the Winter ’27 Release logo!

_________ 

 

Help us choose the official Salesforce Winter ’27 Release logo.

 

Which character should star?

1️⃣ Agent Astro

2️⃣ Bookish Codey

3️⃣ Agent Appy

4️⃣ Lantern Astro

 

Cast your vote here, or vote in our polls on X, Instagram and LinkedIn (or all four!)

 

🗳️ Voting closes Friday, July 10. The character with the most votes will become the official Salesforce Winter ’27 Release logo. 

***POLL IS CLOSED*** Lantern Astro won across every poll and will be the Winter ’27 Release logo!_________ Help us choose the official Salesforce Winter ’27 Release logo. Which character should star?

191 comments
0/9000

Org: 00DdL0000108MPTUA2 (Developer Edition, Agentforce)    Agentforce Session Tracing worked correctly until 2026-07-27T10:31:48Z and has  captured nothing since. GET /services/data/v66.0/einstein/audit/otel/{sessionId}  now returns NOT_FOUND for every new session, while pre-27-July sessions still  return complete 6-span OTLP traces.    The agent works fine and the Builder Trace panel still renders spans with live  timings — so spans are generated, they just never reach Data Cloud.    Five pipelines stopped within 90 seconds of each other:    10:31:14Z  last AiAgentSession row    10:31:48Z  last ObservabilitySpans row    10:31:55Z  last EinsteinGPT gateway row    10:32:44Z  last ObservabilitySpans stream refresh    What I've found:    1. The ObservabilitySpans data stream reports ACTIVE / SUCCESS, but lastRefreshDate     is frozen at 2026-07-27T10:32:44Z while all 23 other streams in the org refreshed     within the hour. Its refreshConfig.frequency is an empty object {} — every sibling     stream shows MINUTES_5.    2. AiAgentSession / Interaction / GenerativeAiUsage streams run their 5-minute     refresh and report lastAddedRecords: 0 every time. They poll; core returns nothing.    3. All PR_*__dll reject tables are empty, so records never arrive at all. Not a     mapping or validation failure.    4. GenAIGatewayRequest__dlm still receives CopilotUtteranceAnalysis rows today but     zero EinsteinGPT (live chat) rows since 27 July. Same DMO — Data Cloud itself is     healthy.    5. Setup shows "Unable to fetch data stream details." and there is no "Refresh Now"     action for the Observability connector type.    6. PATCH /services/data/v66.0/ssot/data-streams/ObservabilitySpans returns:       BAD_REQUEST: "Unable to patch Data Stream: Index 0 out of bounds for length 0"     An unhandled IndexOutOfBoundsException — the stream record looks corrupt.    Already ruled out: API version (v66.0), auth, 72h retention (pulled a 15-day-old  trace fine), Setup toggles (all ON, cycled off/on), Standard Data Model package  (1.132), object provisioning, field mappings, API limits, tenant entitlements,  data spaces (only one), session ID format.    Questions:  - Has anyone else seen Agentforce telemetry stop publishing to Data Cloud around    27 July 2026? We see observability unavailable in a second, unrelated org too.  - Is there any way to repair or restart the ObservabilitySpans data stream when the    PATCH endpoint throws and there is no Refresh Now option?  - Is this a known issue?    Note: this is a Developer Edition org so I cannot raise a support case against it —  the Help portal only offers my Trailhead org, and Trailhead Help confirmed it's out  of their scope.   

1 answer
  1. Today, 7:44 PM

     

    Hi Yash - great write-up, and I see you've already ruled out the config side, plus this is a Dev Edition org with no case support. A few honest points: 

     

    What this is: an IndexOutOfBoundsException on a corrupt ObservabilitySpans stream record, with spans still generating (Builder Trace renders them) but no longer landing in Data 360, is a managed-pipeline / data-stream corruption on the platform side - not your config. Your ruling-out is right. And when the repair PATCH itself throws and there's no Refresh Now on a managed observability stream, there isn't a customer-side way to reprocess or rebuild it. That's the blunt bottom line. 

     

    Given no case support on Dev Edition, the realistic paths: 

    - If you just need tracing working again: provision a fresh Agentforce + Data Cloud Dev Edition. The corruption is org-specific (you noted a second org is unaffected), so a clean org gets a clean pipeline - quickest way to unblock. 

    - To get it acknowledged/fixed without a case: use the developer channels - the Salesforce Developer Forums (

    developer.salesforce.com/forums) and the Salesforce Known Issues site (issues.salesforce.com

    ). The OTel Session Trace API is still Beta, so a corrupt ObservabilitySpans stream is exactly what the Beta feedback / known-issues path is for, and the Agentforce product folks do watch this Agentforce group. 

    - Log an IdeaExchange for the gap itself: no Refresh Now / no reprocess option on a corrupt managed ObservabilitySpans stream is a legitimate product gap worth filing. 

     

    Meanwhile you're not fully blind - spans still render live in Builder Trace, and pre-27 sessions still return full traces via the OTel API, so you can export the historical data and lean on live Builder Trace until you cut over to a fresh org. 

     

    Refs: 

    - Export Agentforce Session Tracing Data (OTel API - Beta, Data Cloud-backed):

    https://developer.salesforce.com/docs/ai/agentforce/guide/otel-api.html

     

    - Data Model for Agentforce Session Tracing:

    https://help.salesforce.com/s/articleView?id=ai.generative_ai_session_trace_data_model.htm&type=5

0/9000

I’m testing an Agentforce agent that needs to query Salesforce records and perform actions on them. I want to make sure the agent only accesses records that the appropriate user is authorized to see.

What is the recommended way to configure permissions, sharing rules, and object/field-level security for an Agentforce agent? Are there any best practices for preventing the agent from accessing records outside the intended user’s permissions? 

 

#Agentforce

1 answer
  1. Today, 7:40 PM

    Hi Liza - the key model is that an Agentforce agent accesses data as a Salesforce user, so its record access is governed by that user's permissions and sharing - the same controls you'd use for a person. There isn't a separate 'agent record access' system; you configure the running user. 

     

    First, know which user the agent runs as: 

    - Autonomous / Service agents run as a dedicated assigned agent user (not the end customer). Whatever that user can see, the agent can see - so scope that user tightly. 

    - Employee/assistant agents run in the context of the logged-in user, so they naturally respect that user's access. 

    Pick the type that matches your requirement, then configure the running user's access to exactly the intended scope. 

     

    How to lock it down: 

    1) Object + field security (FLS): give the agent's user a dedicated permission set (least privilege) granting only the objects and fields it needs - read where it queries, create/edit only where it acts. Anything not granted is invisible to the agent. 

    2) Record-level (sharing): set OWD to the most restrictive level (Private), then open up only what's intended via sharing rules / role hierarchy. The agent inherits the running user's record visibility, so it can't return records that user can't see. 

    3) Actions carry context too: the agent touches records through its actions (Flows/Apex). Run those Flows in user context (the default - respects sharing + FLS) rather than System Context, which bypasses them. Use system context only deliberately, and validate inputs when you do. 

    4) Sensitive fields: use the Einstein Trust Layer's data masking so PII isn't sent to the model even for records the agent can read. 

     

    Best practices to prevent over-reach: 

    - Principle of Least Privilege: a dedicated permission set (or permission set group) for the agent user with the minimum objects/fields/records. 

    - Restrictive OWD plus targeted sharing rather than broad access. 

    - Keep actions in user context; reserve system context for narrow, reviewed cases. 

    - Test by checking the agent user's own access to confirm it genuinely can't reach out-of-scope records - the agent never exceeds what that user can access through normal sharing/FLS. 

     

    Refs: 

    - Give Users Access to Agentforce:

    https://help.salesforce.com/s/articleView?id=ai.copilot_setup_user_access.htm&type=5

     

    - Get Agentforce Ready - Profiles to Permission Sets:

    https://admin.salesforce.com/blog/2025/get-agentforce-ready-move-from-profiles-to-permission-sets-how-i-solved-it

0/9000

As I'm developing an agent that performs record DML and queries of records the current(human) user has access, but will be returned when trying from the agent interface? Whose access is applied in this scenario? 

 

#Agentforce

5 answers
  1. Aug 7, 4:42 AM

    Hi @VETHAPRASATH M

     

    The short answer: it depends on whether the channel your agent is deployed on requires an authenticated Salesforce session — not on the agent type itself, though the type strongly correlates with it in practice. 

    1. Authenticated channels (Lightning Experience/Mobile, internal Slack, an internal portal where the user is logged in) — the agent runs in the context of the logged-in human user. Your normal Salesforce access controls apply exactly as they would if the user clicked around manually: profile/permission set object & field-level security, sharing rules, role hierarchy, OWD. Whatever that user can query or DML, the agent can — nothing more, nothing less. If you're testing from the Agentforce panel inside Lightning while logged in as yourself, your own access is what's being applied. 

    2. Unauthenticated channels (public Messaging, embedded chat widgets, email) — there's no human session to inherit from, so Salesforce falls back to a dedicated Agent User: a special integration-type Salesforce user (License: Einstein Agent, Profile: Einstein Agent User) that you configure explicitly in Agent Creator. Here, the agent user's

    permission sets, field-level security, and sharing access govern everything — completely independent of what the anonymous customer typing into the chat could see.  

     

    Hope this helps.

0/9000

Dear Fellow Trailblazers,  

 

For the following trailhead unit "Build a Segment and Report" under "Explore Data 360 Core Functionality" Badge,  

 

https://trailhead.salesforce.com/content/learn/projects/explore-data-cloud-core-functionality/build-a-segment-and-report?trail_id=data-cloud-explore-setup-to-activation

 

I'm stuck on step 7 - 9 

Data 360 badge question -

 

When I search "Is US Based", I got the following: 

1. For a starter, I don't see a "Lead Category" on the screen 

 2. I don't see "

Lead.Party > Party.Individual > Unified Individual.Unified Individual Id.

" in container path 

 3. What's "Container Object Name"? It's not specified in the instructions  

image.png

 

What did I do wrong? 

 

#Trailhead Challenges  #Agentforce  #Salesforce Developer  #Trailhead  #Salesforce Admin  #Salesforce  #Certifications

4 answers
0/9000

Happy to share that I have successfully completed the Setup with Agentforce Quest

today. 

 

This hands-on experience provided valuable insights into how Agentforce can assist Salesforce administrators by simplifying routine setup activities through natural language interactions. Tasks like managing users, assigning permissions, and configuring setup components can be performed faster and more efficiently, allowing teams to focus on higher-value work. 

 

Looking forward to exploring more AI-driven capabilities within the Salesforce platform. 

 

#SetupWithAgentforce #Salesforce #Agentforce #AI #Trailhead

0/9000

Customer success goes beyond support—it’s about building lasting relationships. Charket WeCom brings customer context, conversations, case management, content analytics, and Agentforce-powered AI together in WeCom, enabling proactive support, faster issue resolution, and personalized engagement that drives long-term customer retention. 

https://explore.charket.ai/resources/9794832

#Charket #WeCom #WeChatSolutions #Agentforce

 

Customer success goes beyond support—it’s about building lasting relationships.

 

 

0/9000

I'm trying to complete Agentblazer and ive completed 96% of the training I'm stuck as I cant see Agent on the Dev Edition which I created at the beginning of this training. Has anyone faced similar issue, I need to get this done sooner as my playground expires on 10th Aug 

 

Issue with Agentforce

 

 

 

#Agentforce  #Trailhead

5 answers
  1. Ajaypreet Singh Saini (Grantbook) Forum Ambassador
    Aug 8, 7:40 PM

    Hey @sachin shinde, if somehow it's not working, yes you can create a new org and redo the work there 

     

    But make sure Enistein and Agentforce is enabled in your org

0/9000

Hi all — I'm trying to start a session with the Agent API and consistently get an HTTP 404 with an empty body. Authentication works, the agent is active, and every documented 404 cause seems ruled out. Looking for help on whether the Agent API is provisioned on my org, or what I'm missing. 

 

What I'm calling 

POST

https://api.salesforce.com/einstein/ai-agent/v1/agents/0Xxg5000000wKO9CAM/sessions

 

Authorization: Bearer <token>   (via Named Credential) 

Content-Type: application/json 

 

  "externalSessionKey": "pf-test-<uuid>", 

  "instanceConfig": { "endpoint": "

https://<mydomain>.my.salesforce.com

" }, 

  "streamingCapabilities": { "chunkTypes": ["Text"] }, 

  "bypassUser": true 

 

Response 

HTTP 404 

Headers: date, content-length, connection 

Body: (empty) 

Note: it's a bare 404 from the

api.salesforce.com

gateway — n token gives 401, and a wrong agent id (with the API reachable) gives a JSON error such as EngineConfigLookupException. Here the body is completely empty, which suggests the path itself isn't served for my org. 

 

What I've verified (all OK) 

- Agent is Activated, type ExternalCopilot (custom agent, not "Agentforce (Default)"). Agent Id 0Xxg5000000wKO9CAM taken from the Agent Builder / BotDefinition. 

- OAuth: External Client App with Client Credentials flow, sc. Run-As user = System Administrator (full Agentforcepermissions). Token is issued successfully (auth is not the problem — no 401). 

- External Credential (OAuth 2.0, Client Credentials with Client Secret) + Named Credential → URL

https://api.salesforce.com

, Generate Authorization Header enabled. 

- My Domain passed in instanceConfig.endpoint is the correct *.

my.salesforce.com

host (confirmed via URL.getOrgDomainUrl()). 

- Agent reactivated and waited for propagation — no change. 

- Added Agentforce permission sets to the running user — no change. 

 

Things I could NOT find in Setup 

- No "Agent API" / "Einstein Agent API" enablement toggle any 

- In Agent Builder → Connections, the only options are Enhanced Chat v2 and Messaging (both "Needs Setup"); Messaging for In-App and Web is not available (no Digital Engagement license on this org). There is no "API" connection option, and Add Connections shows an empty asset list. 

 

Environment 

- Agentforce Developer Edition org (orgfarm dev-ed). 

- Calling the Agent API from Apex (server-side callout via Na 

 

Questions 

1. Is the Agent API (/einstein/ai-agent/v1) provisioned/enablition orgs? If not, how do I enable it? 

2. Does the Agent API require an explicit connection/channel on the agent (beyond Activation)? If so, which one — given "Messaging for In-App and Web" isn't licensed here? 

3. Is a bare empty-body 404 from

api.salesforce.com

a known sned for this org" vs. a config issue? 

 

Thanks in advance — happy to share more logs/config. 

 

#Agentforce

2 answers
  1. Today, 7:27 AM

     An empty-body 404 usually points more toward an endpoint, API version, agent identifier, or org-level provisioning issue than authentication. I’d double-check the exact request URL and method, confirm the agent ID belongs to the same org, and compare the request against the latest API documentation. Also check response headers or request IDs, since they may reveal the actual routing error. 

0/9000

Hey #AwesomeAdmins - Setup with Agentforce is GA!   

 

 

On April 15 at True to the Core,

@Zachary Banks

asked a simple but important question about Setup with Agentforce. 

 

Yesterday, May 26, just 41 days later, we announced General Availability and provided an answer to his question - we will not consume Agentforce Credits. 🚀 

 

That timeline matters because it reflects something I’m incredibly proud of: we’re listening. 

 

Huge thank you to everyone who shared feedback, asked hard questions, and helped shape the product along the way. The community input genuinely influenced the direction of what we built. 

 

 

Read more about the GA announcement here:

https://admin.salesforce.com/blog/2026/setup-with-agentforce-is-generally-available

34 comments
0/9000