Understand the EDA Account Model
Learning Objectives
After completing this unit, you’ll be able to:
- Describe the difference between the Salesforce account model and the EDA account model.
- Explain the difference between the administrative account model and the household account model.
- Understand the default account record types included in EDA.
Salesforce and the Account Model
A quick Salesforce history lesson: Salesforce was originally designed as a business-to-business (B2B) application to help companies improve their sales processes, and by extension, maximize their sales. In the traditional B2B scenario, each company keeps track of their accounts—the other companies or businesses that they are selling to. Each account has people associated with it (contacts) and other things such as opportunities, cases, and tasks. How all these things relate to and interact with each other in Salesforce is known as an account model.
In the K-20 world, we track things a bit differently. Yes, we manage activities with companies and businesses that we partner with to attract potential students, high schools we recruit from, and other institutions that we receive transfers from. But in addition to all that, we care about our students—what they’re doing, the classes they’re taking, and the clubs they belong to. We also want to keep track of things such as departments, sports teams, and alumni networks. How then is one supposed to manage all these components in an application designed for business? With EDA and the EDA account model, Salesforce.org has designed a great solution!
The EDA Account Models
The EDA account model is closely aligned to the standard Salesforce account model. It gives you all the power of Salesforce without forcing you to customize the standard model to suit your needs. You can still do business tracking in EDA if you want to—standard Salesforce objects like opportunities and cases don’t go away. But with EDA, Salesforce.org has created an application that provides custom functionality geared toward how education audiences work.
In the EDA account model, the standard Salesforce account object acts as a container account. EDA offers two kinds of container accounts: the administrative account and the household account.
The administrative account has a single contact associated with it—this is often a student but sometimes a faculty member, alumni, or other person related to the educational institution. The relationship between the account and contact is one-to-one. So for each contact that you create in EDA, you also have a unique administrative account. You can think of an administrative account as the account-level representation of a contact.
The household account functions just like its name suggests, to represent the household a student contact belongs to. Unlike the administrative account's one-to-one relationship, a household account typically contains multiple contacts besides the student, such as parents or guardians, siblings, and other members of a shared household.
Whichever account model you go with, Salesforce creates the container account (administrative or household) for you each time you create an independent contact—that is, a contact that is not part of another account. By default, the name of the new account uses the last name of the new contact. (EDA allows you to customize the naming convention of the container account—more on that in a later module.)
For example, contact Pete Peterson belongs to the Peterson Administrative Account. On the contact record, it looks like this:
If you're using the household account model, it would be named the Peterson Household Account. As you can see, the choice of administrative versus household affects the naming of accounts. It also affects the way that EDA manages address data for contacts and accounts, because household accounts enable more complex address management.
The reason we're emphasizing this concept is that contacts are at the center of EDA. Placing the contact at the center enables a full 360-degree view of that constituent, allowing you to answer essential questions about the contact such as, "What are their interests?" or "Who do they know?" In Salesforce, each contact must be associated with an account. Without an account, a contact is only visible to the person who created it.
Choosing an Account Model
So which account model is best for you? Every institution is different and you can choose the approach that works best for your school. If you’re working with an implementation partner, your consultant can assist in this decision process.
When Nina started her admin role at Cloudy College, choosing an account model was one of the first decisions she had to make. She understood that deciding on which account model to use (or if she should use both) depended on a number of factors. She created this table to help her organize her thoughts around a few factors worth consideration.
|
|
|
|
|
Default Model |
X |
|
|
Simpler Account Level Maintenance |
X |
|
|
Supports Multiple Contacts per Account |
X |
|
|
Supports Household Address Record Tracking |
X |
But what if you have a use case for both models? It’s possible to use different models at different points of the student lifecycle and some institutions even use both types of container accounts in the same org. Flexibility for the win!
For example, Nina decided it made sense to use administrative accounts to support processes related to recruitment, admissions, and actively enrolled students and then convert the student contacts to a household account model when they become alumni.
Regardless of what works best for your institution, you will have to choose which type—either administrative or household account—to set as the default in your org-level EDA Settings. Whenever you create a new, independent contact (that is, a contact that is not part of another account), EDA automatically creates the container account for you, using the type you specified as the default.
Contacts, Relationships, and Affiliations
So now we have a contact and an administrative (or household) account, but the contact record doesn’t mean anything unless you can do something with it. When you first create it, the contact is a blank canvas. It simply represents a person that you have basic information about. Now you need to define how that person relates to your educational institution. Is the contact a student, a faculty member, an alumni, or more than one of those? Does the contact play sports or belong to specific clubs? And does the contact have connections to any other contacts at your educational institution? Is the contact the child of an alumni member? Is the contact married to another contact? This is where relationships and affiliations come in.
As part of the EDA account model, EDA offers two important custom objects that work in conjunction with your contacts.
- The relationship custom object tracks relationships between contacts (who do they know?)
- The affiliation custom object tracks affiliations between contacts and other accounts (what are their interests?)
What do we mean by “other” accounts in this instance? Well, in EDA that could be a department. It could also be a sports team. It might be a prospective employer. The architecture is flexible! The important thing to remember is that affiliated accounts aren’t other people. They’re things or groups such as departments, academic programs, universities, and other companies or organizations. And as part of the affiliation, you determine the connection the contact has to the account (student, faculty, athlete, and so on) by including the contact’s role.
On the flipside, connections between people—technically other contact records in Salesforce—are created using the relationship object.
Let’s look at an example. Pete Peterson (a contact) is connected to people (other contacts) through relationships. He is connected to programs and interests (accounts) through affiliations.
In our example, the Peterson administrative account isn’t an affiliated account. It’s the parent account that’s required for your contact. When you create affiliations to other accounts, such as departments, sports teams, and so on, EDA relates those accounts directly to the contact (in this case, Pete Peterson).
This is just a quick look at how relationships and affiliations relate to the account model and contribute to the 360-degree view of a constituent in EDA. We’ll take a more detailed look at both relationships and affiliations in a later module.
And with that, you’ve completed your introduction to EDA by learning the basics of the architecture, its settings, and its account model. This is a major milestone on the education admin journey, but if you’re ready for more, we’ve got so much more to share with you. We’ve linked a module below that would be a great place to explore next. Nina will be there, too. See you on the trail!