Why does EDA offer an "Educational Instution" record type in addition to "Administrative"?

Question

Does anyone who works with EDA know what the difference is meant to be between an Account of type Administrative and an account of type Educational_Institution when it comes to storing data about the thousands of schools and universities across the US / world that are not you?

1. Is the latter just a way to get a bunch of "validation table" data easy to query separately from other Accounts that also make good Administrative accounts, but offer nothing special beyond "getting birds of a feather together somewhere else besides Administrative, if you're the kind of person who hates clutter"?
2. Does setting an Account to Educational_Institution offer anything to incentivize doing data governance to use it instead of Administrative?

Answer 1

They're for different concepts - one can represent a person (or household) while the other represents a non-person entity.

Can you choose to create Administrative accounts to represent other Institutions anyway? Sure, you have that flexibility to utilize what's delivered (or not utilize) to best support your needs. You also have the Education Cloud Settings page where you can turn off any functionality that causes friction though I don't believe any is "on" by default (ex. Delete Accounts with these records types if they have no Contacts).

---

For a longer dive into it, it's good to start with the origins of why the concept of person and non-person record types was delivered. Education Data Architecture (EDA), as beta at least, was being worked on in July 2015. PersonAccount, while I can't find old release notes, was something still behind requesting support to enable the feature so a lot of these concepts in EDA do seem tied to that concept of a "Person" account, but not having the Salesforce feature of PersonAccount fully available (or meeting the needs at the time) for packaging.

In the docs, it explains how EDA supports 2 different "Account Models" that is also covered in Understand the EDA Account Model.

• Administrative
• Household

As part of that, the Account record-types delivered are used for two different concepts

• Containers
  • Household
  • Administrative
• Affiliated
  • University Department
  • Academic Program
  • Business Organization
  • Educational Institution
  • Sports Organization

The difference between the two "Containers" is in the modeling with Contact to 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. So why that distinction?

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.

I've been showing this as if you have to choose only one or the other but, it's possible to use both types of container accounts in the same org. There's also EDA settings to change which "record type" (custom you create) to consider as the Administrative or Household accounts.

Now, there's an Affiliation object as part of EDA where the "affiliated" record types like Educational Institution play a role. Part of this is covered in Things to Know about Container Versus Parent Accounts

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.

Now, while the difference between Administrative and Education Institution is foundational in the model concept - the difference between he "affiliated" record types can be much smaller (department vs. institution). An important feature of "affiliations" is that it removes the risk of data skew with the typical "parent" account approach (ex. All historical teachers have parent account of one Educational institution) and performance issues with changing ownership/sharing. This is covered in the Things to Know About Container Versus Parent Accounts.

In either case, with these kinds of data volumes, changing ownership or sharing for just one record can involve thousands of calculations to update records throughout the data hierarchy. All these calculations take time and can cause performance issues.

And for why you don't forgo Accounts completely if Contact is the "focus" - this is due to native behavior of the platform with regard to Account/Contact:

If you're wondering why it's non-negotiable that a Contact have either a container or parent Account, the Salesforce security model is the reason. A Contact without a parent Account is considered private, which means the Contact record is visible only to the person who created or owns the record and to admin-level users