#Integration70 utenti parlano di questo argomento

A pattern I've seen work well is to keep Salesforce as the system of record and only send the minimum context needed for each request. 

I'd lean toward a custom LWC that calls Apex to retrieve the user's relevant context (recent purchases, role, allowed products, etc.), then sends that to your AI vendor with the user's prompt. If the vendor supports signed requests, wrapping the context in a short-lived JWT is a good idea to verify integrity, but I wouldn't use the JWT as the primary data store since payload size can become an issue. 

A few things I'd watch out for: 

•  Only send the attributes required to answer the current prompt (data minimization). 
•  Use short-lived tokens and avoid exposing sensitive IDs in the browser where possible. 
•  Keep authorization in Salesforce so the AI only receives data the user is entitled to access. 
•  Log the context sent for audit/debugging, but avoid logging prompts with sensitive information unless required. 

This is similar to how integrations with platforms like LeadAngel are often designed—Salesforce remains the source of truth, while external services receive only the contextual data needed to make a decision or return a response, rather than maintaining their own persistent copy of customer data. That separation tends to make governance and compliance much easier.

Glad that worked. DLRS is configured to use your browser session to manipulate Metadata in your org. Because that browser session, when used from Salesforce's servers, is coming from a different IP address, that setting prevents it from working.

If you do need that setting you can optionally just disable it while working on configuring rollups and deploying triggers. DLRS doesn't need access to the Metadata API outside of the administrative configuration so most of the time you could keep it enabled. Just leave yourself a note so you remember to turn it off when changing configurations.

(If you really get stuck you can always manipulate the Custom Metadata records via setup directly instead of using the configuration screens but that removes some of the safe guards to ensure your configuration is viable, use at your own risk)

You could also deploy the triggers to the org on your own instead of having DLRS do it for you. (You can take the expected trigger and test class from the Manage Child Trigger page for a given rollup)

Hi @Kunal Satghare,

Ensure that TestAdobeSign and Auth provider is set up correctly in salesforce with the appropriate endpoint and credentials.

Additionally, Please note that not all Adobe product APIs support the refresh token grant. I would suggest posting this question in the Adobe Community or reaching out to Adobe Support for further troubleshooting.

Hi @Anik Mallick, Unfortunately, there is not a single indicator in Salesforce that can definitively tell you whether an integration is still in use. However, you can gather enough evidence to make an informed decision by checking a few areas that mentioned below, 

• API Usage: Review Setup → System Overview → API Usage and Login History/Event Monitoring (API Total Usage) to see if the integration user or connected app has authenticated recently. 
• Named Credentials / Connected Apps: Check the Last Used Date (where available) or review authentication logs. 
• Debug Logs & Event Monitoring: If you have Event Monitoring, the API Event Log can show whether the integration has made API calls recently. 
• Scheduled Jobs & Apex: Verify whether scheduled Apex, Flows, Platform Events, or middleware jobs related to the integration are still running. 
• External System Logs: If the integration uses MuleSoft, Boomi, Informatica, etc., check those platforms for recent executions. Sometimes Salesforce shows the configuration, but the middleware confirms whether it's actually being used. 
• Last Modified/Created Records: If the integration updates specific objects, check for records recently created or modified by the integration user. 

In my experience, the best approach is to combine these technical checks with business validation. If both the technical evidence (no API activity, no scheduled jobs, no recent record updates) and the business confirm it's unused, you can confidently classify it as a candidate for decommissioning. If there is any uncertainty, consider disabling it first in a lower environment or monitoring it for a few weeks before removing it from production. This approach has worked well in my projects on few years ago. Since this was done in my career starting point and I also faced the same difficulties what you are facing now exactly. 

Hope it helps you.

@Amiya Das Sandip's right, fix the casing first, that's definitely causing the query to fail.

But even after that, getting the SF-hosted MCP server talking to Claude cleanly is its own headache. A few things that have caught people out: 

Your connected app needs cdp_query_api scope explicitly — general api scope isn't enough for Named Query / Data Cloud endpoints. 

Double check the MCP server URL is your org-specific one, not a generic Salesforce endpoint. 

Claude's MCP connector can be finicky with Salesforce's OAuth flow specifically, it doesn't always complete the handshake correctly even when everything looks right on the Salesforce side. 

If you've sorted the query bug and the connection is still unreliable , I've seen people work around it by routing through DataGrout, it sits between your Salesforce tools and the MCP client and handles the auth layer so you're not fighting the connector. Not saying that's your only option but worth a look if you're still stuck.

「chrome://settings/content/all」にsalesforceサイトの「ポップアップとリダイレクト」の権限を許可に設定していただいた上で

、再度お試しください。