Zac Sheffer · September 17, 2026 · 7 min read
Salesforce owners ask this question differently than most. Not "can it be done", because in Salesforce anything can be done, but "which of the four ways should we do it, and what does each really cost in admin time?" Nobody publishes that comparison honestly, so here it is.
The frame up front: Salesforce stays your system of record in every option below. We integrate with it rather than compete with it, and nothing here requires touching your object model.
Before comparing the four paths, acknowledge what Salesforce brings to referral tracking that most tools do not.
Platform flexibility is real. Custom objects, custom fields, lookup relationships, validation rules, Flows, Apex triggers, and permission sets mean you can model almost anything. Salesforce Enterprise edition supports up to 200 custom objects, and Unlimited allows up to 2,000, so a dedicated referral object fits comfortably within the data model. A referral program is not beyond the platform's capability. The question is never whether Salesforce can do it, but what it costs to build and maintain.
Reporting is powerful. Once the data model exists, Salesforce reports and dashboards are genuinely capable. Cross-object reports, joined reports, and report subscriptions mean you can get referral-sourced revenue numbers in front of leadership without exporting to a spreadsheet.
The ecosystem is deep. If you decide to build natively, there are consultants, AppExchange packages, and community patterns for nearly everything. You are not pioneering. Someone has built a version of this before, and the documentation usually exists.
Your team already lives there. The simplest advantage is the most important one. Your sales team already works opportunities in Salesforce. A referral tracking approach that keeps them in their existing workflow, rather than asking them to log into a separate system, has a dramatically higher adoption rate.
| Path | What it is | Real cost | Where it breaks |
|---|---|---|---|
| Opportunity fields + Flows | Partner source fields, a referral record type, Flow automation | Days of admin work | Free-text decay, no partner visibility, one attribution rule |
| Campaign influence | Partners as campaigns, referred deals as campaign members | Days, plus retraining | Campaign attribution is not partner attribution (see below) |
| Custom referral object | The referral event as its own object linking partner account to opportunity | Weeks: layouts, Flows, reports, ownership | Best data model; ongoing admin tax, still no partner UX or payout math |
| Experience Cloud / PRM apps | Partner-facing portal, deal registration | Enterprise budget and setup | Overkill below a real channel program |
Each of these deserves a closer look, because the real cost is in the details.
Path 1: Opportunity fields and Flows. This is where most teams start. You add a "Partner Source" field to the opportunity, maybe a lookup to the account that referred, and build a Flow that notifies the partner manager when a referral deal is created. Setup takes a day or two. The immediate problem is that a text field decays: "Acme Consulting," "Acme," and "acme consulting" are three entries that no report will reconcile. A lookup field solves the naming problem but not the attribution problem. When two partners refer the same prospect, the lookup holds one name. The admin who enters it becomes the de facto attribution policy, and nobody asked them to be.
Path 2: Campaign influence. This path uses Salesforce's native attribution machinery: create a campaign per partner, add referred opportunities as campaign members, and use campaign influence reports to show partner impact. It sounds elegant. The trap is detailed below.
Path 3: Custom referral object. You create a custom object, say "Referral," with a lookup to the referring partner account and a lookup to the opportunity. The referral gets its own fields: introduction date, referral status, commission terms. This is the correct data model. It is the same conclusion from how to track referrals in any CRM: the referral is an event, not a field. The cost is that someone builds and maintains it: page layouts, validation rules, the Flows that create and update referral records, the reports leadership wants, and the documentation so the next admin understands why it exists. For a team with a dedicated Salesforce admin and a small referral program, this is a genuine option.
Path 4: Experience Cloud with PRM apps. Salesforce Experience Cloud can give partners a portal: deal registration, lead sharing, content access, and pipeline visibility. With an AppExchange PRM package, you get tier management, MDF, and the full channel toolkit. Salesforce's own Partner Relationship Management license is priced at $25 per member per month (or $10 per login for less frequent access), and the expanded Partner Ecosystem Management edition is $50 per member per month. On top of that, implementation for a moderate partner portal typically runs $100,000 to $250,000 in consulting and configuration, with complex deployments reaching $750,000 or more. This is the right path for companies with fifty or more active channel partners and a dedicated partner operations team. Below that scale, the licensing cost, implementation timeline, and ongoing admin burden are disproportionate to the problem being solved.
Routing referrals through campaign influence is the advice that sounds most native, because campaigns are Salesforce's attribution machinery. The trap is a category error: campaign attribution measures engagement, and a referral program pays on origination.
A campaign-influence report answers "which programs touched this deal." A referral program has to answer "who originated this deal, is their credit exclusive, and what do we owe them on collected revenue?" Those are different questions, and the second one has a payee. Bend campaigns into answering it and every commission run starts with a human re-deriving intent from engagement data. The partner who influenced three deals and sourced none will appear in the report right next to the partner who sourced all three, and the report will not know the difference.
The strongest native answer is modeling the referral as its own custom object: partner account on one side, opportunity on the other, introduction date and terms on the record itself. Partnership-tech folks have documented versions of this pattern for years, and it is the correct data model; it is essentially the same conclusion we push for any CRM: the referral is an event, not a field.
The honest cost: someone owns that object forever. Page layouts, validation rules, the Flows that populate it, the reports built on it, and the tribal knowledge of why it exists. Salesforce admins are not idle people, and a hand-built referral object competes for the same backlog as everything else.
There is a profile where building natively in Salesforce is genuinely the best move, and it is worth stating plainly.
You already have a Salesforce admin who has capacity. Your referral program is small, say fewer than fifteen referrals a month. Your commission structure is simple: a flat percentage, paid on closed-won, same rate for everyone. And your partners do not need a portal because you have few enough of them that a monthly email or a quick call covers the status update.
In that scenario, a custom referral object with a simple Flow works. The admin builds it in a week, maintains it as part of the normal Salesforce backlog, and the overhead is proportional to the program's scale. Adding an external tool would introduce sync complexity that the program does not yet justify.
The signal that this changes: your admin starts spending more time on the referral object than on any other custom object in the org, or a partner asks a question about commissions that takes more than five minutes to answer from the data. At that point the program has outgrown the build, and the admin's time is better spent on other work.
Build any of the first three and the same gaps remain, because they are not data-model gaps:
The fourth path is the exception on paper: Experience Cloud with a PRM app does offer deal registration and a partner portal. What rules it out below channel scale is the price of admission: licenses, implementation, and an admin who owns it forever, not a missing feature. Third-party AppExchange PRM suites like Impartner add further cost, ranging from $25,000 to $150,000 per year depending on the edition, on top of the Salesforce Experience Cloud licensing.
One line to carry out of this section: Salesforce supports referral tracking; it does not hand you a finished referral program.
The pattern that works keeps Salesforce exactly as it is and adds a referral layer beside it. Introzy maps referral records to opportunities without adding custom objects or fields to your org, with sync direction configurable, so you can run read-only until you trust the mapping. The introducer stays credited, commissions compute on collected revenue, and partners get their own status view instead of emailing your reps.
The equivalent walkthrough for HubSpot owners is here, and the general placement question is covered in where should partner data live. Or skip to the seam: start free and see your referral pipeline with the object model untouched.
Free up to 5 referrals a month. Every feature included. No card to start.