All Collections
Data management
The class overview and the application overview
What’s the difference between a class overview and an application overview?
What’s the difference between a class overview and an application overview?

Learn what each overview has to offer and where to go for what

Cláudia Duarte avatar
Written by Cláudia Duarte
Updated over a week ago

In articles and elsewhere, we often point out that data management is incredibly important today and FULL FABRIC’s very raison d'être; that part of our mission is to be the premier solution for a first-rate admissions experience for both staff and applicants. Naturally, this includes, but is not limited to, having to curate the applications you receive on a mass scale and the classes offered through your school’s programmes, which is why we have the application overview and the class overview. 🎓

Usually, this is the moment you go: “Say what? Did I catch that right?”, because you weren't expecting the place where you manage an intake to be separate from where you manage its applications. 🤨 That’s understandable – however, what seems obvious isn’t necessarily the best business practice, and thus we’re journeying into the heart of FULL FABRIC to explain the question that forms the title of this article:

What’s the difference between a class overview and an application overview and why are they separate?

On a fundamental level, both application templates and classes have their own dedicated areas from which to retrieve, analyse and manipulate information, because they’re different beasts, although there’s an area of overlap.

The class overview, quoting from the linked article, is "the place where you can manage a profile's educational cycle in the context of a specific class, be that profile a prospect, an applicant, a student or an alumnus". Its primary focus is managing people, particularly to move them down the funnel, like a sort of lifeline to reach outwards. 🔗 To help with this, since information is power, it's possible to pull and display relevant data of a general nature, such as the entries from the profile Info tab.

TIP: To access the class overview, click Programmes on the sidebar and select a programme and class.

As for the application overview, that's where you can find all of the information proceeding from the application template associated to a class, more explicitly, every section and every field in the template. That's because, and this is crucial to note, the data here is directly sourced from the started and submitted applications, meaning that the personal details filled out by candidates on their application forms live there. Thence, the main draw of the application overview is the ability to access a given template and then probe and export the resulting applications.

TIP: To access the application overview, click Applications on the sidebar and select a template.

Knowing precisely how these overviews differ, you can perhaps guess why they're split: namely, that while every class must have one application template, the same template can be simultaneously assigned to several classes, like a full-time MBA and a part-time MBA. Aha! 💥 This isn't just a matter of how the portal is built, it's actually a best-practice concept to centralise homologous data, as centralisation makes applications easier and faster to coordinate, keep clean and regard in a holistic manner.

Sidetracking a bit to reflect on this topic, the underlying premise is that classes exist which are nearly identical, if not entirely so. Take a programme with a part-time and a full-time track, or a daytime and nighttime track, or an online distance learning option, for example. It makes sense to divide the intakes due to the inevitable managerial divergencies such as class end date, among others (e.g., a full-time class will finish much earlier than a part-time class, but that's just the tip of the iceberg). Yet, when it comes to taking applications, the questions and criteria are exactly the same, because it's still the same programme, and the classes are simply two parts of a whole. Using the same application template allows for a smoother workflow, because every application you receive will be up for review in a single application overview. 🤩

And there you have it! 😉

But I really need the ability to view applications in the class overview. Is there any way to do so?

Before wondering if you can, it's important to ask if you should. Considering that the overviews serve distinct functional roles (as described above) that come in handy at different stages and sometimes even involve different staff teams, the persistent belief that you need to mix "apples and oranges" may stem from lingering confusion or deep-rooted habits which aren't necessarily the most efficient. 🍏🍊 As such, please consult with us for guidance. ❤️

That said, cutting straight to the bone, it's not possible to display fields from an application template on the profile list of the class overview, but the tabs All applications and Associated applications present a splendid alternative! ✨

If you're not aware already, these tabs exist as quick routes to the profiles in a class that have started or submitted applications: as the name suggests, All applications is a complete round-up of profiles with applications, whereas Associated applications gathers only those profiles that originally submitted an application to another class but reused the same form to apply to this class as well.

Then, to the right of each profile row you'll find two game-changing shortcuts: the checklist icon, which takes you right to the application form, and the PDF icon, which prompts a download window.

Furthermore, you can also filter profiles by lifecycle state and other filtering options. In fact, you can even save views – groups of your favourite filters and columns intended to make repeated utilisations faster and easier! Just bear in mind that if the number of RECORDS FOUND in the profile list is too low, it's probably because you have filters on that you forgot to deselect. 😄

If an application overview contains application forms from multiple classes, how do I tell which is which?

There are two methods to trace the provenance of an application: adding a column with that information or filtering the list by programme and class.

To add a column:

     1) On the search list bar open the column selector (it's the three-striped icon)
​     2) Look for the Programme-type field and pick it

The column will be duly added to the list:

To filter the list:

     1) On the search list bar invoke the segments builder (it's the inverted triangle icon)
     2) Click Add new rule
​     3) Apply the rule: "(name of the Programme-type field) ⇢ is equal to ⇢ (choose value/s)" (hold CTRL/CMD to multi-select)
​     4) Hit Done

TIP: Templates that are shared across multiple classes require a Programme choice field for the applicant to choose an intake, and that's the one you need to set your sights on. For reference, here's how it looks on the application template schema:

Why is there a mismatch between the numbers in the class overview and the numbers in the application overview?

The reason why inconsistencies come about is that the widget in the class overview renders the lifecycle states of profiles (notably, applicant::started application and applicant::submitted) and the widget in the application overview renders the status of applications (i.e., them being STARTED or SUBMITTED).

The profile lifecycle states are profiles’ current location in the successive junctures of the recruitment and academic cycle of a class (e.g., prospect::cold, prospect::engaged, applicant::started application, and so on). The states themselves are unique to every school, as they’re defined by staff to adequately fit their admissions process. Likewise, staff maintains control over the lifecycle states all the way; so while the system automatically changes a profile to applicant::submitted upon the submission of an application, and other workflows can be designed to automatically update the lifecycle states of users, staff can manually alter said states to something else at any moment.

The status of applications is a system-generated report of whether an application has been started or submitted, regardless of the profile's state and substate. In other words, it's not influenced by the latter, and it can't be edited by staff (except by unsubmitting a submitted application).

Since profiles' lifecycle states are left at staff's discretion, discrepancies may ensue. Likewise if the same application template is associated to more than one class.

*

🎊 Ta-daah, you've reached the end of this article! 🎉 Congratulations, you're one step closer to mastering FULL FABRIC! ⚡️⚡️

If you have any questions or comments on the topic at hand, or if you enjoy reads like this and have article requests, feel free to start a chat or email us at support@fullfabric.com. Also, please leave a rating down below. Your feedback is highly appreciated! 💖

_________________

PUBLISHED: July 25, 2019
LAST UPDATED: July 25, 2019 at 8:57 p.m.

Did this answer your question?