#Agentforce519 personnes en discutent

Hey Karthick, 

The errors in your second screenshot tell you exactly what's wrong: 

"Action input 'Guests' in 'Create_Experience_Session_Booking' has primitive type 'number' and does not require 'complex_data_type_name'" 

"Action input 'startDate' in 'Get_Sessions' has primitive type 'date' and does not require 'complex_data_type_name'" 

Basically, someone (or the auto-generation) set a complex_data_type_name on these two inputs, but that field is only meant for object or list[object] type inputs. Since Guests is a number and startDate is a date, both primitive types, that field should be empty for them. 

Fix: 

1. Open the Create Experience Session Booking action, find the Guests input parameter, and clear out the complex_data_type_name value, leave it blank 

2. Do the same for the startDate input in the Get Sessions action 

3. Save, then check the Problems panel again, the 2 warnings under it are worth reviewing too but the 3 errors should clear once these two inputs are fixed 

These usually come from the action being generated off a Flow or Apex class where the parameter metadata got mismatched. If you're pulling these actions from a Flow, double check the Flow's input variable data types match what's expected (number/date, not a record/object type) before regenerating the action. 

Reference:

Hi , 

Please check this article.  

I just figured it out. Einstein Bots are disabled causing this error. Go to setup -> Einstein Bots -> Turn On. 

Should be good to go 

https://trailhead.salesforce.com/trailblazer-community/feed/0D5KX00000jANqW

Error: We see you're using the Agentforce org from the quick start. But it's not prepared for agent deployment into Slack. Complete the steps from quick start to ensure you can set up the agent.

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 (

). 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):

- Data Model for Agentforce Session Tracing:

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:

- Get Agentforce Ready - Profiles to Permission Sets:

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.