Skip to main content
Attribution is the link between a Salesforce record and the partner who sourced or influenced it. It is what makes partner-attached pipeline, reporting, and commissions trustworthy - so it deserves to match how your org is actually modelled, not the other way around. Salesforce orgs model that link in four different ways, from a single field to a full junction object. Introw supports all four out of the box. There is no RevOps project, no schema rebuild, no code, and no consultant. You keep your existing model; you simply tell Introw how a record is linked to a partner, and from there Introw does the rest:

Reads it in

Introw pulls every matching , even old ones, and attributes each correctly.

Embeds it

Attributed records appear in portals, dashboards, commissions, and reporting under your name.

Writes it back

A form submission is attached with the exact method you configured, so the record is born compliant.
The whole point: you match your system to Introw once, and Introw matches every record to your system forever. Historic s become attributable, and new partner-created records are born correctly attributed. That is the backwards-compatibility and data-hygiene win - and it holds for whichever method below you already use.

The four methods at a glance

Picklist field

A picklist on the Opportunity names the partner. Simplest; no relationships needed.

Lookup to an Account

A lookup field points the Opportunity at the real partner Account. Clean and reportable.

Relation (junction) table

A junction object (e.g. OpportunityPartner) links many partners to one opportunity, with roles.

Custom object

A dedicated Partner object relates to opportunities, accounts, and contacts. Richest data model.
Configure Opportunity attribution at minimum - it is what reporting and commissions run on. You can attribute contacts, accounts, cases, and custom objects to partners the same way.

Method 1 - Picklist field

Best for: simpler programs with one partner per opportunity, and teams that want attribution with no relationships to design. A picklist field on the Opportunity (e.g. “Partner Name”) holds a predefined set of partner values reps select from.
A picklist stores a fixed list of values on the record. Reps choose the partner from the dropdown on the Opportunity. It’s the lightest-weight option - no relationship, no junction - and easy to report on with standard Salesforce reports.
Choose Custom properties and select the picklist. If the values are coded (IDs or abbreviations rather than partner names), use Match property values to Introw partners to line each value up with the right partner record.
A picklist is text, not a relationship - it doesn’t point at the real Account, and values can drift if hand-maintained. Great to start; consider a lookup or relation table as the program scales.

Method 2 - Lookup field to an Account

Best for: clean one-to-one attribution where you want to reference the real partner Account and pull its data. A lookup relationship from the Opportunity to the partner Account stores the actual partner record, not a text label.
A lookup is a loosely-coupled relationship connecting one object to another. A custom lookup field on the Opportunity (e.g. “Partner Account”) points at the partner Account record. Because it references the real Account, you get the partner’s data, clean roll-up reporting, and no duplicated names. An object can hold up to 40 relationship fields, so adding a partner lookup is no strain.
Choose Custom properties and select the lookup field that points to the partner Account. Introw resolves the lookup to the partner record automatically - no value mapping needed, because the field already references the real Account.
You are not restricted to a custom lookup: the Opportunity’s standard AccountId can be selected as the attribution property too. That fits programs where the Account on the opportunity is the partner rather than the end customer - a distributor or reseller model where you sell to the partner and they resell onward. For programs where AccountId holds the end customer, keep it as the customer and add a separate partner lookup, so the two are never conflated.
A single lookup holds one partner, but you are not limited to one lookup. Add a lookup field per role - “Sourcing Partner”, “Delivery Partner”, “Implementation Partner” - and map each as its own named attribution in Introw, so one opportunity credits several partners across tiers. A relation table (Method 3) is the alternative when the set of partners or roles is open-ended rather than a fixed few.
The lookup-to-Account is the recommended default for most Salesforce programs running one partner per deal: it’s clean, native, reportable, and Introw reads it with zero mapping.

Method 3 - Relation (junction) table

Best for: multiple partners per opportunity, revenue splits, or programs that track the role each partner plays. A junction object between Opportunities and partner Accounts creates a true many-to-many relationship. Salesforce even ships one for exactly this: the standard OpportunityPartner object, surfaced as the Partners related list on the Opportunity.
A junction object is a child of two parents, connecting them many-to-many. Each row links one opportunity to one partner account, and carries a Role (Reseller, Referrer, System Integrator, …) and an IsPrimary flag. So one opportunity can credit several partners at once, each in a distinct role. Salesforce’s built-in OpportunityPartner is a legacy object that can’t be customized, but you can also use your own custom junction object if you’ve built one.
Choose Relation table, point Introw at the junction object, and confirm the two keys that connect the opportunity to the partner account. Optionally add a filter that scopes which rows count. The defaults match the standard Opportunity Partner relation, so most orgs change nothing.
Because each row carries a Role, you can create one named Introw attribution per role - filter the relation to Role = Reseller for a “Reseller partner” attribution, Role = Referrer for a “Referring partner” attribution - all reading the same junction. See multi-tier attribution below.
When a partner registers an opportunity through an Introw form, Introw writes a junction row attributing the submitting partner (for the standard object, Role = "Partner", IsPrimary = true) - so the record is compliant with your relation model the moment it’s created.

Method 4 - Custom object

Best for: large programs that treat partners as a core part of the data model, with tier, region, focus, and program data on a dedicated record. A dedicated Partner custom object relates to Opportunities, Accounts, and Contacts, and Introw treats it as the partner.
A custom object is your own object with its own fields and relationships. You model partners on it, relate it to opportunities via a lookup (or a junction for many-to-many), and hold tier, region, focus, and program data on the record itself.
Set the partner object to your custom object during connect (the “How do you store partners in your CRM?” step). Then attribute opportunities via the lookup or relation that connects them to it. Introw resolves the custom object to the partner and reads its fields into segments, portals, and reporting.
Fully flexible and scalable, but it needs upfront schema design. Best when a single Account or lookup can’t capture how you run partners.

Multi-tier attribution - more than one partner on an opportunity

Real ecosystems rarely have exactly one partner per opportunity. A referrer surfaces it, a reseller closes it, an implementation partner delivers it. Introw models this natively: you can define several named attributions on the same object, each with its own name. You do not need a relation table for this - every method here can be repeated, including the single-value ones: add a lookup or picklist per role and map each as its own attribution, so one opportunity credits several partners across tiers. You can mix and match the mechanisms to express roles:

Relation-table roles

One attribution per Role on the junction - Reseller, Referrer, SI.

Multiple lookups

Separate lookups like “Sourcing Partner” and “Delivery Partner”, each mapped independently.

Multiple picklists

Distinct picklists per role when you’re not using relationships yet.
Each named attribution is independently reportable, so several partners can be credited on one - a sourcing partner and an influencing partner side by side - and your commission plans run on whichever attribution(s) you scope them to. Name each attribution clearly and it reads that way in reporting, in the portal, and to partners.

Two-way by design - read and write

Attribution isn’t only about reading what exists. Introw also writes attribution the same way you defined it, so the model holds no matter who creates the record.

Backwards compatibility

Point Introw at your existing model and every historic becomes attributable, in the right partner’s pipeline. Nothing to backfill.

Data hygiene going forward

A partner registering through a form is attached with the exact method you configured - compliant from creation, not reconciled later.

No RevOps work either way

You never restructure . Tell Introw once how objects link to partners; reading old records and writing new ones follow that one definition.

Choosing a method

Whichever you choose, configuration is the same shape: open Object Linking, pick the method, name the attribution, decide if it’s commission-eligible, save. Introw handles the rest - no code, no consultant, no RevOps project.

Set it up

Whichever method you chose, you configure it in the same place: the Object Linking screen. This is the same attribution step the connect wizard runs, reopened any time to add or refine a mapping.
1

Open Object Linking

Go to Integrations, open the connected Salesforce connection with Configure, and go to Which objects do you link with partners?. Select Add object, or open the existing Opportunity mapping to edit it. Configure Opportunity at minimum, since it is what reporting and commissions run on.
2

Choose how opportunities attribute to partners

On How do you attribute partners to Opportunity objects?, pick the method that matches your org: Custom properties (a picklist or lookup field on the opportunity) or Relation table (a junction object such as an Opportunity Partner relation). This mirrors the methods above.
3

Configure the method and map values

For Custom properties, select the field that identifies the partner. For a Relation table, point Introw at the relation object and confirm the keys that connect the opportunity to the partner account, and optionally a filter that scopes which rows count. The defaults match a standard Opportunity Partner relation, so adjust only if your org differs. If a field holds coded values rather than partner names, use Match property values to Introw partners.
4

Name the attribution and save

Set What name do you want to use for this attribution? so the link reads clearly to your team and partners, then select Add Opportunity attribution (or Save when editing). Confirm when Introw asks you to verify. To credit more than one partner on the same opportunity, add another Opportunity attribution with a different lookup, picklist, or relation-table role (for example a “Delivery partner” alongside a “Sourcing partner”) - each is its own named attribution. Repeat Add object to credit other record types too.

Verify it worked

Open a partner-influenced in . In Introw it shows attributed to the right partner under your attribution name, and that partner’s sourced/influenced pipeline reflects it in reporting and commissions. For a partner-created , confirm the attribution (association, field, or relation row) was written on the record itself.

Connect Salesforce

Set up the connection and run this attribution step inside the wizard.

Partner attribution in HubSpot

The same depth for HubSpot - properties, association labels, and roles.

Partner attribution in Pipedrive

The property-based method for Pipedrive.

Show & rename CRM fields

Put any Salesforce field on your Introw tables, overviews, and partner views - renamed to partner-friendly labels.