#Integration69 人がディスカッション中

@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サイトの「ポップアップとリダイレクト」の権限を許可に設定していただいた上で

、再度お試しください。 

Hi Katende! Sorry for the delay and thank you so much for the detailed follow-up! 

1. I would anticipate this to be well under 50,000 records, as this will just capture our daily continuing education/open enrollment registration activity. 

2. I am thinking this would be a full system extract. 

3. I could ask, but I'd like to avoid having to use our IT department as much as I can. 

4. I think using a cloud option is the way I'm going to go 

5. It is sounding like it will be clean. The core fields required for the EDA object are present. 

6. Lumens has a unique Learner ID that will have to be mapped to an External ID field on the Salesforce Contact object. 

7. I'd like to have no code.

The approaches mentioned above (API + Automation Studio, webhooks, or middleware) are all valid. 👍 I'd just add a few considerations based on webinar setups I've seen over time.

If Zoom is already a fixed requirement, I'd like @EDGAR Joes suggests, lean towards webhooks or scheduled API syncs over relying heavily on middleware logic/third party apps like Zapier. Keeping Marketing Cloud responsible for segmentation and journeys, while treating the webinar software as the source of engagement data, tends to be easier to maintain.

If you're still evaluating the webinar platform itself, it's also worth looking at solutions with native Salesforce integrations (for example Univid) that can pass registrations, attendance, watch time and other engagement signals directly into the Salesforce ecosystem, instead of building/maintaining the integration yourself. That can reduce the amount of custom integration work over time, as things update and change.

Curious what approach you ended up taking.

We've seen similar challenges with Zapier and Salesforce over time. It works, but running a third-party integration means depending on three different platforms that can each introduce breaking changes, and where you hit API limits etc.

If webinars are a core workflow rather than an occasional use case, I'd look at moving to a webinar platform with a native Salesforce integration instead of maintaining middleware long term, similar to what @Arpita Chakraborty

suggests in (2). Imo that's been much more stable than relying on Zapier for registrations and attendance sync. 

Also you can usually get a more automated setup, for example where you:

• create webinars from Salesforce Campaigns
• handling registrations through MCAE (ex Pardot)
• and syncing richer engagement data back to Salesforce Campaign Members (watch time, attendance status, polls, CTA clicks, etc). 

Imo that makes lead scoring + follow-up more accurate, as well as admin more efficient.

We've had good experiences with the Univid webinar platform for this kind of native setup, but I'd recommend any setup with a webinar platform that has a native (and well-supported) Salesforce integration rather than building around Zapier - if long-term stability is the main goal (rather minimizing cost). Let me know how it goes!

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.