What in the Education Cloud: Applicant Portal

We're continuing our "What in the Education Cloud" series of posts, where we attempt to explain what comes with Salesforce's Education Cloud, what doesn't, and what our experience and recommendations are.   

It's worth noting that this information is current as of the date of this post, the features currently available, and our current experience with the platform. If you look at this post 50 years from now, your results may vary. 

To date, we have briefly touched on the Education Cloud data model and OmniStudio.  The applicant portal is the next item up for bids. 

As we sit here in October 2024, Education Cloud comes with a singular portal that can be used for admissions, student success, academic operations, alumni, and so on, and I suppose this is the very thing that's worth addressing first. 

Experience Cloud can undoubtedly address all these constituent types within a single portal. From a technology perspective, there isn't a reason why you could not have one portal. However, different thinking could be involved in implementation and ongoing maintenance. 

For one, we always advise clients to consider where they want to manage complexity.  On the one hand, having one portal means managing only one portal. However, the tradeoff is that you would have to manage various components of the portal through audiences, navigate the turbulence of joint ownership with different units that may have different missions and priorities, and generally complicate modifications to the portal. Every time you want to change something, there will be a host of considerations to examine the impact of the change not just on your audience but on other portal users as well. 

On the other hand, while having separate portals for prospects and applicants, current students, alumni, etc., does create some technical and experiential challenges, it simplifies virtually every element of portal management.  

One of the most frequent transitions that constituents experience is the conversion from an applicant to a matriculated student.  Work always needs to be done to determine the point at which an applicant becomes a matriculated student and what it means in technical terms, but the experience in a single vs. multi-portal environment is quite different. 

In a single portal environment, the moment an applicant becomes a student, the portal elements applicable to a current or admitted student simply become visible in the same portal. By contrast, in a multi-portal environment, you would likely have a separate portal for an applicant from an admitted or current student, which means the applicant would now have to log in to a different portal to see content that is applicable to them. 

An additional point of complexity here is the fact that while you may allow the applicants to log into the applicant portal with their personal (or non-school-issued) email address, their login into a current student portal will likely use their school email and often have a single sign-on configured.  So, the tradeoff, just with this small component of this decision, is this: do you A) ask the applicant to now log into the same portal they have been using with different login credentials or B) ask the applicant to now log into an entirely different portal with different login credentials.  And these decisions, little or big, are plenty in this consideration. 

To try and round out this particular part of this monologue (umm... write-alogue?), while we see a lot of value in having a single portal for multiple constituents, the added ongoing maintenance and governance overhead may not be desirable. We'd strongly recommend considering setting up a separate portal for applicants, students, and, almost definitely, alumni. 

And then there are delivered components that come with the Education Cloud portal.  Again, at its current state (safe harbor, anyone?), it includes a combination of standard and custom LWCs and OmniStudio's Flexcards.  While standard or custom LWCs are an expected element of an Experience Cloud implementation, the OmniStudio Flexcards components come with the same warning we provided in our OmniStudio article – these are very technically sophisticated elements and will require you to have significant technical expertise on hand on maintain and expand your use of them, regularly.  If you do not have specific and significant OmniStudio-trained expertise on staff, these components should not be used. 

In summary, the portal delivered with the current version of Education Cloud provides a single point of engagement for many constituents that a typical institution interacts with regularly.  It is a well-laid-out portal with good functionality comprising many different technologies.  However, before adapting it wholesale, it is important to consider if perhaps multiple portals would be better suited for your institution, and each delivered component should be evaluated if there is not a better alternative there.  If you are already deciding to stay away from OmniStudio, My Applicants, My RFIs, My Appointments, and a few other components will not be usable. 

As always, these are just high-level observations and trends, and what's appropriate to your specific institution may vary, so consult your implementation partner (or us) before use.