A manager’s due diligence questionnaire (DDQ) is one of the richest sources of information an allocator collects, yet at most firms the answers live in PDFs that no system can query. Using Claude Code alongside JotForm, FinServ brought every DDQ answer for a multi-manager fund client into Salesforce, linked to the right manager and due diligence record, giving the fund data it can finally compare and analyze, while cutting the time to deliver a user’s request from days to minutes or hours.

The cost of leaving that data in documents is easy to underestimate. A DDQ captures a manager’s ownership, staffing, service providers, trading locations, risk controls, and compliance practices in detail. When those answers sit in a PDF, the only way to use them is to open the file and read it, one manager at a time.

That makes two of the most valuable questions an allocator can ask very hard to answer. How does this manager compare with the others we allocate to? And does what the manager told us in the DDQ match the results we are actually seeing? Without structured data, both questions depend on someone’s memory of documents they read months or years ago.

Recently, FinServ worked with a multi-manager fund that was in exactly that position. Its DDQ responses had never made their way into Salesforce. A development team had built automation that filed DDQ documents into SharePoint, but only for prospective managers, and the filed documents were never linked to the corresponding Salesforce records. The annual review DDQ for active managers was not covered at all.

Working inside the client’s own Salesforce org and its own Claude environment, our consultant directed Claude Code to build the integration that brings every DDQ answer into Salesforce, for both the initial and the annual questionnaire, with each completed document filed and linked to the manager’s record. The sections below cover why DDQ data usually stays locked in documents, what we built and how quickly, and what structured DDQ data makes possible.

Why DDQ Data Stays Locked in Documents

Form tools such as JotForm make it easy to collect a DDQ online, and most can produce a tidy PDF of each submission. Turning those answers into structured Salesforce records is a different problem. A DDQ is full of tables, rosters, repeating answers, and references to people and firms who may already exist in your CRM, and none of that maps cleanly field to field.

For example, an ownership table needs to become one record per owner with the right percentage attached, a key personnel roster needs to link to existing contacts rather than create duplicates, and a list of service providers needs to point to the firms already in your master list. Each of those steps requires custom Apex code.

Historically, that code was expensive and slow to build, so most firms settled for storing the PDF and moving on. The questionnaire was collected, filed, and rarely looked at again until the next review cycle.

Bringing Every DDQ Answer Into Salesforce in Five Days

Claude Code changed that equation. Working with a consultant who understood the fund’s due diligence process, it wrote the Apex that takes each JotForm submission and turns it into structured Salesforce data. The core integration went from first session to production in five days, and the deployment ran more than a thousand automated tests with no failures before it went live.

The integration parses tables and rosters into individual records, matches every named contact against people already in Salesforce, and ties each submission to the correct manager and due diligence record. Answers that were once paragraphs inside a PDF are now fields your team can filter, report on, and compare.

Small details came along with it. For instance, international managers could not enter their phone numbers at all because the form used US-style input masks. The integration added a country selector and stores every number in a standard international format, so a manager in London or Singapore completes the form as easily as one in New York.

Seeing Service Provider Exposure Across Every Manager

Every DDQ asks managers to name their key service providers: fund administrator, auditor, prime brokers, legal counsel, compliance consultant, and more. Captured properly, those answers tell an allocator something no single DDQ can: which providers its whole portfolio depends on. Captured as free text, they are useless for that purpose, because one administrator can appear under several spellings and nothing links the answer to the firm itself.

So we reversed the usual direction of the integration. A nightly job built with Claude Code pushes the fund’s approved providers from Salesforce into the DDQ’s dropdown lists, organized so each question shows only providers of the relevant type. Each answer links the manager directly to the provider’s record in Salesforce. If a manager’s provider is missing, an “Other” option creates the firm marked as unapproved for the due diligence team to review.

The result is visible on every service provider’s page in Salesforce, which now lists all the managers that provider supports and in what role. For example, if a fund administrator suffers an operational failure or a cybersecurity incident, the fund can open that administrator’s record and see every affected manager immediately, rather than searching through dozens of PDFs. The same view shows where exposure is concentrated, such as several managers relying on one prime broker, before it becomes a problem.

Turning User Requests Around in Minutes Instead of Days

The change the fund’s users noticed most was how quickly their requests came back. Before Claude Code, even a small change meant scoping, a development estimate, and a scheduled release, so a request typically took days to reach production. Now the consultant describes the requirement, Claude Code writes the change and its tests, the change is proven in the sandbox, and it is promoted to production, often within the hour.

For example, when managers answering “No” to a question about additional offices were still generating empty office records, the fix was in production about 40 minutes after it was reported. When managers listing several offices produced a single combined answer, the parser that splits it into one record per office went from report to production in about an hour.

Larger requests moved almost as fast. The fund’s due diligence lead asked for a report of outstanding questionnaires one evening, and by midday the next day stage tracking and an outstanding-DDQ report, split by questionnaire type with days outstanding, were in production. When an onboarding executive needed a new form to collect key contacts from managers, Claude Code created the form through JotForm’s API and built its Salesforce parser, live in production the same day.

Speed also changed who could contribute. We gave a FinServ analyst access to the client’s Claude environment so smaller requests could be handled as quick wins in parallel with the larger builds, rather than waiting in line behind them.

Linking Every DDQ Document to the Manager’s Record

The existing SharePoint automation filed DDQ documents for prospective managers only, and nothing connected those files to the manager’s Salesforce record. We built a new automation with Claude Code that saves each completed DDQ to the manager’s due diligence folder in SharePoint Online and logs every upload against the record in Salesforce, so the structured answers and the signed document sit side by side.

It was built without modifying the development team’s existing package. The automation was working end to end in the sandbox about 35 minutes after we started, deployed to production that afternoon, and activated the same day.

The practical effect is that a due diligence analyst reviewing a manager in Salesforce sees the answers, the history of submissions, and a confirmed link to the source document in one place, rather than searching SharePoint for a file that may or may not have been saved.

Extending to the Annual Review DDQ

The annual review for active managers is where structured data pays off most, because it allows the fund to see what changed from one year to the next. Claude Code pulled the fund’s annual and initial forms through JotForm’s API and produced a question-by-question comparison of nearly three hundred questions in about 40 minutes, identifying where the two forms overlapped and where they differed.

That comparison surfaced a sanctions-screening question the new form lacked, which was added to production the same day. The following day, Claude Code made several dozen question additions and removals to the annual form through the API in a matter of minutes, and the annual DDQ went live in production with a successful end-to-end test submission, loading into the same Salesforce structure as the initial DDQ.

An automated reminder and escalation cycle for the annual questionnaire is built and deployed as well, and is held for the fund’s compliance review before it is switched on. Once active, it will chase managers whose questionnaires are outstanding and escalate those that remain overdue, so the annual cycle runs without manual follow-up.

Keeping Speed From Becoming Risk

Faster development is only valuable if the results are reliable. Every change is built in a sandbox, proven with real test submissions, and promoted to production only after the full test suite passes; production deployments on this engagement routinely run more than a thousand tests.

The consultant stays firmly in control. Claude Code writes code quickly, but its first diagnosis is not always right, and the consultant regularly redirected it, for instance when it proposed a JotForm-side fix for a problem the form’s existing settings had already ruled out. All JotForm integration mappings, form conditions, and browser test submissions are done by the consultant, and data corrections are previewed and approved before they are applied.

The work also stays inside the client’s environment. Code is written in the fund’s Salesforce org using the fund’s own Claude environment, so sensitive due diligence data remains within its existing security controls, and every class stays in the client’s org, documented and maintainable long after the engagement.

What Structured DDQ Data Makes Possible

With DDQ answers in Salesforce, the questions that once depended on memory become queries. You can compare managers on team size relative to assets, number of trading locations, or the presence of specific risk controls, assess your portfolio’s exposure to any single service provider, and see where a manager sits relative to its peers rather than in isolation.

You can also start testing the DDQ against reality. For example, if a manager reported in its annual DDQ that a senior portfolio manager left during the year, the fund can line that answer up against the manager’s performance over the same period. If a manager describes tight position limits, the fund can check whether its results look like the product of those limits. Patterns that were invisible across a stack of PDFs become visible across a dataset.

It also prepares the fund for AI-driven analysis. Tools that compare managers or flag inconsistencies are only as good as the data they can reach, and structured, linked DDQ data in Salesforce is exactly what those tools need to produce answers a due diligence team can trust.

Applying the Same Approach to Any System With an API

Nothing in this approach is specific to Salesforce or JotForm. Claude connects to outside systems through the Model Context Protocol, an open standard whose servers typically wrap an application’s existing API. Where a vendor already offers an MCP server, Claude can use it directly. Where one does not exist, a server can be built on top of the API, or Claude Code can call the API itself, as it did with JotForm on this engagement.

In practice, that means any system with a documented API can be brought into the same workflow, and that covers much of the technology alternative asset managers already run. For example:

• Deal and relationship management: DealCloud offers a documented REST API, so deal, company, and contact data can be read and updated the same way the fund’s manager data is managed in Salesforce.
• Portfolio and fund accounting: Allvue describes its platform as API-first, which allows portfolio, fund, and investor data to feed the same kind of analysis.
• Market and peer data: Preqin delivers its fund, manager, performance, and service provider datasets through APIs, so your own manager data can be benchmarked against the wider market.
• Documents and collaboration: SharePoint Online and the rest of Microsoft 365 are reachable through Microsoft’s Graph API, the same interface our DDQ filing automation uses.
• Project and workflow management: Asana’s API lets operational tasks and deadlines be created and tracked from the data in your other systems.

The constraints are practical rather than technical. API access is sometimes gated behind an administrator or a higher subscription tier, coverage varies from vendor to vendor, and some older on-premises systems offer no API at all. Assessing those constraints system by system is where we start, before any code is written.

The Bottom Line

For most allocators, the DDQ is collected, filed, and rarely analyzed, because turning its answers into structured data has always required custom code that was slow and expensive to build. Claude Code removed that barrier. For our multi-manager fund client, that meant every DDQ answer in Salesforce within days, comparable across managers, linked to the source document, extended to the annual review, and connected to the service providers the portfolio depends on, with user requests that once took days now delivered in minutes or hours.

The speed matters, but the real value is what the data now allows. The fund can compare managers against each other and test what managers report against the results they deliver, and every annual cycle adds another layer of history to that analysis. With sandbox-first discipline and an experienced consultant, AI-assisted development becomes a dependable way to get there. Because Claude reaches other systems through their APIs, the same approach extends well beyond Salesforce to the deal, portfolio, market data, and document platforms your firm already relies on.

Making the Move with Confidence

Bringing DDQ data into Salesforce with Claude Code, supported by sandbox-first discipline and a clear understanding of your due diligence process, is more than a technical upgrade; it changes what your team can learn about the managers you allocate to. Done right, it turns static questionnaires into comparable, analyzable data your team can trust. Done poorly, it fills your CRM with inconsistent records that make comparison harder rather than easier.

FinServ Consulting helps Private Equity and hedge funds get it right. We are currently working with clients who are actively using Claude Code to build and maintain their Salesforce automation, combining deep knowledge of the alternatives industry with hands-on Salesforce and Apex experience. Contact us at info@finservconsulting.com or (646) 603-3799 to learn how we can help your firm turn its due diligence questionnaires, and the other systems you rely on, into data you can analyze.