Salesforce PRM is Sales Cloud extended to your resellers, distributors, dealers and referral partners through an Experience Cloud partner site. Partners log in with partner licenses, register deals, accept leads you pass them and see their own pipeline. Your channel team approves registrations, watches lead acceptance and reports on partner revenue in the same org your direct sellers use. That replaces the spreadsheet of partner deals and the inbox full of registration emails.
What does PRM actually mean on Salesforce?
It means three pieces working together: partner accounts in your org, partner users with external licenses, and a portal where those users work. Salesforce now markets the bundle as Partner Cloud, with Partner Relationship Management as the base edition.
The portal is usually built from the Partner Central template in Experience Cloud. Salesforce documents it as supporting channel sales, channel marketing, lead distribution, deal registration, partner onboarding and pipeline dashboards. It ships with deal registration actions and lead list views, so you start from a working layout rather than a blank site.
Salesforce's pricing page lists a higher edition, Partner Ecosystem Management. It adds market development funds, partner scorecards, incentive compensation and a channel management console. Channel Revenue Management is a separate add-on for rebates, channel inventory and price protection. Packaging changes often. Ask your Salesforce account team which edition includes each feature you plan to rely on.
Licenses matter as much as features. Partner Community is the license built for business-to-business sites that need sales data. Salesforce also sells a Channel Account license priced per partner account rather than per user. Each licensed account gets a block of partner users, which suits partners whose headcount you cannot predict.
How should partner accounts, users and sharing be set up?
Each partner company becomes an account enabled as a partner, and its people become contacts with partner users attached. Visibility then comes from partner roles, sharing rules and, where your license supports them, sharing sets.
When an account is enabled as a partner, Salesforce creates account roles beneath the internal user who owns it. You choose one to three roles per partner account, often labelled Executive, Manager and User. Pick the smallest number that works. Two roles across 400 partner accounts adds 800 roles to your hierarchy, which slows sharing recalculation.
Super user access lets a partner manager see leads, opportunities, cases and custom objects owned by people at or below their role. That is usually what a reseller principal wants. It is also where most leaks start, so test it with real partner personas before launch.
Keep external org-wide defaults separate from internal ones. Salesforce lets you set a more restrictive external default per object, so your direct sellers can still see each other's work while partners cannot. Review the owner of each partner account too. That internal user sits directly above every partner role for the account.
How do you design deal registration so partners trust it?
Deal registration works when the rules are written down, applied the same way every time and visible to partners. In Partner Central, a registration is typically a lead record type submitted through a global action and approved by a channel manager.
Salesforce's setup path is a lead record type for registrations, a page layout, an approval process and the global action partners use to submit. The hard part is the rule set behind that form. These are the rules we see programs need most often.
| Rule | Why it matters | Typical failure |
|---|---|---|
| Required fields at submission | Gives the approver enough to judge the deal is real | Partners submit a company name only, and approvers chase details by email |
| Duplicate and conflict check | Stops two partners, or a partner and a direct rep, owning one deal | Matching runs on company name, so spelling variants slip through |
| Approval deadline for the vendor | Partners keep selling while they wait, so a slow answer feels like a no | Registrations sit in a queue with no owner and no reminder |
| Protection period after approval | Tells everyone how long the partner owns the opportunity | No expiry date field, so stale registrations block new partners for good |
| Extension and renewal rules | Long sales cycles need a fair way to keep protection | Extensions granted informally, so partners see favouritism |
| Clear rejection reasons | Partners learn what a valid deal looks like | A bare rejection with no picklist value or comment |
| Conversion to opportunity | Links the registration to pipeline and revenue reporting | Approved leads never convert, so partner revenue is invisible |
Build the conflict check on more than the account name. Compare the email domain, website and any customer number from your ERP. Show the approver possible matches on the approval page instead of asking them to search.
Store the protection start and end dates as fields, and let a scheduled flow expire registrations automatically. Notify the partner before expiry so they can ask for an extension through the portal rather than by email.
How should leads be passed to partners?
Pass leads through queues and assignment rules that put them in front of the right partner, then measure whether the partner accepts and works them. A lead handed over without an acceptance step is a lead nobody is accountable for.
Partner Central includes lead list views where partner users can accept or reject leads sent to them. Add a status for acceptance, a rejection reason and a timestamp for each step. A flow can return a lead to your channel queue when the partner has not accepted it within the agreed window.
Agree that window with partners in writing before you automate it. The routing logic itself, such as round robin, matching to accounts and territory fit, follows the same principles as internal routing. Our separate guides on lead routing and territory management cover that design.
How do you track onboarding, tiers and certifications?
Treat onboarding as a checklist on the partner account and tiering as a field driven by rules you publish. Salesforce provides channel programs and program levels for grouping partners into tiers.
A typical onboarding record tracks signed agreements, finance paperwork, portal access, first training completed and first registered deal. Each step needs an owner on your side. Otherwise partners stall after signing and nobody notices.
For certifications, store the person, the certification, the date earned and the expiry date on a custom object linked to the partner contact. Roll a count up to the account so tier reviews can use it. If you require certified staff for a tier, report on certifications expiring soon and warn the partner early.
Are market development funds and incentives standard?
Partly. Salesforce documents fund objects for budgets, allocations, requests and claims with approvals. The pricing page places them above the base PRM edition.
Fund requests and claims usually fit the standard objects well. Finance will still want claims matched to proof of performance, such as invoices or event attendance, and paid through your accounting system. Plan that integration point early.
Rebates, volume incentives and partner commissions are where custom builds or an add-on come in. Channel Revenue Management covers rebates and inventory-driven programs. Simpler spiffs can live in a custom object with a calculation flow. Confirm entitlements with your account team before choosing.
How do you report partner-sourced and partner-influenced pipeline?
Decide the definitions first, then capture them as fields on the opportunity. Partner-sourced means the partner found the deal, usually through an approved registration. Partner-influenced means a partner helped close a deal your team originated.
Salesforce has a standard Partners related list on opportunities, but many teams add explicit fields: sourcing partner, influencing partner and partner role. Lock the sourcing field once the registration converts so it cannot be edited quietly later.
These definitions also settle channel conflict. When a direct rep and a partner both claim a deal, the registration record and its timestamps answer the question. Compensation rules for direct reps on partner deals should follow the same definitions, or reps will avoid registered deals.
What content and enablement belongs in the portal?
Put the material partners need to sell right now in the portal: price lists, product sheets, co-brandable campaign assets, training links and the program guide itself.
Use Salesforce CMS or Files with audience targeting so each tier sees the right material. Assign an owner to every asset and a review date. A portal full of last year's pricing teaches partners to email their channel manager instead.
How does sell-through data from distributors fit in?
Sell-through and inventory data usually comes from distributor reports or your ERP and lands in Salesforce through an integration. Treat it as a separate workstream, because file formats, customer matching and timing differ by distributor.
Agree what the channel team needs to see before choosing tools. Often that is sales by partner and end customer at a summary level, not every invoice line.
When is full PRM overkill?
When you have a handful of referral partners who send a few introductions a quarter, a portal is more than you need. A partner account type, a referral source field and a simple web form feeding a queue will cover it.
Move to a partner site when partners need their own deal status or registrations start causing disputes. Rapid partner growth that swamps your channel team's inbox is another signal. A few partners with heavy deal volume can justify a portal sooner than many quiet ones.
What belongs in phase one of a Salesforce PRM rollout?
Phase one should give a small group of partners deal registration, lead acceptance and their own pipeline view, with sharing tested end to end. Everything else can follow once that core works.
- Written program rules for registration, protection periods, conflicts and lead acceptance, agreed with the channel team.
- Partner account, role and external sharing design, tested with sample users from at least two competing partners.
- Partner Central site with registration, lead list views, a partner dashboard and the program guide.
- Opportunity fields for sourcing and influencing partner, plus channel reports for leadership.
- A pilot group of partners willing to give feedback before wider rollout.
Phase two usually adds onboarding checklists, tiers, certifications and enablement content. Funds, incentives and distributor data come after the core has run long enough to trust.
We have built this pattern before. For a payments ISO, we delivered an Experience Cloud portal used by more than 60 independent agents. They look up merchants, send in applications and follow their status there. It sat alongside Sales Cloud and residual summary objects with automated agent commission splits.
