What In the Education: Cloud Data Model
This post is part of a series called "What in the Education Cloud," where we will try to demystify Salesforce's Education Cloud and share our experience and opinions on what comes with it, what doesn't, and what to do with it all.
What experience, you ask? In 18 months since its release, we're on our 12th implementation of Education Cloud, and in full transparency, not all those implementations have gone smoothly. We're one of the few implementation partners who implemented the new Education Cloud across the entire student lifecycle – recruiting, admissions, student success, advising, alumni, and advancement. Additionally, we onboarded schools onto a fully featured Student Information System built entirely on top of Education Cloud. We know this thing.
Data Model
When I first considered implementing Salesforce for my institution over a decade ago, one thing became painfully clear: the data model needed to be figured out. At the time, I spoke to over half a dozen institutions that had functioning Salesforce implementations to try and figure out what data model I should adopt. To my horror, every school I spoke with had a different architecture. Fast forward a few years, and Salesforce released Higher Education Data Architecture (HEDA, later in grand Salesforce fashion renamed to EDA) to put some guardrails around the problem. Then, in March of 2023, Salesforce released the currently new and so-far-named Education Cloud with a brand-new data model.
Enough of a history lesson?
We consistently hear that the new Education Cloud is based on 'the core.'" I can't help but think of the little green aliens from Toy Story who used to so reverently say, "The Claw." Indeed, every time I hear "built on the core," I hear the little guys say, "The Core," and feel like I need to join in.
But what is "the core"? Well, at its core (pun intended), it is the same set of data architecture and some functional pieces that power all of Salesforce's current industries offerings – health, government, insurance, automotive, etc. The promise of the core (are you doing the little green aliens with me now? You're welcome) is that we will be able to benefit from innovations achieved in some other "cloud" or take advantage of components, features, and functions that are developed elsewhere. That sounds great, but the reality is a bit more... nuanced.
If we look at the current iteration of the Education Cloud data model specifically for recruiting and admissions (https://architect.salesforce.com/diagrams/data-models/education-cloud/recruitment-and-admissions), we can see that the data model spans a whopping 55 objects. By comparison, the EDA data model had 38 objects in total (not just for R&A).
Why the object sprawl? Multiple reasons.
First, we are seeing remnants of other industries in here. While we are not familiar with other industries, there are oddities in the data model that can only be explained by this reliance on the core. There are required one-to-one relationships between objects that seem to have no purpose yet must be defined, or junction objects that appear to be unnecessary.
Second, the requirement for a Person Account and the inclusion of Person account-dependent functionality increase the number of objects that have to be populated.
Third, the R&A portion of the data model does set up the necessary base for deployment across student success, academic operations, and, further on, alumni and advancement, so the initial work necessary to enable all those other functions may seem like a lot.
In general, as one of our team members has quipped, the data model appears to have been designed by someone who got a PhD in data modeling. Yes, it may be the ultimate data modeling expression for all higher education processes, but is it the most efficient and elegant? Indeed, the object sprawl does represent an increase in implementation and maintenance complexity that may or may not be warranted.
What does it mean to you? Again, we're only discussing the data model here.
The underlying data model, specifically for recruiting and admissions, is undoubtedly very complex. The recommendations we typically provide to our clients are these:
Suppose you are set with your student advising, alumni relations, advancement, and SIS portion of your overall solution stack and only want to get Salesforce for recruiting and admissions. In that case, you do not need the complexity that Education Cloud introduces. EDA or even plain old, non-core Sales and Service Clouds are more than sufficient.
Suppose you anticipate taking advantage of Education Cloud's other offerings in student success, student advising, academic operations, alumni relations, and advancement. In that case, the investment in dealing with Education Cloud complexity will be realized as you go.
To summarize in a bullet point format (I can hear you groan: Vadim, you should have added this at the beginning),
Education Cloud introduces a much more expansive data model than previous iterations of Salesforce's offerings.
While it may represent an idealized version of a data model needed to onboard many of the processes we deal with in higher education, it does increase the complexity of the implementation and maintenance.
If you plan to expand Salesforce's use beyond recruiting and admissions to other functional areas covered by Education Cloud, the additional complexity may be worth it.
If you have no plans to use any of the delivered functionality in the Education Cloud or do not see its expansion beyond recruiting and admissions, then the data model, and by extension, the Education Cloud, may not be for you.
As always, these are just generalized thoughts and as we all know, all claims should be checked with your healthcare... I mean, implementation partner.