How do you use Palantir Ontology to alert on forecast sandbagging on consumption deals in Salesforce during BDR-to-AE split when SDRs on Outreach?

Two ways to build this: rules in the CRM or a scored model in the Ontology

There are really only two credible architectures for catching forecast sandbagging on consumption deals, and choosing between them determines everything downstream — cost, staffing, how quickly you see value, and how much political capital you burn.

Option A: keep the logic inside Salesforce. You build the detection as native CRM machinery — a set of custom fields on Opportunity that hold forecasted consumption units, a nightly integration that lands actual usage from your product telemetry or billing system into those same records, a formula field that computes the variance, and a Flow that posts to a Chatter feed or Slack channel when the variance crosses a threshold. Outreach activity comes in through the standard Outreach-to-Salesforce sync, which writes task and email-engagement records against the contact and opportunity. Everything lives in one system. Everything is inspectable by any admin with the right profile.

Option B: build the detection in the Palantir Ontology. Here Salesforce becomes one input among several. You register Opportunity, Account, Contact, and OpportunityHistory as ontology object types. You register Outreach sequences, mailings, calls, and prospect records as their own object types. You register the consumption stream — API call counts, seats activated, storage consumed, compute-hours, whatever your meter is — as a time-series-backed object linked to Account. Then you write the sandbagging logic as ontology functions and materialize the score as a derived property, surfaced in a Workshop application where a deal desk works the queue.

The genuine difference is not "one is better." It's that Option A detects a *field* problem and Option B detects a *behavioral* problem. Salesforce sees the number the AE typed. It has no memory of what the number was three weeks ago unless you're tracking OpportunityHistory carefully, no access to what the product is actually doing unless you build that pipe, and no native way to join Outreach touch cadence against usage inflection. You can approximate all of it with enough custom objects and enough nightly jobs, and plenty of RevOps teams have. But you're rebuilding a data platform inside a CRM, and you'll feel it the first time someone asks "show me every deal where consumption grew more than 20% in the fourteen days *before* the AE pushed the close date."

Option B answers that question natively because the Ontology is a semantic layer over versioned data, not a row store optimized for record editing. The cost is real: you need someone who knows Foundry pipelines, you need the consumption data landed and modeled, and you need to accept that your alert now depends on a system your Salesforce admin can't debug alone.

There's a third posture worth naming because a lot of teams end up here by accident: Option C, the warehouse-middle pattern. Salesforce and Outreach both land in Snowflake or BigQuery via Fivetran or a native connector, dbt models compute the variance, and a reverse-ETL tool writes a Sandbagging_Flag__c and score back onto the Opportunity. This is cheaper than Palantir and more capable than pure Salesforce Flow. It loses the Ontology's write-back and action framework — the ability for a manager to click a button in the same interface that surfaced the alert and have it mutate the source system with lineage intact. For many mid-market teams that trade is fine. Be honest about whether you're choosing Palantir because you need the action layer or because it's already on the enterprise agreement.

Deciding which architecture fits your situation

The decision hinges on four questions, and I'd answer them in this order.

Do you already have consumption telemetry landed somewhere queryable? If usage data lives only in production application logs and no one has ever pulled it into an analytics environment, that pipeline is your project — not the alerting. Budget four to eight weeks for it regardless of which detection architecture you pick. If it's already in a warehouse with a daily or hourly refresh, you can build meaningful detection in two to three weeks either way.

How many opportunities are you actually inspecting? Under roughly 200 open consumption deals per quarter, a human reading a well-built Salesforce report on Monday mornings will outperform any scoring model, because the manager knows the deals. The scoring model earns its keep somewhere north of 500 open deals, where nobody can hold the portfolio in their head and patterns hide in the middle of the distribution.

Is Palantir already deployed with the relevant data in it? If Foundry is live and your billing or product data already flows through it for finance reporting, the marginal cost of adding a SandbaggingSignal derived property is small — days, not months. If this would be the first Foundry use case, you are buying a platform to solve an alerting problem, and that's a bad trade almost every time.

Who acts on the alert? This is the question people skip. An alert with no owner is a dashboard. If the answer is "the BDR manager and the deal desk review flagged deals in the Thursday pipeline meeting," you have a workflow. If the answer is "we'll put it on a dashboard and see," build the cheap version.

One more filter that matters more than any of the above: is the sandbagging real, or is it a comp-plan artifact? If your quota credit for consumption deals is booked on committed minimums but paid on realized usage, reps have a mechanical incentive to forecast conservatively — they're not hiding anything, they're responding to the plan you wrote. No ontology fixes that. Read the comp plan before you build the detector, because the fastest fix for sandbagging is often a change to how consumption overage is credited, not a new alert.

The numbers behind each path

Concrete figures, with the caveat that these are planning ranges from typical enterprise deployments rather than a published benchmark — verify against your own environment before you put them in a business case.

Salesforce-native build. Roughly 40–80 hours of admin and developer time: five to eight custom fields on Opportunity, a scheduled Apex or integration job to land usage figures, a formula or rollup for variance, a Flow for notification, and one saved report. Ongoing maintenance is a few hours a month. The failure mode is data freshness — if usage lands nightly and your forecast lock is Friday at noon, you're always inspecting stale variance. Also watch Salesforce governor limits if you're pushing usage rows per account per day; at 5,000 accounts with daily granularity that's 1.8 million rows a year, which belongs in a custom object with a retention policy, not on the Opportunity.

Warehouse plus reverse ETL. Fivetran-style ingestion for Salesforce and Outreach, a handful of dbt models, and a sync tool writing back. Typical build is three to six weeks of analytics-engineering time. Recurring cost is the connector and sync licenses — meaningful at scale because most of these price on monthly active rows or record syncs, so a high-volume Outreach activity table can be the single most expensive object in your pipeline. Trim what you sync: you need engagement events and sequence membership, not every email body.

Palantir Ontology. If Foundry is live: two to four weeks to model the objects and land consumption data, another one to two weeks for the Workshop application and the action definitions. If Foundry is not live, you're looking at a platform engagement measured in quarters and a licensing conversation that has nothing to do with this use case. The honest number for a greenfield Palantir deployment is not something I can quote responsibly — it varies enormously by scope and negotiation, and anyone quoting you a figure from a blog post is guessing.

The score itself. Weight three inputs and normalize each to 0–100 before weighting:

• *Consumption-to-forecast ratio* over a trailing 30 days, weight ~0.45. This is the core signal. A deal where realized usage is running at 130% of the forecasted consumption rate while the AE hasn't touched the forecast is the classic pattern.
• *Forecast revision direction and frequency*, weight ~0.30. Count downward revisions to expected consumption or outward pushes of the ramp date over the trailing quarter, from OpportunityHistory. Two or more downward revisions on a deal with flat-or-growing usage is a strong flag.
• *Engagement-to-forecast divergence*, weight ~0.25. Pull Outreach sequence activity and meeting counts. High recent engagement plus a stagnant or reduced forecast is suspicious; low engagement plus a stagnant forecast is just a stalled deal, which is a different problem needing a different play.

Set the alert threshold at composite 70 for immediate routing and 50–69 for a weekly digest. Scale the threshold by deal size — a small deal at 60 isn't worth a manager's Thursday, a seven-figure deal at 55 is. Expect your first threshold to be wrong; plan to tune it after two full forecast cycles against a labeled set of deals your VP already knows were sandbagged.

Alert volume is the metric that kills these projects. If more than about 8–10% of open deals flag in a given week, the queue gets ignored within a month. Tune down until the flagged set is small enough that a human genuinely reviews each one, then loosen slowly.

Building it: sequencing, the BDR-to-AE seam, and what breaks

Sequence matters more than architecture, because most of these projects fail in the data-modeling phase and never reach the interesting part.

Land and model the consumption stream first. Before any Salesforce work, get usage into your platform at account grain with a daily partition and at least twelve months of history. You need history to compute a trend, and you need the trend to distinguish a genuinely conservative forecast from a sandbagged one. Model it as an ontology object linked to Account by a stable external ID — not by name, which will bite you the first time an account is renamed after an acquisition.

Then model the Salesforce side, including history. Register Opportunity, Account, and critically OpportunityHistory or your field-history tracking. The detection depends on knowing what the forecast *was*, not just what it is. If field history tracking isn't enabled on your consumption-forecast fields today, turn it on and wait — you cannot backfill it. This alone is a reason to start the project earlier than you think you need to.

Then the Outreach layer, and be precise about the handoff. During a BDR-to-AE split the ownership record changes but activity doesn't cleanly partition. SDRs on Outreach keep running nurture sequences against contacts on accounts the AE now owns; the AE's own outbound may or may not flow through Outreach depending on how your team works. Build an explicit Handoff object with the timestamp of the ownership change, the outgoing BDR, the incoming AE, and the opportunity. Every activity then resolves to pre-handoff or post-handoff, and your engagement signal stops being noise. Without this object, high SDR touch volume on a post-handoff account reads as AE engagement and your score inverts.

Then define actions, not just alerts. This is the actual reason to use the Ontology over a dashboard. Define three ontology actions on a flagged opportunity: request a re-forecast (creates a task with a 48-hour due date and notifies the AE and their manager), escalate to deal desk (moves the opportunity into a review queue and stamps a reason code), and dismiss with reason (records why the manager thinks the forecast is right, which becomes your training label set). That third action is the most valuable one and the one everybody forgets to build. Dismissals are how you learn your thresholds are wrong.

Then pilot narrow. One segment, one pod, ten business days, alerts going to a private channel that only the RevOps owner and one sales manager can see. Compare flagged deals against what actually closed. You are looking for two numbers: what fraction of flags a manager agreed with, and whether any deal that genuinely sandbagged went unflagged. If agreement is under about half, do not expand — retune.

What breaks, in rough order of likelihood. Account-to-customer mapping in the consumption system doesn't match Salesforce account IDs — plan a reconciliation exercise, it is always worse than expected. Outreach sync is configured to log activity against the contact but not the opportunity, so your engagement signal has no deal-level grain. Consumption forecast lives in a free-text notes field or a spreadsheet, not a structured field, so there's nothing to compare against; fixing this means a field-definition project and a quarter of adoption before detection is possible. And the political one: the first genuinely correct flag lands on a top rep, the manager overrides it, and the queue quietly dies. Decide in advance, in writing, who arbitrates a disputed flag.

Adjacent patterns the same model unlocks

Once the objects are modeled, sandbagging detection is one query among several — and the neighboring use cases often justify the build better than the original one did.

Stage inflation, the mirror image. Same joins, inverted logic: deals sitting in Commit with no post-handoff engagement, no economic-buyer contact role, and no consumption pilot activity. Sandbagging hides upside; inflation manufactures it. Most forecast pain is inflation, and it's usually the easier sell internally because finance already feels it.

Ramp-quota fairness after a BDR-to-AE split. The Handoff object you built for activity attribution is exactly what you need to compute how much pipeline a new AE inherited versus sourced, which is the perennial argument in any team running a split model. Give a ramping AE credit against inherited pipeline and the sandbagging incentive itself weakens.

Consumption-ramp risk on closed deals. The same telemetry that catches an under-forecast pre-close catches a customer who signed a minimum commit and isn't consuming against it. That's a churn signal six months before renewal, and it's usually worth more money than the forecasting fix. Route it to CS, not to the deal desk.

Cross-system hygiene. Duplicate accounts created during an acquisition, contacts sequenced by two SDRs simultaneously, opportunities with mismatched currency or ramp schedules — all of it falls out of the same object graph. A RevOps team that models the graph once tends to find that the alerting backlog it had been carrying for a year mostly evaporates.

The general lesson: the expensive part is never the alert. It's the join. Build the join for a reason you can defend, then harvest the adjacent questions it answers, and be disciplined about which alerts actually get a human owner — everything else is a report someone will open twice.

Related questions

Should the alert automatically change the forecast?

No. Auto-adjusting a rep's number destroys trust in the system and hides the disagreement you actually want surfaced. Route the flag to a human queue with a review SLA and let the manager and rep resolve it on the record.

What if consumption data only refreshes weekly?

Weekly is workable for detection but shifts your cadence — compute the trend over a trailing eight weeks rather than 30 days, and run the review meeting a day after the refresh lands. Don't lock forecasts before the data arrives.

How do you separate sandbagging from a genuinely conservative rep?

Look at the pattern across a full year, not one deal. A rep who is consistently 15% under on every deal is calibrated conservatively and you can adjust their number systematically. Sandbagging shows up as selective conservatism near quota lines.

Does this work if SDRs use something other than Outreach?

Yes. Salesloft, Apollo, HubSpot Sequences, or native Salesforce tasks all supply the same primitive — timestamped engagement tied to a contact and ideally an opportunity. Map them to the same ontology object type and the score logic is unchanged.

Where should the handoff timestamp come from?

Prefer Opportunity owner-change history over a manually stamped date field, since the manual field is skipped under quarter pressure. If your process assigns AEs before ownership transfers, capture both and use the earlier one.

FAQ

Do I need Palantir Ontology specifically, or will a warehouse and dbt do?

For pure detection, a warehouse and dbt will do, and for most mid-market teams it's the better economic choice. The Ontology earns its place when you need the action layer — a manager clicking "request re-forecast" in the same interface that surfaced the flag, with the write-back to Salesforce governed and traceable. If your workflow ends at "someone looks at a dashboard," you don't need Palantir for this.

How long before the alert is trustworthy enough to run a pipeline meeting off?

Two full forecast cycles, minimum. The first cycle produces flags nobody trusts, the second lets you compare flags against actual outcomes and retune the weights and threshold. Teams that put an untuned score in front of a VP in week two generally lose the project, because one bad flag on a good rep is enough to end the conversation.

What's the minimum consumption-data granularity that works?

Daily usage at account grain with twelve months of history is comfortable. Weekly works with a longer trailing window. Monthly is too coarse for consumption deals — by the time a monthly aggregate reveals the divergence, the quarter is closed and the sandbagging already paid off for the rep.

How do you handle deals with no consumption history at all — new logos?

Score them differently or exclude them. A brand-new account has no usage trend to diverge from, so the consumption component is meaningless. For new logos, lean on the engagement and forecast-revision components with reweighted inputs, or accept that this detector is a expansion-and-renewal tool and use a different play for new business.

Does field-history tracking in Salesforce need to be on before I start?

Yes, and this is the most common avoidable delay. Field history cannot be backfilled — if tracking isn't enabled on your consumption-forecast and close-date fields today, you have no revision signal until you turn it on and accumulate a quarter of data. Enable it in week one even if the rest of the project is months out.

Won't reps just game the score once they know it exists?

Some will, and you should tell them it exists anyway. A hidden score is a trust problem waiting to detonate. Published thresholds change behavior in the direction you want — reps update forecasts when usage moves — and the gaming that remains (forecasting slightly high to stay under the variance band) is a far less damaging failure mode than silent sandbagging.

Sources

• https://palantir.com/docs/foundry/ontology/overview/ — Palantir Foundry Ontology concepts, object types, and links
• https://palantir.com/docs/foundry/action-types/overview/ — Ontology action types and write-back workflows
• https://help.salesforce.com/s/articleView?id=sf.forecasts3_overview.htm — Salesforce Collaborative Forecasts overview
• https://help.salesforce.com/s/articleView?id=sf.tracking_field_history.htm — Salesforce field history tracking setup and limits
• https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_opportunityhistory.htm — OpportunityHistory object reference
• https://support.outreach.io/ — Outreach support center, sequences and Salesforce sync configuration
• https://www.gartner.com/en/sales/topics/sales-forecasting — Gartner resources on sales forecasting practice
• https://hbr.org/2017/07/how-to-set-sales-targets-that-actually-work — Harvard Business Review on target setting and rep behavior
• https://docs.getdbt.com/docs/build/models — dbt model documentation for the warehouse-based alternative
• https://www.snowflake.com/en/data-cloud/workloads/data-engineering/ — Snowflake data engineering workload documentation

Related on PULSE

• [How do you use Palantir Signals for GTM alerts to measure forecast sandbagging on consumption deals in Salesforce during multi-product bundles when SDRs on Outreach?](/knowledge/q10679)
• [How do you use Palantir pipeline digital twins to alert on stage inflation without buyer evidence in Dynamics 365 during consumption ramp deals when founder still owns largest accounts?](/knowledge/q10725)
• [How do you design a RevOps control tower in Palantir Ontology that catches duplicate contacts after acquisition before weekly commit calls for consumption ramp deals with procurement portal mandates?](/knowledge/q10722)
• [How do you use Palantir Ontology to automate ramp quotas on new hires in Dynamics 365 during usage-based pricing when consumption pricing with minimum commits?](/knowledge/q10671)
• [How do you use Palantir-driven forecast simulations to dedupe ramp quotas on new hires in Dynamics 365 during BDR-to-AE split when consumption pricing with minimum commits?](/knowledge/q10737)
• [How do you use Palantir Foundry to measure forecast sandbagging on consumption deals in Salesforce during PLG-to-sales handoff when no dedicated RevOps hire yet?](/knowledge/q10702)