In the ever-evolving universe of higher education, admissions departments are constantly reviewing the fields of information that are collected on their applications and making decisions about how best to accommodate every program’s changing needs. Perhaps the business school needs to collect a particular set of fields for its applicants. Or perhaps changing privacy laws in Europe require a modification that only affects EMEA applicants.

In many cases, admissions departments wait a whole year to submit their requested changes for the applicant portal. Any requests that are not submitted by a certain deadline must wait for the next cycle, typically many months in the future. Of course, the reason for the stringent process is that legacy software systems require extensive software development in order to accommodate the logic and complexity that typically governs the data model experience for each applicant.

But what if we could waive a wand and skip over all the software development and concrete logic that needs to be hardwired into those legacy systems? What if we could empower the operational admins (who know the rules and logic that is required for each applicant) to configure the system to accommodate those ever-changing parameters on the fly?

What would such a world look like?

Within the applicant experience (in other words, every form and field that an individual applicant sees) the operational admins would need control over the logic for the following:

  • Rendered – Which fields should be displayed to particular applicants?
  • Required – Which fields should be required of particular applicants?
  • Auto-Populated – Which fields should be auto-populated with existing CRM data for particular applicants?
  • Read-Only – Which fields should be “locked” with read-only access for particular applicants?
  • Record Selection – In the case of pick-list fields (or type-ahead search), which records from the CRM should be displayed as values in the pick list for particular applicants?

Of course, one would also want control over the label of fields (irrespective of the real CRM underscore name) and be able to insert any instructional or placeholder text.

Suffice it to say that if you have control over all the above with the ability to configure the logic based on any combination of AND/OR statements, well then Bob’s your uncle! You’ve done it. You have the power to create “the applicant portal that changes based on who is looking at it”.