#Integration72 人正在讨论

I'm looking for guidance on the current recommended architecture for Agentforce + Experience Cloud + Embedded Messaging.

Original Architecture

I built an Experience Cloud (LWR) support portal using:

•  Agentforce Service Agent 
•  Embedded Messaging 
•  Omni-Channel 
•  Flow-based Agent Actions 
•  Custom Topics 
•  Salesforce Knowledge 

The solution was working during development.

What Changed

After Salesforce platform updates, the Embedded Messaging configuration changed significantly.

The setup started introducing additional messaging connectors/channels and configuration options that were not present when the project was originally built.

Since then, the previous implementation has stopped behaving as expected.

Current Situation

Authentication and Agentforce itself are working.

I have successfully:

•  Created an External Client App (ECA) 
•  Configured OAuth Client Credentials 
•  Obtained valid access tokens 
•  Retrieved my Agent information 
•  Begun testing the Agent API directly 

Because of the Embedded Messaging changes, I'm evaluating whether continuing with Embedded Messaging is still the recommended approach.

Questions

1.  Has the recommended architecture for Experience Cloud + Agentforce + Embedded Messaging changed recently? 
2.  Is Embedded Messaging still the preferred integration method for an external Experience Cloud support portal? 
3.  Should new implementations use the Agent API instead of Embedded Messaging? 
4.  Are there migration guides explaining the transition from older Embedded Messaging configurations to the current architecture? 
5.  If rebuilding today, would Salesforce recommend: 
   •  Embedded Messaging 
   •  Agent API 
   •  Messaging for In-App & Web 
   •  another supported approach? 

Goal

My objective is to build a production-style AI customer support portal following Salesforce best practices rather than relying on legacy configuration that may have been superseded by newer Agentforce capabilities.

Any clarification on the recommended architecture would be greatly appreciated. 

Update which I feel this will be helpful for the community, after a few rounds of Salesforce-Jira integrations, here's what's consistently saved us troubleshooting time: 

1. Don’t sync everything: Concentrate on business-critical fields (Case, Bug, Story, Priority, Status, Assignee, Resolution). A leaner scope will result in better performance, lower API usage and less conflicts. 

2. Go event-driven over scheduled polling: Keeps Support, Engineering, and Product on the same current data. 

3. Map fields before you build: Picklists, Statuses, Priorities, Record Types rarely map 1:1 across systems. 

4. Assign source of truth per field: Avoid update loops e.g. Engineering owns Resolution/Sprint, Support owns Customer Impact/Case Priority. 

5. Think about API limits. Bulk updates burn your allocation fast. Use batching, retries, error handling. 

6. Filter attachments/comments: Not everything should cross systems; filter by visibility, user type or keywords to keep internal notes internal 

7. Support multiple Jira projects/instances: Configurable mapping scales better than hardcoded routing logic 

8. Monitor failed syncs proactively: Logging + retry queues + alerts catch issues before they silently break workflows 

For

a Salesforce Jira connector, handles bi-directional sync without middleware and covers most of this out of the box. 

What I have seen from my personal experience: 

• Jira user-based price skyrockets as companies look to scale.
• Organizations require a single Salesforce Case to sync with numerous Jira issues but not all connectors enable this natively in SF.
• Parent-child Case circumstances necessitate workarounds particularly for enterprise support teams.
• Validating skills beyond the demo - real-world workflows help to identify shortcomings.
• Comment synchronization is an area that is often overlooked, yet it can have a significant influence on collaboration if it is not trustworthy.
• Also, don't just ask if it's 'bi-directional'; inquire about whether it's genuinely real-time and how it handles conflicts and retries.

These are just patterns I've observed across customer conversations and implementations. 

Hello everyone, we have an application that utilises Salesforce as the underlying platform, we don't have a direct commercial relationship with Salesforce themselves as a result - that relationship is instead managed by the provider of this solution (TrackWise Digital).  

We would like to use the information in TWD / Salesforce to populate an MS Fabric Lakehouse, for the purposes of business intelligence, integration with other systems and potentially even experiment with AI technologies at some point - but what is the best way to extract the data from Salesforce given it's the underlying "storage platform" for this solution?  

We've looked at various API's, e.g. SObject Reads / SOQL, but is there a recommended approach from anyone who has "been there, done that" - we would like to avoid going down the wrong roads with this and finding there was a better approach.  

Finally, in terms of access needed - what do we need to ask our partner Honeywell for in terms of access to allow access in the recommended way, is there a particular type of account / key to request?  

Thanks for reading folks, we're really interested in progressing this so your assistance greatly appreciated.  

Best regards 

Chris 

Hi Trailblazers,

I’m looking for some architectural advice on integrating a third-party GenAI search widget into our Experience Cloud / B2B Commerce site.

The Setup: We have selected a third-party AI search tool  that sits on our storefront to help users find case studies using natural language. For privacy and compliance reasons, we want this external AI to be completely "stateless."

The Goal: We want Salesforce to hold the "brain." Salesforce will retain the user’s history, past purchases (coursepacks), and role. When an authenticated user interacts with the AI widget (e.g., they ask, "Give me a refreshed version of my pack from last year"), we need Salesforce to dynamically pass that historical context (like past SKUs) to the AI widget at the exact moment of the query, without permanently storing PII on the third-party side.

My Questions:

1. Passing the Payload: What is the best practice for injecting this dynamic user context into an external widget? Should we use a custom LWC to fetch the user’s history via Apex and pass it as a hidden payload/parameter to the widget's API? Or is it better to encode this context into a JWT?
2. General Advice: Has anyone built a similar architecture where Salesforce acts as the memory engine for a stateless external AI? Any "gotchas" we should watch out for?

We are not looking to replace the tool with Agentforce at this time; we are strictly focused on the data integration layer between our chosen vendor and Salesforce.

Any insights, documentation, or recommended patterns would be hugely appreciated! Thanks!   

@* Salesforce Developers * 

The DLRS in our instance has broken.  Attached is the picture of the error page. We were on 2.14, I upgraded the package to 2.19, but the error persists. I cannot access anything within the app.  I have the system admin profile with the Metadata permission.  Please help, the Create/update Site Settings button does not seem to work, I click it and nothing happens

@Commons Project: DLRS @WIT Group, Charlotte, US @Who owes me a beer?!?

Description:

We are experiencing an issue with our Salesforce Named Credential TestAdobeSign and Auth Provider setup for integrating with Adobe Sign. After approximately one hour (3600 seconds), the following error is returned:

{"code":"INVALID_ACCESS_TOKEN","message":"Access token provided is invalid or has expired"}

Expected Behavior:

The access token should be automatically refreshed using the refresh token mechanism, ensuring continuous access to Adobe Sign without manual intervention.

Actual Behavior:

The access token expires after one hour, and no automatic refresh occurs, resulting in the above error.

Additional Information:

The Named Credential TestAdobeSign is set up to use OAuth 2.0.

The Auth. Provider for Adobe Sign has been configured correctly with all required endpoints and credentials.

The issue consistently occurs after one hour, indicating that the access token expiration is not being handled as expected.

@* Salesforce Developers *