Okay... big breath everybody... we’re taking on a monster here, and I’m going to attempt to do it succinctly.

Direct vs. joint object attribution

Point of clarification: Direct here does not refer to Sales.

Instead, it refers to whether we’re tracking attribution DIRECTLY ON the lead or opportunity in question or through a joint custom object.

My rule of thumb here is pretty simple.

If you only have ONE possible winner for the value, a direct attribution on the record is most likely going to be fine and simplify reporting and calculations. This should be through a relationship field on the core object that’s limited to the Partner

Accounts (by record type, as you’ve already done the hard work of building up an architecture, right?) In the screenshot below, the top area for ’Partner Source Details’ are fields on the Opportunity record. The following elements are present:

• Partner Account Reference Field (Limited to Partner Record Types)
• Partner Contact Reference Field (Limited to Contacts on the Partner Account)
• Estimated Partner Fee: Calculated from the Amount here, but could be as fancy as drawing values from approved quotes to provide accurate estimations on approved commission items.
• Partner Commission on Opportunity: This is ’stamped’ from the Partner Account record and editable here to maintain the % at the time the deal was closed and provide flexibility in adjusting some deals up or down if needed.

If you have MULTIPLE possible attribution points, the standard is shifting toward a joint object that pulls each relationship together. You can use this model to link Leads, Opportunities, Customer Accounts... whatever you want to tie back to multiple Partners.

You see this model labeled ’Partner Influence’ on the bottom component, which is actually a Single Related List view for the object. Here you can see some basic details, and we could elaborate on them as needed.

The architecture

My primary experience here is with Salesforce, but the basic architecture requirements are similar across any object-oriented database. Here’s an idea of what you will want to look at - clearly, you can go deeper here.

• Influence Custom Object
• Influence Custom Object Page Layout
• Field: Partner Account (reference field)
• Field: Partner Contact (reference field)
• Field: Opportunity (reference field)
• Fields: Opportunity Values (mapped from Opportunity as needed)
• Field: Influence Type (single or multi-select picklist - see caveats)
• Field: Approval Status (single select picklist if necessary)
• Field: Approver (User reference field, if needed)
• Field Approval Date (Date, if needed)
• Page Layout Update: Opportunities - add to any Opportunity layout as needed for engagement

Other data: partner relationship/connection object

With adjustments, this object could carry the load for Partner relationships to a variety of key data in the system, such as Customer Accounts, Licenses, Quotes, Renewals, Contracts... yeah... anything really. How?

Record types!

Every record type can utilize a different layout and, thus, a different set of fields for user engagement. This would warrant a different name for the object - something like ’Partner Connection Object’ or ’Partner Relationship Object’ or ’The Tie That Binds’... yeah maybe not the last one but you get it.

The next step is to add the ’Connection’ object wherever it needs to be. What’s nice here is that you shouldn’t have to do any fancy filtering to make sure only the records you WANT show up because they are automatically limited to that object.

Advanced plays

Getting the object set up is really basic SFDC administration - we’re not really doing anything fancy from a technical standpoint as it’s all ’point and click’ features. Once in, however, you can start to advance your utilization based on your processes.

Product attribution

My friend Clark Wright has talked about leveraging SFDC’s ’out of the box’ (OOTB) features for Partner connections and automation he put in place to drive influence creation based on product selection.

Every time certain products are added as Opportunity Products the automations kick in to generate a new influence record for that partner.

With everything living on the Opportunity, reporting is easy to manage through standard report types. What’s great about this is that Sellers don’t have to do anything outside their normal rhythm, a big win for anyone familiar with the effort to get data out of the Sales organization.

Automation

Working with automation can improve overall utilization for approvals as well if that’s part of the program.

Deals can be blocked from Closing if there are any unreviewed ’Partner Influence’ records attached, for example. Or you can use in-system notifications to drive visibility alongside emails and help people find work faster.

These could also be programmed to evaluate specific program terms, look for duplication, or route data for review and ownership.

The sky’s the limit here! And by sky, I do mean your available resources and budget for partnership-related work... so.... yeah... no comment there.

The caveats

1. Reporting is still the goal. It’s great to understand influence, but let’s not forget what we really want is an understanding of how Partners impact the organization. I’ll call back to my prior article on this one: Show Me the Money... by Program and Partner.
2. Out of the Box (OOTB) features for Partner connections exist, but as Brian Hattaway at Iolite has mentioned in the Partnership Leader slack channels, they come with limitations. Many organizations looking for advanced reporting, functionality, or more control will find them limiting.
3. He also highlights the value of custom setup when tracking Partner engagement across multiple programs (Tech Partners that are engaged in Referral, Co-selling, and possible SI work, for example). He’s working on a write-up around the OOTB features and I’m looking forward to the details.
4. PRMs may not align for Opportunity visibility without a direct attribution on the Opportunity record. Check with your Ops team and vendor on how this exposure works and requirements before committing to a new direction.
5. Influence is still a subjective concept. You’ll ultimately want to build a list that works for you and your specific goals and program metrics. What ties to revenue and payouts? What ties to performance? How does your internal team view this compared to your Partner? All relevant questions to consider!
6. CRMs will typically require advanced licensing models (Professional to Enterprise levels) to support customization like this. Yes... Even Hubspot. If you’re not already on those levels you may be looking at a significant cost increase across your entire user base.
7. You can run out of custom objects! Custom objects have their own limitations based on licensing and require custom reports. You could run out of objects in lower editions just trying to get Partnerships spun up so you’re still fighting for resources in a key direct platform, as they will definitely want those objects for their own use.
8. Custom objects require custom reports. Depending on your administrative support or personal skill set, this could be more or less annoying. The main challenge is that you need to provide clear definitions for what you want in the reporting model if you have someone else do it. You can learn more about them from Salesforce here or, if you’re like me and like to see it, watch a video from a professional in the community.
9. Single v. Multi-select is an important choice as it has an impact on reporting models, user experience, integrations, data exportation, historical updates, data consumption and more. Here’s a good write-up of the risks and potential benefits from Insycle. My experience pushes me toward single select pick-lists, avoiding multi-select like it’s a checkbox field. There ARE good use cases, however, but a lot of organizations without proper support end up creating headaches by using multi-select where a single-select would be more appropriate. Check with your admins and make the decision that’s right for your org.

The wrap-up

The bare minimum takeaway here is that tracking influence is both entirely possible and benefits from some intentional planning.

I generally advise against giving your setup teams (RevOps, SalesOps, Systems, IT, etc.) explicit direction on the technical setup - they know the critical elements of your org, such as data governance, integrations, and dependencies to work around after all - but they will need strong guidance on intended outcomes and Partnerships, in general, most of the time.

This is where a lot of program leads end up being split between program strategy and operations in their role. 

As always, lean into your existing tech stack and work your internal influence to get some help delivering results.

Partnerships is all about collaboration, after all, and when more people pitch in, you end up with greater awareness and buy-in. I’ve said it before and I’ll keep saying it - we’re all in Partnerships; some people just don’t realize it.

Prefer to listen? Check out Aaron’s podcast here:

Partner Influence: Purpose, Architecture, and Caveats by Behind the SaaS

Listen to this conversation and get some additional insights!-