Salesforce Partner Onboarding Testing
Salesforce partner onboarding testing validates the journey that turns a reseller or channel firm into a working partner — the account enabled as a partner, its users provisioned with the right license and partner role, and access granted to exactly the leads, opportunities and cases they should share. It proves a new partner can start selling on day one without seeing another partner's pipeline.
Experience Cloud journeys, including partner onboarding, are on the active roadmap and available for proof-of-concept engagements.
What partner onboarding involves in Salesforce
Partner onboarding sits at the boundary between an internal org and an external channel. It usually begins with an application or a channel manager's decision, continues with the Account being enabled as a partner account, and then creates one or more partner users against contacts on that account using a Partner Community or Channel Account license. Enabling the account generates partner roles beneath the channel manager who owns it — Executive, Manager and User by default, with the number set in Setup — and those roles become the anchor for sharing.
From there the partner needs a working Experience Cloud site: membership through profiles or permission sets, navigation and pages for deal registration and lead inbox, and access to shared records through sharing rules, account relationship data sharing rules, or manual and Apex sharing. Many orgs also enroll the partner in a channel program and level, assign onboarding tasks or training, and send a welcome email with login details. Each of these is configured separately, which is why the whole journey needs to be tested together.
This page focuses on setting partners up. The authenticated customer equivalent is covered by customer registration testing, and the day-to-day portal journeys by customer self-service testing.
The onboarding happy path
SyntraFlow is designed to run partner onboarding as one journey that crosses the internal org and the partner site, switching between the channel manager and the new partner user.
Partner application approved
An application record or lead is submitted and approved by the channel manager, confirming the approval routing and the creation or update of the partner Account.
Account enabled as partner
The account is enabled as a partner account. The test asserts the IsPartner flag, the generated partner roles and their position under the account owner's role.
Partner users provisioned
Contacts are enabled as external users with the intended license, profile, permission sets and partner role, and the test checks that no license or role is left at a default.
Program enrollment and tasks
Where channel programs are used, the partner is enrolled at the right level, and onboarding tasks, training assignments or welcome communications are generated.
First login to the site
The new partner user logs in, lands on the correct home page and sees the navigation, lead inbox and deal registration pages defined for partners.
Access to shared records
The partner reads a lead assigned to them and registers a deal, proving that sharing rules grant access to their own records and nothing belonging to other partners.
Why partner onboarding fails in ways customers notice
A partner that cannot log in is a visible problem. A partner that can log in and see too much is a far more serious one.
Over-shared pipeline
A broad sharing rule or a partner role placed too high in the hierarchy exposes one partner's opportunities to a competing reseller.
Wrong license or profile
A user created with a Customer Community license cannot use partner objects such as deal registration or lead distribution, and onboarding stalls.
Role count mismatch
Changing the number of partner roles affects only newly enabled accounts, so older and newer partners end up with different hierarchies and different access.
Delegated admin gaps
A partner super user or delegated external user administrator can create users but assigns permission sets the business never intended partners to hold.
Access boundaries to assert after onboarding
The outcome of onboarding is an access model. These are the boundaries a test should prove from inside the partner site, not from an administrator's view.
| Partner role | Should be able to | Should not be able to |
|---|---|---|
| Partner executive | See opportunities and leads owned by users in their partner account | See records owned by another partner account or internal-only fields |
| Partner manager | See records owned by partner users below them in the partner role hierarchy | See records of the executive or of peers outside their branch |
| Partner user | Work leads assigned to them and register new deals | Reassign leads to other partners or view other users' opportunities |
| Partner super user | View records owned by others in the same partner account | Access records of other partner accounts through the same permission |
| Delegated external admin | Create and deactivate users for their own partner account | Assign internal profiles, permission sets or roles outside the account |
| Channel manager (internal) | See and manage all records for the partner accounts they own | Lose visibility when a partner user takes ownership of a record |
Negative and exception paths
Partner onboarding carries more negative paths than most processes because every mistake is an access decision.
- Enabling a contact whose email is already in use by an active user, and confirming the duplicate username is handled rather than silently suffixed.
- Rejecting a partner application and proving no account is enabled and no user or role is created.
- Onboarding two partners in the same territory and confirming neither sees the other's leads, deals or cases.
- Deactivating a partner user and confirming record ownership, lead queues and portal access are handled as designed.
- Disabling a partner account and checking that partner roles are removed and users lose access in one step.
- Attempting deal registration for an opportunity already registered by another partner and confirming the conflict rule applies.
- Accessing an internal record URL directly from the partner site and confirming the page returns no data, a check shared with negative access testing.
Test data and role variations
Onboarding tests need seeded data that looks like a real channel: at least two partner accounts owned by different channel managers, contacts eligible for enablement with unique emails, leads and opportunities already assigned to each partner, and the sharing rules and account relationships that should connect them. Available external licenses matter too; a sandbox with too few Partner Community licenses will fail user creation for reasons unrelated to the process. Provisioning and resetting those records, including deactivating users created by a run, is part of test data management.
The journey should be executed as each role that touches it — channel manager, partner executive, partner user and delegated administrator — because access only becomes visible from the perspective of the person holding it. Running as an internal administrator proves nothing about what a partner sees. Where the site's guest and external exposure is the primary concern, Experience Cloud security testing covers that surface in more depth.
Suggested test scenarios
A starting set that balances onboarding completeness with the access checks that matter most.
| Scenario | What it proves |
|---|---|
| Approved application to first login | The whole onboarding chain completes and a partner reaches the right site pages |
| Two partners, one territory | Partner accounts are isolated from each other's pipeline |
| Three-level partner hierarchy | Executive, manager and user roles see the records the hierarchy implies |
| Delegated admin creates a user | Partner-side user creation stays inside allowed profiles and permission sets |
| Partner account disabled | Roles, users and access are removed together |
| Deal registration conflict | A second registration for the same deal is caught |
| Seasonal release rerun | Site, sharing and license behavior still hold after an Experience Cloud update |
Evidence and ongoing regression
A complete run is designed to capture the partner account and roles created, each user's license, profile and permission sets, screenshots of what the partner saw on first login, and a record-level matrix of what each partner role could and could not open. That matrix is what a channel or security owner needs to sign off a new partner program or a sharing change.
Partner access is sensitive to change far from the onboarding flow itself — a new sharing rule on Opportunity, a site page added by marketing, or a permission set updated for internal users. Automating onboarding through Salesforce test automation and rerunning it after each release and deployment keeps partner isolation proven rather than assumed.
Related pages
Business Processes
The full library of Salesforce business process tests partner onboarding belongs to.
Customer Registration Testing
The self-registration journey for customers rather than channel partners.
Experience Cloud Testing
Broader coverage of the sites, templates and licenses partner portals run on.
Experience Cloud Security Testing
Deeper checks on external exposure, guest access and site-level security.
Sharing Rule Testing
Proves the sharing rules that decide which records each partner can reach.
Role Hierarchy Testing
Validates how partner roles sit under channel managers and inherit access.
Partner Onboarding testing FAQs
What is Salesforce partner onboarding testing?
It is testing the end-to-end journey that sets up a new channel partner in Salesforce — enabling the partner account, creating partner users with the right license and role, enrolling them in a program, and granting access to shared records on an Experience Cloud site. The test asserts the outcome from the partner's own view, including what they must not see.
Why test onboarding from inside the partner site?
Because access is only meaningful from the perspective of the user holding it. An administrator can open every record, so running the journey as an admin hides over-sharing and missing permissions. Logging in as each partner role shows exactly which leads, opportunities and pages they reach.
How do partner roles affect testing?
When an account is enabled as a partner, Salesforce creates partner roles beneath the account owner's role, and those roles determine record visibility within the partner firm and upward to the channel manager. Tests should confirm the role count, placement and resulting access, especially after the configured number of roles changes.
How is this different from customer registration testing?
Customer registration covers self-registration on a customer site, typically with a customer license and sharing sets. Partner onboarding usually involves an approval step, partner licenses, partner roles, deal registration and lead distribution, so its access model and failure modes are different.
What happens to access when a partner is offboarded?
Disabling a partner account removes its partner roles and affects its users, while deactivating individual users raises questions about record ownership and queue membership. Offboarding should be tested as deliberately as onboarding so former partners lose access completely and their records remain owned.
Is partner onboarding testing available in SyntraFlow today?
Experience Cloud journeys, including partner onboarding, are on the active roadmap and available for proof-of-concept engagements. The roles, sites and sharing model in scope are confirmed per engagement.
Onboard partners without over-sharing
Walk through your partner program's onboarding and access model and see how it can be tested end to end.