Self-Hosted AI Research Infrastructure Behind a Salesforce Deal Engine

#The starting position

The firm sources acquisition targets for investors, each with a mandate describing what they want to buy. In Salesforce, we had already built the investor and deal model and an AI matching workspace where analysts review scored candidates and approve them. That workspace is where decisions happen.

The research behind each score is a different kind of work. Screening a company properly means reading its website and other public sources, comparing what is found against several mandates, and asking a language model to score and explain the fit. Multiply that across many companies and many investors, and it becomes a high-volume, long-running workload: lots of external requests, lots of model calls, and jobs that can take longer than a typical transaction inside a CRM should.

The firm also wanted room to experiment. New ranking approaches, idea generation and larger batches all needed a place to be tried without disturbing the analysts working in Salesforce every day.

Running all of that inside Salesforce would have meant fighting platform limits and paying for capacity in the most expensive place. Running it in a disconnected tool would have meant results nobody could audit. The firm needed infrastructure that could do the heavy research work efficiently and hand every result back to Salesforce, where the decisions and the audit trail live.

#What we built

01 Orchestration with n8n

Research jobs are orchestrated with n8n workflows. When a candidate needs research, the job is picked up by a workflow that runs the steps in order: gather information, read the relevant mandate, call the model, and write the result back. Workflows can be inspected and adjusted without rebuilding the system.

02 A PostgreSQL working store

A PostgreSQL database holds working data and the state of research jobs, so long-running work can be tracked, resumed and inspected.

03 Web research with Firecrawl

Firecrawl gathers information about candidate companies from the web, turning public pages into content the model can read. Research is grounded in what the company actually says about itself.

04 Mandate documents from Google Drive

The firm's investor mandate documents live in Google Drive. The infrastructure reads them from there and connects them to the investor in Salesforce, so the criteria used in scoring can be traced to the documents investors provided.

05 Self-hosted deployment with Coolify

The stack runs on a self-hosted server, deployed and managed through Coolify. The firm owns the infrastructure, controls its data and has predictable running costs instead of per-transaction pricing for every research step.

06 Results written back to Salesforce

Every score, rationale and red flag produced by the research is written back to the match record in Salesforce. Analysts review and approve matches there, and approved matches become deals, so the CRM remains the single place where the process is visible and auditable.

#How a research job flows

An analyst tags a batch of candidate companies for several investors in Salesforce. For each company and mandate pair that needs deep research, a job is handed to the n8n workflows.

The workflow gathers the company's public information with Firecrawl, reads the relevant mandate from Google Drive and asks the language model to score the fit, explain it and list red flags. The job's progress is tracked in PostgreSQL, so the state of every piece of research can be followed. When the result is ready, it is written back to the match record in Salesforce.

The analyst sees the scored match in the workspace they already use, reads the rationale and approves or rejects it. None of the infrastructure is visible to them, which is how it should be. From the analyst’s point of view, the matching workspace simply has better research behind every score.

#Ongoing experiments, kept separate

Alongside the production flow, the infrastructure supports experiments: AI idea generation for new target lists, an alternative ranking proof of concept, and large-batch screening with performance testing. These run apart from the production process, and their results are measured before anything is promoted. Throughput targets for large batches are goals under test, not reported results, and we describe them that way.

#Why split the work this way

Salesforce is excellent at what the firm needs most: structured business data, permissions, approvals, reporting and an audit trail. It is not designed to run thousands of long web research jobs and model calls as cheaply as possible. Dedicated infrastructure is.

Splitting the work by what each system is good at gives the firm the best of both. The research runs where it is efficient and controllable. The decisions stay where they are visible and governed. And because every result is written back, nothing important lives only in the side system.

Self-hosting is a deliberate choice with trade-offs. It gives the firm control of its data and predictable costs, and it means someone has to run the infrastructure: monitor it, update it and keep it secure. Deploying through Coolify keeps that operational work manageable, and it is part of the ongoing engagement.

#Security and data handling

Moving part of a process outside Salesforce raises fair questions about data, and the design answers them directly.

The research layer works on research inputs. Its job is to study companies against mandate criteria, so the design centers on those inputs instead of copying the CRM into another system.

The firm owns the server. Because the stack is self-hosted, data processed during research stays on infrastructure the firm controls, instead of passing through a third-party automation platform.

Results come home. The outputs that matter, the scores, rationales and red flags, are stored on Salesforce records, under Salesforce permissions, where the firm already governs access.

Documents stay in place. Mandate documents remain in Google Drive, where the firm manages them, and are read from there instead of being copied into another store.

These principles keep the research layer an engine rather than a second database of record, which is what makes it safe to run alongside a CRM that holds sensitive investor information.

#How we delivered it, end to end

Decide what stays in the CRM. Investors, mandates, matches, approvals and deals stay in Salesforce. Research jobs do not.

Design the hand-off first. The contract between Salesforce and the workflows, what is sent out and what comes back, was agreed before building either side.

Track job state. PostgreSQL holds job state so long-running work is observable.

Ground research in sources. Web research and mandate documents feed the model, so scores trace back to evidence.

Separate experiments from production. New approaches are tested and measured before they touch the live process.

#The decisions that mattered

Two systems, one record of truth. Infrastructure for the work, Salesforce for the decisions, with everything written back.

Self-hosted for control and cost. Owning the stack made high-volume research affordable and kept data under the firm's control.

Honest performance claims. Batch throughput is measured before it is reported.

#What changed

#What we would tell a firm building AI research at volume

Decide early which system owns the decision and which system does the work. Keep decisions, approvals and the audit trail in your CRM, and run heavy research on infrastructure designed for it. Connect the two so every result comes home to the record that matters, and measure performance before you promise it.