Working in the Higher Ed space, or any B2C O2I*[1] organization, can present the Salesforce Administrator with a headache: how to manage the Account of the Contact record, when the Contact is as important, if not more important, than Account.
Sure, Accounts are important – we want to know about the schools we recruit students from, the companies where they end up working, the foundations who contribute to alumni relations and the partner organizations we work with. But we don’t want the Account to dictate how we deal with the Contact. Salesforce, however, mandates that all Contacts are associated to an Account.
What are the traditional Salesforce configuration options for a Higher Education Institution?
- Person Accounts: A ‘standard’ Salesforce function which rewrites the data model, turning the Account record into a ‘Contact’.
- Administrative Accounts: Create an Account for every Contact record.
- Household Accounts: Create an Account for the Contact, their spouse, parents, siblings, as required.
- Bucket Accounts: Lump all the Contacts into a single account.
Where these traditional models fail:
- Person Accounts: Difficult to support a blended O2I and B2B model in the same org, it is not compatible with all AppExchange products and is known to have other issues.
- Administrative Accounts: Creates two records for every one, and the Account record becomes meaningless clutter which the analysts and data miners have to work around.
- Household Accounts: This can be a complicated concept for users – where does one household start and the next one end? We have to know the relationships between individuals and know how and when to maintain them.
- Bucket Accounts: A simple solution, but limited to no more than 10,000 contacts per account (Salesforce best practice).
Is there an alternative?
We believe so: An Affiliation-driven Contact. HEDA (Higher Education Data Architecture) is included as an “Affiliation junction” object – this may exist in your org as an ‘Employment History’ object or similar. This object allows you to create multiple relationships between Accounts and Contacts.
It can track:
- Where someone went to college
- Where they worked after graduation
- Where they work now
- Which community organizations they volunteer with
- Which company boards they are on
Let’s assume for a minute that in your affiliation record, you have a start and end date for each affiliation – no end date means that there’s an ongoing relationship, e.g., Jill is working at the bank or Pat is studying at the university. Now it’s possible that someone can have multiple active affiliations – Jo is working here, on the board there and consulting too. However, Jo is probably going to identify one relationship as primary – so let’s use this one relationship to set the Account on the Contact record.
How does this help?
If you, as a Salesforce user, need to look at the Contact record, you probably want to understand how the Contact identifies themselves – now when we look at Chris’s record, straight away we see Chris James, ABC Bank. On the flip side, if you need to review the ABC Bank record, you’ll find Chris and all the other currently associated affiliations as Contacts.
How do we make this happen?
There are three steps to putting this Affiliation-driven contact in place:
- Ensure that your Affiliation object has a “Primary” checkbox: This field allows a user or contact to identify their main relationship. [HEDA complicates this by having a primary relationship for each account record type, so you’ll need a new “primary”]. The business rule here is that each Contact can only have one Primary Affiliation.
- Add a Process Builder on the Affiliation object: When a record is marked as “Primary,” update the Contact with the Account of that record. Also run the flow in step 3.
- Add a Flow to set the “Primary” checkbox on the other (existing) Affiliation records to false
(i.e., only the new Affiliation record is Primary = true). - Or Replace step 2 and 3 with a trigger
The mechanism is straight-forward, but it’s important to coach/train your users on how to create/manage the Affiliations (not to directly update the Account on the Contact).
Where does it get complicated?
There are a number of reasons why this could get complex, therefore it’s up to each Org to review the best practice.
- What if my contact isn’t working anywhere? Full-time students will not have a main job, so you need to consider a bucket Account for the students currently enrolled, then move them when they graduate.
- What if my information is old or incomplete? In my opinion, some data is better than no data, and it will be updated when you next hear from the Contact. However, the organization has to accept, as a policy decision, that sometimes they’re working with ‘mostly current’ data.
- How about Security? If Accounts are Private in the OWD (Organization Wide Defaults) or if Contact is ‘Controlled by Parent’, you’re going to have to think through record visibility. This will work best if Accounts and Contacts are, at least, Public Read-Only.
- What if there are Accounts with dozens, even hundreds, of Contacts? To separate out Bruce-the-alumni from Alfred-the-recruiter, you may want to add Contact Roles to the Account.
- Purely consumer/contact engagements. For organizations where there is absolutely no suggested account data, then this model isn’t going to help. This model helps orgs track a Contact’s relationships with different accounts over time.
A shift in thinking is key: Accounts no longer come first – Contacts are first, Affiliations are second, and Accounts are a product of that relationship.
What are the perks?
- Account records are dynamically maintained with active student and alumni data – valuable to those working the network within the account.
- Executive Education and Professional Graduate applications [opportunities] can be associated to the company where someone works. Now you can quantify the relationship with an Account.
- Contact records behave similar to a B2B organization, in that an Account shows its active Contacts.
- New Affiliation data automatically updates both Contact and Account.
- No ‘placeholder’ records are created in the Org.
- Communities, or Marketing Landing Pages combined with LinkedIn login credentials, can provide end-users a way to update their own information.
In conclusion, the Affiliation-Driven Contacts model gives your Salesforce Admin the opportunity to create a sustainable Contact-Account model. Now, the O2I organization can align itself with native Salesforce behavior. The model is simple to implement and leverages existing data and accounts. Finally, there isn’t a conflict with HEDA, and placeholder accounts are avoided.
Contact us to learn more about this model.
[1] Organization-to-Individual. Business-to-Consumer just doesn’t work in this space!
