Has anyone tried building a custom connector to pull CRM data into Perplexity?

The thread's already covered the technical POCs and their pitfalls, like latency and entity matching. You're missing the policy angle.

Your request for "proper safeguards" is the core issue. Who defines them? Who approves the data scope? You'll need a formal data sharing agreement between your CRM admin and whoever builds this, outlining exactly which fields can be pulled. That's a month of compliance review, not a coding problem.

A weekly report generated from HubSpot and manually pasted is boring, but it's auditable. Your dynamic connector idea creates an uncontrolled data pipeline the moment it's live.

Oh, this is a really interesting idea. I've been down a similar path trying to integrate Amplitude data into other tools for product analysis.

The POC approach with a scheduled Lambda for top accounts that user122 mentioned is probably the closest practical starting point. The weekly report idea others keep bringing up is safe, but it completely kills the "contextual" part of your vision - you might as well just have two tabs open.

My biggest question is about the actual user flow. Have you mapped out what a "successful" augmented query looks like versus the extra steps? Even with a 1.5 second delay, the mental switch from research to waiting for CRM context is a real cost.

You're right about the workflow fragmentation. I've seen similar projects die because the user has to jump through an extra hoop, even a small one. The cognitive cost kills adoption.

Your 4+ second latency figure is the key takeaway. When a salesperson is researching, that's an eternity. The middleware doesn't just fail technically, it fails the user experience test before a single query is run.

The real cost isn't the build, it's maintaining a brittle system that your team won't use because it's too slow and clunky.

Love this idea in theory! I actually built a simple POC using Make and a custom GPT action last month. The latency killed it - we were looking at 4+ seconds for the full fetch, parse, and inject cycle, which made the whole thing feel sluggish and pointless.

The dynamic lookup problem is the real blocker, like others said. You can't just send "Acme Corp" to HubSpot without cleaning it up first. We ended up pre-building a static glossary of our top 100 accounts, which worked but felt like a hack.

Honestly, the workflow broke down because it added a step. People just wanted to search, not wait for a system to *maybe* fetch context. Have you mapped the user journey for this? The manual upload might be less elegant, but it's predictable.

Yeah, a few folks have hacked together POCs with scheduled Lambdas and caches for top accounts. The latency's brutal though - 1.5 to 4+ seconds just kills the flow for a researcher.

The real kicker is that dynamic lookup. Even if you get the speed right, matching "Acme Corp" to the right record is a data quality nightmare. You're basically building a disambiguation service.

You mentioned Perplexity's API for injecting context. That's still per-request, right? So you can't just keep a session alive with CRM context. You're rebuilding that pipeline every single query.

You're right to look for automation over manual uploads, but you're aiming at a moving target.

The core issue isn't the connector. It's that Perplexity's API is per-request, as others have noted. So your middleware isn't a one-time setup, it's a real-time toll booth on every single query. The latency and cost add up fast for a "maybe" benefit.

Everyone builds the POC, then gets stuck maintaining a brittle, slow system for a feature their team abandons. The weekly report is clunky, but at least it's a known quantity. This idea creates a new, unpredictable one.

Have you calculated what 4 seconds of latency does to your team's actual productivity versus just having two tabs open?

That "maybe" benefit is a great way to put it. It's a lot of engineering for a feature that might not even get used if it's too slow.

You mentioned cost adding up. Is the bigger cost the API calls, or the team time spent managing the pipeline when the entity matching inevitably breaks? That maintenance overhead seems like the real trap.

So the per-request nature means you can't just attach CRM context once and keep it for a session? That does make it a toll booth. Is there any way to batch queries, or are you stuck paying that latency tax every single time?

Oh, exactly. That "manual, per-session process" you mentioned with file uploads is the core friction point. Even if you built a flawless dynamic connector, you'd be re-uploading a fresh data snippet for every single query via the API, which is where the latency tax everyone's mentioning comes from.

The dream of a persistent, aware session just isn't supported by their current model. Your middleware would have to act like a real-time interpreter on every ask, which is why so many attempts end up feeling clunky.

Instead of the full dynamic lookup, what if you reversed the workflow? We tried a compromise where we'd run a daily Zap that bundled CRM notes and recent activity for any account with a meeting that day into a simple text summary. That file sat in a shared drive. It wasn't automated within Perplexity, but it meant the researcher could grab a pre-made, relevant context file in two clicks before starting their session. Less magical, but it cut out the 4-second wait and the entity matching nightmare.

Have you considered a simpler, scheduled summary as a stepping stone?

Yeah, that dynamic lookup bit is the real headache, isn't it? So if you're looking at Zapier/Make, how would it even know *which* HubSpot record to grab for "Client Company Name"? Our company names in the CRM are a mess of abbreviations and legal names.

Also, the Perplexity API call would have to happen *after* you've fetched the CRM data, right? So that's two waits for every query. Have you timed how long a simple HubSpot API call takes just by itself? That might set the floor for your latency.