We are deploying Enhanced Bots (Einstein Bots) on our company website using Embedded Messaging. We've enabled "Conversation Transcripts on Data Cloud" to analyze bot conversation data via reports. **Goal:** We want to filter out internal employee conversations from analytics/reports so we can focus on actual customer interactions. **Challenge:** Since Embedded Messaging is accessed via a public website (no login required), there's no built-in way to identify whether a conversation was initiated by an internal employee or an external customer. The ConversationEntry data in Data Cloud doesn't include any user identity or IP address information. **What we've considered so far:** 1. **Hidden Pre-Chat fields** – Using the Messaging Web API to pass a hidden field (e.g., a flag set by server-side IP detection) before the conversation starts. This seems viable but requires custom web implementation. 2. **Adding a bot question** ("Are you an employee?") – Rejected because it adds friction and may reduce utilization rates. 3. **Separate deployment per audience** – Deploying different Embedded Service configurations for internal vs external pages, but this adds operational complexity. **Questions:** - Is there a recommended or built-in way to tag/identify user type (internal vs external) in Enhanced Messaging conversations? - Has anyone successfully used Hidden Pre-Chat fields with Enhanced Bots to pass custom metadata that appears in Data Cloud transcript data? - Are there other approaches we haven't considered? **Environment:** - Salesforce Enterprise Edition - Enhanced Messaging channel with Enhanced Bots - Data Cloud enabled for conversation transcript analysis - Embedded Messaging for Web (MIAW)
,
Internal Employees vs external customers are archtecturally dealt differently via Agentforce Service Agent vs Employee Agent.
All user interactions with an Employee Agent are ought to be be happening with internal employees only.
For Agentforce Service Agent, ideally this would be hosted on a public facing website, with customers as the targeted users.
If at all there is a scenario that internal employees and external users are using same interface, first step would be authentication of the users (via email or phone), and then match them with exsiting data. If your match is successful with the Customer table, then user shall be a external user, and if the email/phone gets matched with the User table, that would be an employee only.
