Skip to content

PartnerStack Salesforce Integration: Sync Partner Leads, Deals and Milestones

Plan the PartnerStack Salesforce integration with a dedicated API user, lead and deal mapping, sandbox tests, attribution fields and milestone rules.

Official documentation reviewed 7 November 2026 ยท Documentation-based guide

What does the PartnerStack Salesforce integration do?

The PartnerStack Salesforce integration connects partnership activity with the CRM records used by a SaaS sales team. PartnerStack documents workflows for creating Salesforce Leads from partner leads, creating Contacts when partners join, sharing Contact and Deal updates, rewarding partners when referrals reach customer milestones, and creating Accounts, Contacts and Opportunities for partner-submitted Deals.

The important implementation detail is that this should be treated as a configured workflow, not an assumption that every PartnerStack field automatically syncs both ways. PartnerStack’s Salesforce documentation directs administrators to authenticate the CRM and work with the onboarding team on the automations needed for the program. Define the objects, field mapping, ownership and reward rules before enabling production sync.

If you are evaluating the platform itself, see the PartnerStack software profile. For CRM workflow comparisons, read the PartnerStack HubSpot integration guide and the broader PartnerStack lead-to-customer tracking guide.

Which Salesforce records should each partner event create?

Choose the Salesforce object based on the stage of the relationship. A partner lead is not automatically a qualified sales opportunity, and a new partner is not a customer. A clean mapping keeps partner attribution visible without filling the sales pipeline with duplicate or unqualified Deals.

Partner activity Typical Salesforce record Implementation decision
A partner is approved into the program Contact, if the partner needs a CRM record Define whether partners belong in a dedicated record type or campaign segment.
A partner submits a prospect Lead Check for an existing Lead or Contact before creating a new record.
A partner submits a qualified Deal Account, Contact and Opportunity Use the agreed deal-registration criteria and preserve the PartnerStack Deal reference.
A prospect changes stage Existing Lead or Opportunity update Map only the stage and fields required by the partner workflow.
A referral reaches a reward milestone Opportunity or related partner attribution record Send the milestone to the reward process only after the qualifying condition is confirmed.

PartnerStack’s documentation lists these as common integration use cases. It does not mean every program uses every object. Start with the smallest set of records needed by sales and partner operations.

Prepare Salesforce permissions before connecting

Use a dedicated integration user that your organization controls. PartnerStack recommends an established Salesforce integration user with API access enabled and access to the objects the integration needs. Avoid connecting through an employee’s personal login: staff changes, password resets and permission changes can interrupt a business-critical workflow.

  • Enable API access for the integration user.
  • Grant read and write permissions only for the objects and fields used by the approved workflows.
  • Confirm access to Leads, Contacts, Accounts and Opportunities only where required.
  • Document who owns field changes, duplicate resolution and failed-sync monitoring.
  • If a Salesforce sandbox is available, connect and test there first.

PartnerStack notes that a sandbox can be used while developing automations with the onboarding team. Before switching to production, keep the sandbox and production field configurations aligned. A field mismatch can make an automation fail after a seemingly successful connection.

Set up the connection in a controlled sequence

  1. Audit the existing CRM. List the fields used for partner source, partner ID, referral ID, deal registration, owner, stage and customer conversion. Record the current duplicate rules.
  2. Choose the system of record. Decide whether Salesforce or PartnerStack owns each field. Do not allow both systems to overwrite the same value without a conflict rule.
  3. Create the integration user. Enable API access and grant the minimum object and field permissions required.
  4. Connect the sandbox. In the PartnerStack dashboard, an administrator can open Integrations, choose New connection, select Salesforce and authenticate the account. PartnerStack’s authentication guide describes the connection flow and the recommended user permissions.
  5. Define each automation. Work with the PartnerStack onboarding team to specify which partner events create or update Salesforce records, and which CRM updates should be sent back to the partner workflow.
  6. Map stable identifiers. Store the PartnerStack partner, lead and Deal references alongside Salesforce record IDs. Email addresses alone are not reliable unique keys because a person can change roles or use multiple addresses.
  7. Test and reconcile. Run new-lead, existing-contact, duplicate, Deal-registration, stage-change and milestone tests. Compare records in both systems before switching the connection to production.

Build a field dictionary before importing partner data

A field dictionary prevents the same concept being stored under different names in the CRM and partner platform. The exact field names depend on your Salesforce configuration, so treat the following as a design checklist rather than a claim that these fields are created automatically.

  • Partner identity: PartnerStack partner ID, partner display name and partner status.
  • Referral identity: partner lead ID, referral source, referral link or coupon reference where applicable.
  • CRM identity: Salesforce Lead, Contact, Account and Opportunity IDs.
  • Attribution: first referral date, lead source, partner owner and attribution status.
  • Commercial status: qualification stage, accepted Deal date, closed-won date and customer ID.
  • Reward status: qualifying milestone, billing confirmation, commission approval and payout state.

Use external IDs or another stable key where your Salesforce design supports them. For a deeper treatment of duplicates and merge rules, see PartnerStack lead deduplication rules and PartnerStack Leads vs Deals.

Keep CRM pipeline stages separate from commission approval

A Salesforce Opportunity marked Closed Won is a sales milestone. It is not automatically proof that an invoice was collected, a subscription remained active, or the partner satisfied every reward condition. Your commission engine should use the billing events and program terms that define an eligible conversion.

For example, a partner-submitted Deal might be accepted by sales, move to Closed Won, and then wait for the first qualifying subscription payment. The CRM should preserve the partner reference, while the commission ledger should wait for the payment event required by the program. This separation avoids paying on a forecast or an uncollected contract.

For B2B programs, document how Salesforce ownership, deal registration and billing confirmation interact. The sales-assisted affiliate attribution guide explains why lead source, sales ownership and payment confirmation should remain distinct.

Acceptance tests before production

  • A new partner record is created once and receives the correct partner reference.
  • A partner lead matching an existing Contact is updated or routed for review instead of duplicated.
  • A qualified partner Deal creates or updates the intended Account, Contact and Opportunity records.
  • CRM stage changes do not overwrite the original partner attribution.
  • A failed sync is visible to an owner and can be retried without creating duplicate records.
  • A customer milestone reaches the reward workflow only after the defined commercial condition is met.
  • Sandbox and production field mappings are compared before cutover.

Frequently asked questions

Does PartnerStack automatically sync every Salesforce field?

Do not assume that. PartnerStack documents specific integration use cases and guides for the workflows. Confirm the supported fields, direction and automation scope with the onboarding team.

Can I connect a Salesforce sandbox first?

Yes. PartnerStack’s authentication guidance says a sandbox can be used while developing automations. Keep the field configuration aligned when switching to production.

Does a Closed Won Opportunity automatically qualify a commission?

No. Treat the CRM stage as a sales milestone. Apply the program’s reward rules and confirm the required billing event separately.

Should every partner lead become an Opportunity?

No. Keep unqualified prospects as Leads until they meet the criteria for a registered Deal or sales opportunity.

Sources and editorial disclosure

Primary references: PartnerStack Salesforce integration and PartnerStack Salesforce authentication. These documents describe the supported use cases, connection flow, integration-user permissions and sandbox guidance. Reviewed 7 November 2026.

This is documentation-based implementation guidance. No PartnerStack or Salesforce account was connected or independently tested for this article. Field names and automation availability must be confirmed for the specific program and contract.

This guide is based on vendors’ official documentation and our research method. Tools are not hands-on tested unless a profile says so. Spotted something out of date? Suggest a correction.