Your Partners Are Already in Salesforce. Use Them.

The slowest part of standing up a partner program is usually data entry for companies your CRM already knows about.

---

Ask a team how their partner list got into the partner program and the answer is often that somebody exported a view and re-typed it. That has two costs: the obvious afternoon, and the one that matters — the list is stale the following week, because new partners keep arriving in the CRM and nothing carries them across.

The four decisions

Syncing is less a configuration task than four decisions, and getting the second one right is most of the work.

1. Which object stores your partners. There is no universal answer: some organizations keep partners as Accounts with a record type, some use a dedicated object. Ask where your own team actually creates a partner, not where the data model says they should.

2. What filter identifies a partner. This is the real decision, and the field type matters: a picklist gives you the same controlled dropdown Salesforce shows, with no typo risk. A free-text field has to match spelling and case exactly — confirm the value with whoever owns your Salesforce data rather than typing what you think it is. A filter that is too loose pulls customers into the partner program; too tight and the partners your team adds next month never appear. The test is not whether the filter matches today’s list — it is whether a new partner, created next month by a rep following your normal process, will match it.

3. Which fields are name and email. Mundane, and the one that breaks quietly. The email you map becomes how the partner is contacted and invited, so mapping a generic company address rather than a person’s is the difference between an invitation that reaches someone and one that reaches nobody.

4. Whether documents come too. Files on your Salesforce partner records can flow into the file library automatically. Worth an explicit decision rather than a default, because partner records often carry agreements and internal notes, and “everything on the record” is rarely what you meant.

Test before you save

There is a test step before saving, and it is not ceremonial. It answers the only question that matters — does this filter select the companies I think it selects — at the one moment when a wrong answer is free.

The failure it prevents is specific and annoying to undo: a filter that is slightly too broad imports a set of customers as partners, and now your partner program has records that should not exist, in a system that other people are already looking at.

What “stays current” actually buys

The recurring value is not the initial import — it is that your partner program stops being a snapshot. A rep creates a partner account in Salesforce the way they always have; it appears in the program without anybody being told to do anything.

That is what makes a partner program survive contact with a growing team. Any process that depends on somebody remembering to copy a record across will drift, and the drift is invisible until somebody asks why a partner has no portal access.

Frequently asked questions

Which Salesforce object should store partners?

Whichever one your team actually uses to create a partner today — often Accounts with a record type, sometimes a dedicated object. Match the real process rather than the intended data model.

How do I choose the filter that identifies a partner?

Test it against the future, not the present. A good filter matches a partner your team will create next month following their normal process, not just the companies on today’s list.

Which email should I map?

The one you want invitations and notifications to reach. Mapping a generic company address rather than a person’s is the most common reason a partner invitation reaches nobody.

Do Salesforce documents come across too?

They can — files on partner records can sync into your file library. Make it an explicit decision, since partner records often hold agreements and internal notes.

Why sync instead of importing once?

An import is a snapshot that starts going stale immediately. A sync means a partner created in the CRM next month appears without anyone remembering to copy it.

Takeaways

• Four decisions: the object, the filter, the field mapping, and whether documents follow.
• The filter is the real work — judge it by whether it will catch next month’s partner.
• Map a person’s email, not a generic company address.
• Use the test step. A too-broad filter imports customers as partners, and that is unpleasant to undo.
• The point is not the first import; it is that the list stops being a snapshot.

More on the program in the partner relationship management overview.