Partner Accounts
Partner Accounts are Salesforce Account records that have been flagged as partner-enabled, allowing the platform to provision external users (Contacts under the account) with Partner Community licenses for access to an Experience Cloud partner portal.
Definition
Partner Accounts are Salesforce Account records that have been flagged as partner-enabled, allowing the platform to provision external users (Contacts under the account) with Partner Community licenses for access to an Experience Cloud partner portal. The flag turns a standard Account into the central record for managing a channel relationship: deal registrations, lead distributions, shared opportunities, partner tier assignments, and any other channel-management data.
Once an Account is enabled as a Partner Account, its related Contacts can be enabled as Partner Users in two clicks. The Account becomes the sharing anchor for everything those partner users see in the portal: records owned by their company's partner users, records shared with their company via sharing rules, and records explicitly assigned to them. This Account-centric model is what makes a partner portal feel like a tenant experience for each partner company, even though all partners share the same underlying org.
How Partner Accounts power the channel program
Enablement and the partner Account flag
Enabling an Account as a Partner Account is a one-action change in Setup or on the Account record's options. The action sets a hidden flag on the Account that the platform uses to filter portal-accessible records, drive sharing rules, and surface the Account in the partner administration views. Disabling an Account un-flags it, which immediately revokes partner-user access for everyone associated with the Account. The change is reversible but disruptive: deactivated partner users lose access until re-provisioned. Most enterprises treat Partner Account enablement as a one-way commitment for a given partner relationship and use distinct lifecycle workflows for adding versus removing partners.
Partner users, roles, and the partner role hierarchy
Once an Account is a Partner Account, Contacts under it can be enabled as Partner Users. Each Partner User has a license (Partner Community or Partner Community Plus) and a role within the partner Account's mini-hierarchy: Partner User, Partner Manager, or Partner Executive. The role determines what records the user can see across their partner company: a Partner Executive sees everything the company's other partner users own, while a Partner User sees only their own records by default. This partner-role hierarchy is independent of the org's broader Role Hierarchy and gives each partner Account its own self-contained access model.
Sharing rules anchored on the partner Account
Sharing rules for partner-accessible objects typically anchor on the partner Account. A common pattern: share Leads with the partner Account when the Lead's Partner_Account__c field equals the partner Account's Id, giving every Partner User of that partner Account visibility to the Leads routed to their company. Similar patterns apply to Opportunities, Cases, and custom objects. The sharing rules use the partner-Account-centric design to scope visibility precisely without revealing other partners' data. Misconfigured sharing rules at the Account level cascade into sharing leaks or sharing gaps across dozens of related records, so the configuration deserves careful design and quarterly audit.
Deal registration, lead distribution, and shared workflows
Partner Accounts are the anchor for deal registration workflows. A Partner User submits a deal registration that includes their partner Account as the registering company. The Salesforce internal team reviews the registration, approves or rejects it, and tracks deal volume per partner Account. Lead distribution rules assign incoming Leads to the best-fit partner Account based on geography, vertical, or product line, and the assigned Leads become visible to all Partner Users of that partner Account through the sharing rule. Joint Opportunity records can be jointly owned by the customer's internal user and the partner Account, with both sides seeing the same record through their respective sharing models.
Tiering and channel program features
Most channel programs implement partner tiers (Bronze, Silver, Gold, Platinum, etc.) that determine the partner's level of access, support, and incentive eligibility. The tier is stored as a custom field on the Partner Account record and drives downstream behavior: which marketing resources the partner can download, what discount levels they qualify for, what training they have completed, and how much priority they get on deal registration approvals. Each tier upgrade or downgrade is a workflow that updates the partner Account, with audit trail. Some channel teams also store per-quarter sales targets and actuals on the Partner Account for performance reviews and incentive payouts.
Joint planning and partner engagement records
Beyond transactional records (Leads, Opportunities, Cases), Partner Accounts often anchor joint-planning artifacts. Quarterly Business Reviews, annual go-to-market plans, partner enablement progress, certification tracking, and rebate calculations all hang off the partner Account record. Each of these is typically a related custom object with a Master-Detail or Lookup to the partner Account. The partner Account becomes the customer's complete view of the relationship, with the partner-portal records being one of many related views. Mature channel programs invest in building this rich partner-Account-centered view because it powers the channel team's strategic conversations with each partner.
Sandbox testing and partner Account hygiene
Sandbox testing for partner-portal scenarios is more complex than for internal scenarios because the test data must include partner-enabled Accounts, partner-enabled Contacts, and the right sharing rules. Building a representative sandbox dataset that exercises every partner tier, every sharing rule, and every workflow takes effort. Many channel teams maintain a curated partner test data load script that runs after each sandbox refresh, reconstructing the test partner Accounts in a known state. Without this discipline, partner-portal regression tests miss real-world scenarios and bugs slip into production.
Common patterns in mature channel programs
Looking across mature partner programs, a few patterns recur and tend to predict whether the implementation will hold up over time. First, a single canonical Partner Account per partner company rather than multiple Accounts for different products or regions. Multiple Accounts for the same partner fragment the relationship view and complicate sharing rules; consolidate them under one record with related-list views for different product lines if needed. Second, structured partner tier transitions with documented criteria and approval workflows. Ad-hoc tier changes (a manager deciding to bump a partner up to Gold without a recorded reason) create downstream confusion when the channel team audits the program. Third, a clear retirement workflow for inactive partners: rather than disabling the Partner Account immediately, mark the partner as inactive with a custom status field, route any in-flight deals to a transition owner, then disable the Account after a defined grace period. None of these patterns are forced by the platform, but they distinguish well-run channel programs from those where partner data and sharing slowly drift into a mess that takes a multi-quarter cleanup to recover from.
Enable and manage Partner Accounts
Working with Partner Accounts means setting up the underlying Experience Cloud partner portal, enabling Accounts and Contacts for partner access, and configuring the sharing model and channel workflows. The walkthrough below covers the standard sequence from an unconfigured org to an active partner Account with portal access.
- Confirm Experience Cloud partner portal is provisioned
From Setup, confirm Digital Experiences is enabled and at least one Experience Cloud site exists using the Partner Central template (or a custom-built partner portal). Confirm Partner Community or Partner Community Plus licenses are loaded onto the org. Configure the partner-licensed user profile with the right object and field access. Without the portal foundation in place, enabling Partner Accounts has no effect; the partner users would have nowhere to log in.
- Enable the Account as a Partner Account
Open the Account record for the partner company. Click the Manage External Account action (or the equivalent action depending on the org's UI version) and choose Enable as Partner. Confirm the action. The Account is now a Partner Account. Verify by checking the Account's setup options and confirming the Partner flag is set. Repeat for every partner company that should have portal access. For bulk enablement of many partner Accounts at once, the Data Loader can update the Account's partner flag via API.
- Enable Contacts as Partner Users
For each Contact under the partner Account who should have portal access, open the Contact record and click Manage External User then Enable Partner User. The action launches the user-creation flow: assign a Partner Community license, set the username and email, pick the right partner user profile, assign the right partner role. Save. The new Partner User receives a welcome email with portal login instructions. Test the login by impersonating the user in a sandbox and confirming they see the expected records in the portal.
- Configure sharing rules and tier metadata
Define the sharing rules that govern what partner users see. For Leads, share with the partner Account when the Lead's Partner_Account__c field matches. For Opportunities, similar pattern. For custom objects (Deal Registration, Joint Plan, Marketing Resource Access), configure sharing rules per the program design. Populate the partner tier field on the Partner Account record. Validate the configuration by logging in as a sample Partner User and confirming the right records and sharing behavior. Iterate on edge cases (orphan records, missing sharing) before scaling to the broader partner population.
- Disabling a Partner Account immediately deactivates all its partner users. Restoring access requires re-enabling and re-provisioning. Treat the action as a significant change.
- Partner role hierarchy is scoped to the partner Account, not the org's Role Hierarchy. Misunderstanding the distinction causes visibility surprises during testing.
- Sharing rules anchored on the partner Account are the primary control for cross-partner data isolation. A misconfigured rule can leak one partner's data to another.
- Login-based licenses charge per login, not per user. Active partners on login-based licenses can run up cost quickly.
- Partner-tier metadata on the Account drives many downstream workflows. Inconsistent tier values create confusing portal experiences and reporting anomalies.
Trust & references
Straight from the source - Salesforce's reference material on Partner Accounts.
- Partner Experience OverviewSalesforce Help
- Partner User ManagementSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What are Partner Accounts?
Q2. What do partner accounts enable?
Q3. What's a critical concern?
Discussion
Loading discussion…