How do you log deal intelligence in Salesforce when Palantir Foundry is the buyer mandated analytics layer?

What it is and why it matters

When a buyer mandates Palantir Foundry as the analytics layer, your deal stops being a normal software sale and becomes a delivery-shaped sale that happens to have a contract attached. The commercial motion still lives in Salesforce — stage, amount, close date, forecast category, quota credit — but the signals that actually predict whether the deal closes now live in the buyer's Foundry environment: whether a sandbox exists, whether their data has been mapped into an ontology, whether a pipeline runs on live data or on a static CSV somebody uploaded in week two. If your CRM only records "met with the data team," you have a forecast built on vapor.

The gap is structural, not behavioral. Standard Salesforce opportunity fields were designed for a world where the proof of value is a demo and a reference call. In a Foundry-mandated deal, proof of value is a working pipeline inside the buyer's own tenant, and getting there requires the buyer's security team, their data engineering team, and often a Palantir-side deployment strategist who does not report to anyone on your side of the table. Every one of those dependencies is a place the deal stalls silently. Reps log activity because activity is what the field expects; they do not log "the S3 bucket credentials have been pending IT approval for nineteen days," because there is nowhere to put it.

The consequence shows up two quarters later. A pipeline review looks healthy — thirty opportunities, all with recent activity, most in late stages — and then half of them slip because the technical checkpoint they were all waiting on never happened. Nobody could see it, because the intelligence lived in Slack threads, in a solutions architect's head, and in a Foundry workspace nobody on the revenue side had access to. The fix is to make Salesforce record the *state of the technical relationship*, not just the state of the conversation.

There is a second reason this matters beyond forecasting accuracy: the same data becomes your product feedback loop. If you can query "which objection appeared at which stage across all Foundry-mandated deals in the last four quarters," you learn whether your problem is ontology design, migration tooling, or pricing. Without structured capture, that question is unanswerable and every quarterly business review devolves into anecdote. This is the core RevOps job in a mandated-platform world — turn a delivery reality into fields a manager can inspect and a leader can trust.

It is also worth being honest about the political shape. When the buyer mandates a platform, they have already spent money and reputation on that decision. Your deal is downstream of a commitment that predates you, which means the buyer's internal champion is often defending the platform choice as much as they are evaluating you. Deal intelligence that captures who made the mandate, when, and under what business case is more predictive than any BANT field, because it tells you whether the sponsor's job depends on this working.

The step-by-step process

Start by drawing the line between the two systems before you build anything. Salesforce owns commercial truth: account, opportunity, amount, stage, forecast, contacts, contracts. Foundry owns analytical truth: data, models, pipeline lineage, whatever the buyer is doing with it. Deal intelligence — the structured record of technical progress — is created in Salesforce and *flows to* Foundry, never the reverse. Getting this direction wrong is the single most common architectural mistake, because it makes your CRM downstream of a system your reps cannot write to and your admin cannot control.

Then build the schema. On the Opportunity, add a small set of required-at-stage fields rather than a sprawl of optional ones. A workable starting set: Foundry_Sandbox_Provisioned_Date__c, Ontology_Mapping_Status__c (picklist: Not Started / In Design / Mapped / Validated), Pipeline_Environment__c (Dev / Staging / Live), Data_Sources_Connected__c (number), and Platform_Mandate_Sponsor__c (lookup to Contact — the person who owns the Foundry decision internally). Five fields. Resist the urge to ship twenty; fill rate collapses past about six required fields per stage, and a field nobody fills is worse than no field because it creates false confidence in reports.

Next, add a child object for events. Call it Foundry Activity or Technical Milestone — the name matters less than the fact that it is a related list on the Opportunity with a record type per event class: integration attempt, workshop, security review, objection raised. Each record carries a date, an owner, an outcome picklist, and a free-text note. This is where the granular intelligence lives. The parent Opportunity fields are the roll-up that managers inspect; the child records are the evidence a solutions architect can reconstruct six months later during a renewal.

Wire the automation last and lightly. A Salesforce Flow that creates a Foundry Activity record whenever a rep logs a task with call type "technical" removes most of the manual entry burden. A second Flow that advances stage when Foundry_Sandbox_Provisioned_Date__c is populated keeps stage honest without a manager chasing it. Validation rules should block the save on the two or three fields that genuinely gate the forecast — typically ontology status before Commit — and stay out of the way otherwise.

Finally, close the loop back to Foundry. Most teams do this with a scheduled export of the Opportunity and Foundry Activity objects into whatever the buyer's ingestion path is, or into your own warehouse first if you want a staging layer you control. Do not attempt real-time bidirectional sync in the first quarter. Batch is fine. The analytics value of this data comes from trend, not latency, and every hour of engineering spent on sync reliability is an hour not spent on field discipline, which is where the actual failure mode lives.

Run this on one pod or one segment for ten business days before touching anyone else. The pilot is not a formality — it is where you discover that "ontology mapped" means three different things to three different solutions architects, and you fix the definition before that ambiguity is baked into four hundred records.

Costs, timelines, and typical ranges

The Salesforce side is cheap and fast. Five custom fields, one custom object with four record types, two Flows, and two validation rules is a few days of admin work for someone who already knows the org — call it under a week including testing in a sandbox. The expensive part is never the configuration. It is the definitional work: agreeing across sales, solutions engineering, and delivery on what each picklist value actually means, and then getting managers to inspect the resulting report every week without exception. Budget two to four weeks for a single-pod pilot, and expect the definition of "ontology mapped" to change at least once during it.

Integration cost depends entirely on the path you choose. A scheduled CSV or bulk-API export into a warehouse you already own adds essentially no new spend — you are using capacity that exists. Middleware platforms in the iPaaS category are the common alternative, and licensing there varies widely by vendor, connector count, and volume tier; the honest answer is that you should price it against your actual record volume rather than trust any general figure, because the same platform can differ by an order of magnitude between a small connector plan and an enterprise agreement. What is consistent is that middleware trades engineering time for recurring cost, and adds a second system that can silently stop.

The timeline that actually matters is the buyer's, not yours. Foundry deployments involve the buyer's data readiness, and that is the variable nobody controls. Sandbox provisioning is usually quick once approved; the approval is the slow part, because it touches security review and often procurement. Ontology design is where deals sit longest, because it forces the buyer to make decisions about their own data model that they have deferred for years. If your Sandbox-to-Live-Pipeline metric is running long across many deals, that is not a sales execution problem — it is a signal that you are selling into organizations whose data is not ready, and the fix is qualification criteria upstream, not more follow-up.

On staffing: one RevOps owner with write access to validation rules can run the entire build, provided a sales manager enforces the weekly inspection. That second condition is the one that fails. Configuration without enforcement produces a beautifully designed schema with a thirty percent fill rate, which is worse than the Slack threads it replaced because now people believe the dashboard. When you scale past a couple of pods, you will want a dedicated admin, mostly because the child-object reporting and the export job need someone who owns them when they break.

There is a hidden cost worth naming: rep time. Every field you add is a tax on the person closing the deal. The way to keep the tax low is to make the automation carry the burden — auto-create activity records from logged calls, auto-populate dates from calendar events where you can, and require manual entry only for the handful of judgments a human must make. If reps are spending more than a couple of minutes per deal per week on this, the design is wrong and they will route around it.

Where teams get it wrong

The most common failure is treating Foundry as a competitor to your CRM and building a sync that tries to make both systems hold the same truth. They do not hold the same truth. Foundry holds the buyer's operational data; Salesforce holds your commercial relationship. When teams try to mirror opportunity records into Foundry and analytical objects back into Salesforce, they get duplicate records, conflicting stage values, and a reconciliation problem that consumes an engineer indefinitely. One direction, one owner per field, one system of record per concept.

The second failure is making the new fields optional. Under quarter-end pressure, an optional field is an empty field, and a report filtered on an optional field silently excludes the deals most at risk — because the reps in trouble are the ones skipping data entry. If ontology status genuinely gates your forecast, it should block the save on Commit-stage deals. If it does not gate the forecast, it should not exist. There is no useful middle category, and the middle category is where most schemas live.

Third: company-wide rollout before the pilot proves anything. This is the classic RevOps error and it is worse here than usual, because Foundry-mandated deals often span multiple verticals with genuinely different technical shapes. What "data sources connected" means for a manufacturer with on-prem historians is not what it means for a bank with a cloud warehouse. Piloting in one segment surfaces those differences at a scale where you can adjust the picklist; rolling out globally bakes one segment's assumptions into everyone's records.

Fourth: inspection meetings that read narratives. If the weekly review is reps describing how deals are going, the fields will rot regardless of how well designed they are, because nothing depends on them. The inspection must be conducted with the saved report open, sorted by exception, record by record — name the missing field, assign an owner, set a due date before the next forecast call. Fifteen minutes, no slides. When a Commit-stage deal has an empty ontology field, it gets downgraded in that meeting, not discussed.

Fifth, and subtler: buying a point solution to paper over field discipline. There is an entire category of tools that promise to capture deal intelligence automatically from calls and emails, and some of them are genuinely useful. None of them will tell you that the buyer's sandbox has been pending security approval for three weeks, because that fact was never spoken on a recorded call — it lives in a Jira ticket in the buyer's tenant. Automated capture supplements structured fields; it does not replace the judgment calls, and teams that buy it as a replacement end up with richer transcripts and the same blind forecast.

A sixth mistake worth flagging is scope creep into delivery tracking. The temptation, once you have a Foundry Activity object, is to use it to run the implementation — tasks, assignments, burn-down. Don't. Your delivery team has a tool for that, and Salesforce will do it badly. The object exists to make deal risk visible to revenue, and the moment it becomes a project tracker, the fields that predicted risk get buried under operational noise and the sales team stops reading it.

Decision framework: when to choose what

The first branch is whether you have a Foundry environment you can see. If you are a partner with tenant access — building on the platform, delivering an application layer — you can pull genuine telemetry and the integration is worth engineering properly. If you are outside the buyer's tenant, and most vendors are, every Foundry field in Salesforce is a human assertion entered by your solutions architect. That is fine, but it changes the design: you need date-stamped, owner-attributed assertions with a confidence field, not a pretend-automated feed, because a stale human assertion presented as system truth is how forecasts break.

The second branch is volume. Below roughly a few dozen Foundry-mandated opportunities a year, do not build integration at all. Structured Salesforce fields plus a manual quarterly export into a spreadsheet will answer every question you actually have, and the engineering you skip pays for itself twice. Integration earns its keep when the number of records makes manual analysis genuinely impractical, or when someone downstream — finance, product, the buyer themselves — needs the data on a cadence a human cannot sustain.

Third: build versus buy for the pipe. Direct API work gives you control and no recurring license, but it also gives you an artifact your team must maintain through every schema change on both sides. Middleware gives you monitoring, retries, and connector maintenance somebody else owns, at recurring cost and with a ceiling on how weird your transformations can get. The rule I would apply: if the transformation is a straight field-to-field map on a schedule, use whatever you already own. If it involves conditional logic, enrichment, or multiple source systems, the middleware earns its cost in the reliability you do not have to build.

The fourth decision is which fields gate the forecast, and this one deserves more care than it usually gets. A field that blocks a save creates real friction, so spend it where it buys the most forecast accuracy. In practice that is usually two things: the identity of the platform-mandate sponsor, and whether a live pipeline exists. A deal with no named sponsor for the mandate is a deal where you cannot answer "who loses their job if this fails," and a deal with no live pipeline has not been proven in the buyer's actual environment regardless of how good the demo was. Everything else can be captured without blocking.

This framework generalizes past Foundry, which is worth noting when you are justifying the work. The same shape applies whenever a buyer mandates the platform you must integrate with — a hyperscaler marketplace requirement, a specific data warehouse, a mandated identity provider, an industry data standard. In each case the commercial system needs a small number of fields that record technical reality, a child object for events, and a manager who inspects them weekly. Building it once for Foundry gives you a pattern you reuse the next time procurement hands you someone else's architecture.

Related questions

What if the buyer will not give us any visibility into their Foundry environment?

Then every technical field is a human assertion, which is acceptable if you stamp it with a date, an owner, and a confidence level. Treat assertions older than about three weeks as expired in your reports so stale claims stop propping up the forecast.

Should the Foundry fields live on the Opportunity or the Account?

Both, at different grains. Account-level fields hold durable facts — Foundry tenant exists, ontology maturity, named platform sponsor. Opportunity-level fields hold deal-specific state like pipeline environment and sandbox date, which reset with each new deal on the same account.

Does this change how we forecast?

Yes, and that is the point. Map fields to forecast rules explicitly: no live pipeline means the deal cannot sit in Commit, no named mandate sponsor means it cannot sit in Best Case. Managers apply those downgrades in the same meeting where they inspect records.

How do we handle deals where Foundry is one of several mandated tools?

Generalize the schema rather than duplicating it. Use a Mandated_Platform__c picklist alongside the technical state fields, so the same object serves Foundry, a mandated warehouse, or anything else procurement imposes next quarter.

Who should own this schema long term?

RevOps owns the definitions and the report; solutions engineering owns the accuracy of the technical fields; the sales manager owns enforcement. Splitting definition from enforcement is what keeps the fields honest, because the people entering data do not also grade themselves.

FAQ

Why not just log everything as Salesforce tasks and notes?

Because notes are unqueryable at scale. You can read fifty of them; you cannot answer "which objection appeared most often at technical evaluation across two years of deals" from free text. Structured fields and a child object make the same intelligence reportable, and reporting is the entire reason to capture it.

How many custom fields is too many?

Fill rate is the test, not the count. In practice, required fields past about six per stage see meaningful drop-off, especially at quarter end when reps are triaging. Start with five, measure fill rate for a month, and add only when a specific report cannot be built without the new field.

What is the minimum viable version of this if I have no admin time?

Three fields on the Opportunity — pipeline environment, ontology status, mandate sponsor — and one saved report filtered to Commit-stage deals with any of them empty. No custom object, no automation, no integration. That alone recovers most of the forecast accuracy, and it is an afternoon of work.

Do we need Palantir's cooperation to build this?

No. Everything described here lives entirely in your Salesforce org and records your own team's observations about the deal. Cooperation helps if you want genuine telemetry rather than assertions, but the schema, the inspection cadence, and the forecast rules are yours to build unilaterally.

How do we stop the Foundry Activity object from becoming a project tracker?

Restrict the record types to deal-relevant event classes — integration attempt, workshop, security review, objection — and refuse to add task-management fields like percent complete or assignee status. If someone needs delivery tracking, that belongs in the delivery tool, and keeping the boundary sharp is what keeps the object readable.

What is the first metric to report once the data exists?

Time from sandbox provisioned to first live pipeline, segmented by industry. It is the single most diagnostic number in a Foundry-mandated motion, because it measures buyer data readiness rather than sales activity, and it tells you where your qualification criteria need to tighten.

Sources

• https://help.salesforce.com/s/articleView?id=sf.dev_objectcreate_task_parent.htm — Salesforce documentation on creating custom objects.
• https://help.salesforce.com/s/articleView?id=sf.fields_about_field_validation.htm — Salesforce validation rules reference.
• https://help.salesforce.com/s/articleView?id=sf.flow.htm — Salesforce Flow builder documentation.
• https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm — Salesforce Bulk API developer guide for scheduled exports.
• https://palantir.com/docs/foundry/ontology/overview/ — Palantir Foundry ontology documentation.
• https://palantir.com/docs/foundry/data-connection/overview/ — Palantir Foundry data connection documentation.
• https://trailhead.salesforce.com/content/learn/modules/data_modeling — Trailhead module on Salesforce data modeling.
• https://www.gartner.com/en/information-technology/glossary/ipaas-integration-platform-as-a-service — Gartner glossary entry on iPaaS.

Related on PULSE

• [How do you log deal intelligence in Salesforce when Foundry is the system of record for account planning?](/knowledge/q10508)
• [How do you structure prime-sub RevOps when Palantir holds the platform award and you sell the application layer?](/knowledge/q10494)
• [How do you model quota credit when Palantir delivers the platform and you sell the application layer?](/knowledge/q10488)
• [How Do I Get My Reps to Log Competitive Intel?](/knowledge/q16068)
• [How do I get reps to log accurate next steps in CRM?](/knowledge/q42)