Every B2B sales org that sells anything more complicated than a single SKU eventually hits the same argument: who gets credit for the deal? The account executive insists they ran it. The solution engineer points out the customer only signed because of their architecture. The pre-sales person ran three POCs. The sales manager approved the discount that closed it. And when commission day comes, finance is reconciling all of this in a spreadsheet that nobody trusts.
I ran into exactly this on an enterprise telecom implementation. A single deal at a large enterprise customer bundled internet, cloud, and security, came in around five billion in local currency, and had five different people who could each make a legitimate case for being paid on it. The AE owned the relationship, a solution engineer designed the bill of materials, a pre-sales specialist ran the cloud demo and the security POC, an industry specialist brought the banking domain knowledge, and the sales manager coached the deal and signed off on the discount. The compensation plan paid each role differently. Salesforce was the system of record for the pipeline, but the credit calculation was happening in Excel, and the numbers never matched.
The fix is two distinct features that people constantly conflate: opportunity teams handle access and visibility, and opportunity splits handle credit and money. Getting the distinction right is most of the battle.
Opportunity teams are about access, not credit
The opportunity team is a junction object that links a user to an opportunity and assigns them a team role. Its job is sharing and visibility. When you add someone to the team, the sharing engine grants them read or read/write access to that one opportunity even though they don't own it, and they start showing up in team-based reports. The owner is always an implicit team member, so you never add them by hand.
You turn this on under Feature Settings, Sales, Opportunity Teams by enabling Team Selling, then you drag the Opportunity Team Members related list onto the page layout so people can actually see and manage it. The team roles themselves are just a configurable picklist. On the telecom org I defined roles for Account Executive, Solution Engineer, Pre-sales Specialist, Industry Specialist, Sales Manager, and Customer Success. None of those roles carries any inherent permission. What they buy you is the ability to filter splits, drive reports, and write validation rules later, which is why it's worth being deliberate about the list rather than letting it grow organically.
The feature I push hardest is the default team. Each user can configure a default opportunity team in their personal settings, listing the teammates they normally work with, each one's role, and the access level. When that user creates an opportunity, the whole default team attaches automatically. On the telecom deals, an AE who always worked with the same solution engineer and pre-sales specialist set them as their default team with read/write access, and stopped re-entering the same two names on every record.
There is a sharp edge here that bites every project. The default team only applies when a human creates the opportunity in the UI. If the record is born from an API call, a Flow, an import, or a lead conversion driven by integration, the default team does not attach, because the execution context isn't an interactive user session. On any org with automated opportunity creation, I build a record-triggered Flow on insert that looks up the owner's default team and inserts the members. Otherwise sales managers file a ticket every week saying "the SE can't see the deal," and they're right.
Account team versus opportunity team
These two get configured redundantly more often than almost anything else in Sales Cloud. The account team is assigned per account and gives its members access across that account and, optionally, the opportunities and cases beneath it. The opportunity team is assigned per opportunity and scopes access to that single deal.
The clean mental model I give clients: put the persistent people on the account team and the per-deal people on the opportunity team. On the telecom org, the AE and the Customer Success rep stayed constant across every deal with a given customer, so they lived on the account team. The solution engineer and pre-sales specialist changed depending on what the deal was selling, so they went on each opportunity team. A wealth-management client I worked with later used the identical pattern: the relationship manager and wealth advisor sat on the account team for every high-net-worth client, and a product specialist for bonds, equity, or insurance got added to the specific opportunity that needed them.
Be aware that account team membership does not cascade down to the opportunity team automatically. "I set the account team, why can't my SE see the opportunity?" is a guaranteed support ticket. If you want that cascade, you build it in a Flow.
Revenue splits and overlay splits do different jobs
Splits are how you divide the credit for the opportunity amount among the team, purely for commission and attribution. They never touch the real Amount on the record. There are two kinds, and the difference is the whole point.
A revenue split must total exactly 100% across all members. If the owner doesn't split, they default to 100%. This is for the people who genuinely share ownership of the number. On the telecom deal, the AE took 60%, a co-AE who helped penetrate the account took 30%, and the sales manager took a 10% override, which sums cleanly to 100%.
An overlay split carries no total constraint at all. The percentages can sum to anything. This is how you credit supporting roles without taxing the owner's number. The same deal layered overlay credit of 30% to the solution engineer, 20% to pre-sales, and 10% to the industry specialist, totaling 60% with no conflict, because overlay credit is additive rather than a zero-sum carve-up of the deal.
You enable this under Feature Settings, Sales, Opportunity Splits, which spins up default Revenue and Overlay split types. During the wizard you decide whether to back-fill existing opportunities with an owner-100% revenue split; I almost always say yes, because mixed data where old deals have no splits and new ones do makes every report lie.
Constrain split types or the numbers become fiction
The real configuration leverage is in the split type itself. Each split type has a "total must equal 100%" toggle, an amount field, and a list of roles it's splittable among. I treat those role lists as policy. On the telecom org, the Revenue split type was restricted to Account Executive, Sales Manager, and Customer Success, while Overlay was restricted to Solution Engineer, Pre-sales, and Industry Specialist. Keeping each role purely revenue or purely overlay kills an entire class of ambiguity, because Salesforce blocks anyone from adding a split for a role that the split type doesn't allow.
The amount field is more powerful than people realize. It doesn't have to be the standard Amount. The telecom client wanted Customer Success comped on monthly recurring revenue, not total contract value, so I created a custom split type pointing at a Monthly_Recurring_Revenue__c field with its own 100% rule and its own role list. That let the recurring-revenue compensation run on a completely separate basis from the headline deal credit.
Even with role constraints, splits will quietly corrupt your compensation numbers if you don't add guardrails. The ones I always build:
- A validation that overlay totals can't run wild. One sales manager added every team member at 50% overlay and produced 300% of phantom credit; a rule that blocks anything over a sane ceiling and routes it to a director for approval stops that.
- A report filter on
IsWon = TRUE. Closed-lost opportunities keep their split records, and a compensation report that forgets to exclude them pays people on deals that died. - A record-triggered check at Closed Won that the revenue splits actually sum to 100% and that large deals carry the expected manager split, so credit doesn't silently default to owner-100%.
- For big deals, an approval process that locks the splits and blocks the move to Closed Won until a director signs off, so an AE can't quietly hand favorable credit to a buddy.
Once those guardrails are in place, a "splits by user by quarter" report becomes a genuine source of truth that the compensation team can export straight to the HRIS or ERP, and the Excel reconciliation goes away. That, ultimately, is the goal of the whole exercise.
The principle to hold onto
Access and credit are two different problems, and the most common failure I see is solving one when the client needed the other. Opportunity teams make sure the right people can see and work the deal; splits make sure the right people get paid for it. Decide which problem you're actually solving before you touch a single setting, design your roles so that revenue and overlay never blur, and put the guardrails in before the first commission run rather than after the first dispute. Do that and the deal-credit argument stops being an argument.
Implementing or optimizing Sales Cloud? Our Salesforce team runs discovery, designs the sales process, and configures Sales Cloud on production engagements. Get in touch ->
See our full platform services for the stack we cover.
