You’re offline. This is a read only version of the page.
3,079
We're currently struggling with how to relate accounts and contacts in our implementation. The idea of a person having a single organization to which they belong (via the OOTB lookup) doesn't really fit our scenario. With our clients, there's generally a lot of people who work/volunteer for multiple orgs at once, plus they move between them with regularity. Also, our clients can be individuals as well as orgs.
The issues with doing this via the lookup are:
1. Only one account per contact (unless you add a second lookup, then maybe a third, etc... and all of the requisite fields).
2. No good history tracking (when did they start/leave).
3. If they move, either their activities go with them to the new account, or you have to create a second contact record (which is not an option for us, as having a complete picture of our relationship with these individuals as they move around is very important).
So using Connections solves these issues, but then has the following cons:
1. Less intuitive reporting
2. Activities do not roll up at all
3. Rollup fields will not work
The only solution I can see that maintains the level of data integrity we need to have seems to be to use Connections, but then to write custom code of some kind to roll up activities, numbers, etc... specifically for the dates during which that contact was connected to that account. Are there any other options I'm missing? Is anyone aware of any code out there that does anything like this?
This still doesn't fix the "less intuitive reporting" issue, but I don't see a perfect solution and data integrity is more important than intuitiveness of report building - we can always build it (or at least a base) for them if the data is good.
*This post is locked for comments
So in the case of an N:N between accounts and contacts (or Connections, for that matter), any thoughts on how I would get the activities to be visible on the account and the contact both? If we manually add both to the Activity it would be fine, but 1. that probably wouldn't get done consistently, and 2. in the case of things like appointments you'd have invites going to both the account and the contact, when you'd only want one invite going out. If it's an N:N relationship, we also can't easily automatically fill in the associated account, since there might be multiple accounts for the contact.
I'm peeking at the possibility of javascript to lookup the connected/related orgs and add them to another field on the form (and people could then remove/correct ones that aren't right), but then there's still the issue of where to add them on the activities. (Can't add party fields, anything added to invitees or to fields syncs to Outlook, and if we made a custom activity instead with all party fields, it wouldn't sync to Outlook.) Plus we'd need some way of marking which org was primary (and enforcing that), to know which org to default.
I am not 100% sure about reporting. In my opinion the manual n:n might be slightly easier but not much in it probably. (And it will depend on what you actually need to achieve.)
You can add start date (etc) to a manual N:N. So again not much to pick between them there. Except maybe that the connection role can be user defined. But if you wanted that you could always create a lookup entity on a manual n:n.
Connections do have a distinct advantage when multiple entity types need to be connected. Say you want to connect an account to many contacts. But also connect the account to many other accounts. (Or any entity.) I have seen requirements like this when working with legal companies who have complex networking between their accounts and contacts.
Your final decision might come down to the user interface. I personally like the way a quick create form works with a manual n:n relationship. But it really is personal preference.
Interesting - seems like a couple of votes now for manual N:N vs Connections. What advantages does that have over Connections? I'd still be able to have the roles, start date, end date, etc... on the Connection, so what does the N:N buy us? Is it easier to report on? Seems like it'd actually be trickier, to me, but I'll try to get in some tests today.
Thanks for the thoughts! Happy to hear of more suggestions/experiences if people have them...:-)
I would consider a manual many to many relationship between contact and account. Plus add into the intersection entity a field called something like relationship type. As a contact could be an employee for one account or a volunteer on another etc.
Each account would have multiple "account contact" records, with "account contact" being a new custom entity. That each "account contact" entity would be related to a contact. Meaning you achieve a N:N between account and contact via the custom entity.
I am not too sure either, I would have to test those too. I have also seen people build out a landing page as such, that will connect to the Account with a 1:N to the landing page and then a N:1 to Contacts. This middle Entity would have many records for each Contact, but you retain all the functionality of the 1:N relationship. But all reporting needs to come from this landing page rather than either the Contact or the Account entity.
This actually worked quite nicely.
I assumed that the rollup of activities was something inherent with the OOTB account to contact relationship (but admit that I have no evidence of this...I'll do some testing around it). But also, it's my understanding that a native N:N wouldn't allow us to add fields like role, date, etc...that would need to be a part of that, so it would have to be a manual N:N. This seems like it would have the same issues Connections would, in terms of having to do custom code around displaying things/rolling things up for specific date ranges. I could be wrong, though - have you (or anyone else?) tried this, and have comments on how hard/easy it was to work with?
What is the downside of restructuring the relationship to be an N:N? This way you can have the same contact record on many Accounts. You will need to build out a time stamp of when they where associated where, this would have to be done through code, but I have seen that before.
Up side is that you can go to One contact record and see what Accounts they are on, and the reporting would be running off of one record. I am thinking that you have considered this, why was it not adequate?
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,253
Super User 2024 Season 2
#2
Martin Dráb
230,188
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (