Hi all!
Quick context: we are an education philanthropy that moved to SF + OBJ about 2 years ago. One challenge we are grappling with right now is how to manage multiple contacts associated with our FRs. This list includes:
- Applying contact
- Primary leader/founder
- Secondary leader/founder
- Grant signatory
- Payment contact
- Fiscal sponsor contact (when relevant)
- FS signatory
- FS payment contact
- Relationship management contact (we provide ongoing support)
- etc...
For this type of thing, are folks using the default "FR Role" object? We have found that that type of thing, similar to Affiliation, is really difficult for our staff to use and keep track up. We had been using "flat" fields for some of these contacts, like the primary/secondary leader, since we also report on leader demographics but this meant folks need to update info across contact records, affiliations, and the FR. We're moving to move contact record lookups directly on the FR but curious if there's another way we should be thinking of!
Thanks!
#Outbound Funds
The Funding Request Role object is the right home for this — it's built exactly for the case of many contacts, each with a role, on one FR, and adding a new role type is just a picklist value, not a schema change. Your instinct to move off flat fields is correct; the pain is that you're spreading the same info across flat fields + Affiliations + roles at once.
A hybrid that fixes both the reporting and the UX:
1) Make FR Role the single source of truth for the full, variable list (signatories, payment contacts, fiscal-sponsor contacts, the rest). It handles the long tail without a field explosion. The FR also has a native applicant lookup for the primary applying contact/account — use that for the applicant, FR Roles for everyone else.
2) For the one or two roles you actually report on (primary/secondary leader demographics), keep a flat lookup on the FR but auto-populate it with a record-triggered Flow: when an FR Role of that type is created or updated, stamp the FR lookup. That kills the manual double-entry you called out, and demographics stay a simple FR-to-Contact report.
3) The FR Role UX complaint is usually fixable without dropping the model: add a screen flow or quick action to attach a contact in two clicks, and put a clean related list (Role, Contact, key columns) on the FR layout.
4) Keep Affiliations for the durable who-works-where org relationships and FR Roles for per-request context — different grains. Forcing Affiliations to carry per-FR roles is part of what is hurting.
Net: junction as source of truth, Flow-sync the handful you report on, invest in a good entry component.
if this helps, please mark it as the Best Answer so it helps the next person — thanks 🙂
