# Self-Hosted AI Research Infrastructure Behind a Salesforce Deal Engine

> A private equity advisory firm needed AI research at a volume and cost that Salesforce alone was not designed for. We built a self-hosted agent stack, with n8n workflows, a PostgreSQL store and web research, that does the heavy lifting outside the org and writes every result back to Salesforce, where the deal process lives.

- Source: https://synconai.com/case-studies/self-hosted-ai-research-infrastructure
- Publisher: SynconAI (https://synconai.com)
- Type: Case study
- Evidence: Delivered client engagement. The client is anonymised; the industry, products and outcomes are theirs.
- Organisation: A United States private equity and investor advisory firm running AI-assisted company screening for multiple investor mandates
- Industry: Financial Services
- Products: n8n, PostgreSQL, Coolify, Firecrawl, Salesforce Platform, Google Drive, Large language models
- Service: Custom AI Development (https://synconai.com/custom-ai-development)
- Reading time: 6 minutes

## In short

We built self-hosted AI research infrastructure for a US private equity advisory firm. n8n workflows, a PostgreSQL store, Firecrawl web research and Google Drive mandate documents run on a server deployed with Coolify, doing heavy research outside Salesforce and writing every score and rationale back to the match records, where analysts approve them.

## Key points

- Put each workload where it fits. Salesforce is the right home for decisions and audit trails; long-running research jobs belong on infrastructure built for them.
- Write everything back. Research that stays in a side system is research nobody can audit; results belong on the CRM record that drives the decision.
- Self-hosting buys control and predictable cost, and it brings responsibility for operations. Plan for both.
- Measure before you promise. Throughput targets for large batches are tested, not assumed, before anyone reports them.

## Where each part of the work runs

At the top, Salesforce holds the business process: investors, mandates, candidate companies, match records, approvals and deals. Beneath it, an orchestration layer of n8n workflows receives research jobs from Salesforce and runs them. The research layer gathers information about companies from the web with Firecrawl and reads mandate documents from Google Drive, and language models score and explain the fit. A PostgreSQL store holds working data and job state. Everything is deployed on a self-hosted server through Coolify, and every result is written back to the match record in Salesforce.

### 1. System of record

- Salesforce
- Mandates
- Match records
- Deals

Decisions and audit trail stay in the CRM.

### 2. Orchestration

- n8n workflows
- Research jobs
- Write-back

Long-running work runs outside the org.

### 3. Research

- Firecrawl web research
- Google Drive mandates
- Language models

Evidence gathered, then scored and explained.

### 4. Platform

- PostgreSQL
- Coolify
- Self-hosted server

Owned infrastructure with predictable cost.

## 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

| Area | Before | After |
| --- | --- | --- |
| Research workload | Constrained by where it ran | Orchestrated on dedicated n8n infrastructure |
| Job tracking | Not observable | Job state tracked in PostgreSQL |
| Company research | Manual reading | Firecrawl web research grounding each score |
| Mandate criteria | Separate from the CRM | Drive documents connected to investors in Salesforce |
| Results | At risk of living in side tools | Written back to Salesforce match records |
| Running cost | Tied to per-transaction pricing | Self-hosted with predictable cost |

## 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.

## Questions

### Why not run the AI research inside Salesforce?

Screening many companies against many mandates involves long-running web research and repeated model calls. Those jobs are better handled by infrastructure designed for them, with its own workflows and storage, while Salesforce keeps the investor data, the approvals and the deals. The two are connected so every result returns to the CRM.

### Where do mandate documents come from?

The firm keeps investor mandate documents in Google Drive. The infrastructure reads them from there and connects them to the investor in Salesforce, so the criteria the AI uses can be checked against the documents the investor provided.

### How fast can it screen large batches?

Large-batch screening and performance testing are part of ongoing work, alongside experiments with alternative ranking approaches and AI idea generation. Throughput targets are being measured rather than assumed, and we do not report them as achieved until they are.

---

SynconAI. https://synconai.com/case-studies/self-hosted-ai-research-infrastructure