Why building a unified student record is the technical foundation that every personalisation, analytics, and AI ambition in higher education recruitment depends on.

Higher education has a data problem that is both well understood and persistently unsolved. Institutions have been grappling with fragmented data for a long time. Data is housed across departments and platforms, making it nearly impossible to compile a holistic view of the institution and its student body. The admissions team holds application data. The events team holds open day registrations. Marketing holds email engagement. Student records holds the academic history. None of these systems were designed to talk to each other, and for most universities, they still do not. Shape Software

The consequence is not just operational inefficiency. It is a recruitment strategy built on an incomplete picture of every prospective student in the pipeline. Without a unified view, personalisation is impossible at scale, analytics are unreliable, and the AI-driven engagement tools that universities are now investing in have no coherent data foundation to work from.

Building a 360° student view is the architectural prerequisite for all of it. This article covers what that architecture actually looks like, why it is harder than it sounds, and what the technology components behind it need to do.

Why Fragmentation Is the Default, Not the Exception

Many institutions still rely on legacy systems that do not integrate well with modern software, leading to data incompatibility and manual data transfers. Without a defined data governance framework, institutions struggle to establish policies for data sharing, security, and standardisation. The systems accumulate over years and procurement cycles, each solving a specific operational problem without reference to the broader data landscape. HubSpot

A typical UK university managing student recruitment might be running a student records system (Banner or Colleague), a separate admissions management tool, an event management and engagement platform like Gecko, a marketing automation platform, an agent management portal, and possibly a clearing hotline system. Each holds a piece of the student story. None holds the whole.

Each system serves its own distinct purpose, and a lack of integration among them often leads to duplicated efforts, inconsistent reporting, and missed opportunities. When a recruitment officer wants to understand a prospective student's full journey, they are piecing it together from multiple screens, multiple logins, and multiple data exports that may not even share a common identifier. Dynamics Square

The 360° student view solves this by creating a single governed record that aggregates all of that data, enriches it in real time, and makes it available to every system and every user that needs it.

What a 360° Student Record Actually Contains

The term is used loosely. Before building the architecture, it is worth being precise about what a complete student record must hold and where each data type originates.

Identity and contact data is the foundation: name, contact details, address, preferred language, nationality, and the unique identifiers used to link this record to Banner or any other authoritative system. This layer must have a defined source of truth. In most UK universities using Banner, Banner owns the authoritative identity record. The CRM consumes it, does not overwrite it.

Academic intent data captures what the student is interested in studying: course preferences, level of study, entry year, campus preferences, and any scholarship or funding interests. This data comes from inquiry forms, open day registrations, UCAS inquiry feeds, and agent referrals. It evolves as the student's interest develops and must be timestamped to show how intent changes over time.

Engagement history is where the analytical value concentrates. Every email opened, every link clicked, every event attended, every chatbot interaction, every page visited on the university website: this is the behavioural record that distinguishes an actively engaged prospect from a dormant one. It is also the data that feeds lead scoring models, journey automation triggers, and AI-driven next-best-action recommendations.

Application and progression status links the prospect record to their formal application: UCAS application reference, application status, decision type, offer conditions, and deposit status. This data typically originates in Banner or the admissions system and is consumed by the CRM to contextualise the engagement record.

Consent and preference data records the legal basis under which each category of communication is being sent, the channels to which the student has consented, and the timestamp and source of that consent. This is not optional metadata: under UK GDPR it is a first-class data attribute that governs every campaign the institution sends.

The Data Model Challenge: One Person, Many Records

The most technically demanding aspect of building a 360° view in higher education is not the integration. It is the data model. A university student is not a simple contact record. The same individual may:

• Enquire about an undergraduate course in Year 12, then return two years later as a postgraduate prospect

• Apply to multiple courses in the same cycle under a single UCAS application

• Defer their entry and re-enter the recruitment cycle the following year

• Be known to Banner under one identifier and to Gecko under a different email address

A generic CRM data model, built for a one-contact-to-one-opportunity structure, cannot represent this complexity without significant customisation. The data model must support one unified contact record mapped to multiple applications, across multiple cycles, linked to multiple course interests, with engagement history spanning potentially several years.

Microsoft Dynamics 365 built on Dataverse provides the entity framework to accommodate this. Microsoft Dataverse aims to help customers eliminate data silos, enable powerful insights, and act on their data. The Dynamics 365 Education Accelerator extends the standard Dataverse model with higher education-specific entities including learner records, programme enrolments, and academic history, providing a structured foundation that implementation partners configure to match each institution's specific operational reality. EdVisorly

Getting this data model right before any configuration begins is the single most consequential decision in a HE CRM implementation. A data model that cannot represent the institution's actual recruitment structure will produce a 360° view that is technically complete but operationally misleading.

The Integration Architecture: What Must Connect and How

A 360° view is only as good as the integrations that feed it. The following are the core system connections that a modern HE CRM architecture must manage.

Banner (or equivalent SIS) integration is the most critical and the most complex. Banner must remain the source of truth for applicant identity and academic data. The integration pattern should be event-driven rather than batch-scheduled: when a status change occurs in Banner, the CRM is updated in near real time rather than waiting for a nightly sync. Write-back from the CRM to Banner must be governed: a proposed change in the CRM triggers a review workflow before it is applied to the authoritative record. This protects data integrity at the boundary between systems.

Event management integration (typically Gecko) feeds open day registrations, session attendance, and event interaction data into the student engagement record. The integration must pass not just registration status but the full relational structure: which event, which session, whether attendance was confirmed, and any post-event interaction. Attendance at a specific subject taster session is analytically different from a general open day visit and must be recorded as such.

Marketing automation integration is increasingly native in platforms like Dynamics 365 Customer Insights, where the CRM and the campaign engine share the same data layer. Where a separate marketing platform is used, the integration must pass campaign engagement data (sends, opens, clicks, unsubscribes) back into the student record in real time to keep the engagement score current.

UCAS inquiry feed integration provides early-cycle prospect data from UCAS's matching service, enabling universities to identify prospective students before they have directly enquired. This data enters the CRM as a prospect record and is enriched as subsequent interactions occur.

Azure Integration Services (Logic Apps, Service Bus, API Management) provides the middleware layer that orchestrates all of these connections: managing authentication, handling retry logic, transforming data formats between source and target schemas, and providing the audit trail that compliance and governance require.

Real-Time Deduplication: The Problem That Never Goes Away

A 360° view fails the moment the same student exists as two separate records. Deduplication is not a one-time migration exercise. It is an ongoing architectural requirement.

Duplicate records arise continuously in a live recruitment environment. A student who enquires via a university website, registers for an open day through Gecko using a different email address, and then submits a UCAS application under their formal name may generate three separate records across three systems before the integration logic catches the overlap.

The deduplication architecture must operate at multiple points: at data entry (real-time duplicate detection when a new record is created), at integration boundaries (matching incoming records from Banner or Gecko against existing CRM contacts before creating new ones), and as a background process (running fuzzy matching across the existing database to identify and resolve historical duplicates). The matching logic must work across multiple attributes simultaneously: name, email, date of birth, postcode, and phone number, using a scored threshold rather than an exact match, because real-world student data is rarely perfectly consistent across systems.

UTM Attribution and the Source-of-Enrolment Question

One of the most valuable analytical questions a recruitment operation can answer is: which channel, campaign, or touchpoint influenced a student's decision to apply? Without source attribution built into the data model from the start, the answer is unavailable, and marketing budget allocation is essentially guesswork.

UTM parameter capture at the point of enquiry, linked to the student record and preserved through the application journey, provides the foundation for attribution analysis. When a student clicks a paid search ad, lands on a course page, and submits an inquiry form, the UTM parameters from that click should be captured in the CRM inquiry record and retained even as the contact progresses through the funnel. This is not a complex technical implementation, but it is one that must be designed into the data model explicitly: UTM fields on the inquiry entity, capture logic in the web form integration, and reporting in Power BI that joins inquiry source to application outcome.

The Analytics Layer: From Data to Intelligence

By creating a 360-degree profile of each applicant and centralising multi-channel communications, a CRM enables the highly personalised engagement that today's students expect. But the profile alone is not enough. The intelligence that acts on it requires an analytics layer that surfaces actionable signals rather than raw data. WinPure

Engagement scoring aggregates interaction history into a single numeric indicator of conversion likelihood. A student who has attended two open days, clicked on three subject-specific emails, and visited the accommodation pages multiple times scores materially higher than a student who received the same emails and never engaged. This score drives segmentation, journey automation, and the prioritisation of recruitment officer call lists.

Disengagement detection is the inverse: identifying prospects who were previously active but have gone quiet, flagging them for re-engagement before they drop out of the funnel entirely. The signal is not the absence of activity; it is the contrast between prior engagement and recent inactivity.

Power BI sits on top of the Dynamics 365 data layer to surface both operational dashboards (funnel metrics, campaign performance, event attendance) and strategic analytics (source attribution, cycle-on-cycle comparison, yield rate by course and geography). The key architectural requirement is that Power BI reads from the CRM's Dataverse tables directly, not from a separate data export, so that the analytics always reflect the current state of the student record.

What the Architecture Enables That Fragmentation Cannot

The practical difference between a fragmented data environment and a properly architected 360° view is visible in specific operational scenarios.

A recruitment officer preparing for a call with an undecided offer holder can see, in a single screen: the courses they applied for, the open days they attended, the emails they engaged with most, the scholarship pages they visited, the last communication they received and whether they opened it. That conversation can be targeted and relevant rather than generic. The offer holder's experience of the institution is one of an organisation that knows them, not one that is starting from scratch.

A marketing manager planning the next campaign cycle can segment the prospect database by engagement score, course interest, source channel, and application status simultaneously, and exclude anyone who has already accepted an offer elsewhere. The campaign is built on data, not assumptions.

And when a student submits an erasure request under UK GDPR, the data governance layer of the architecture knows exactly where that individual's data exists across every integrated system, and can execute the suppression and deletion workflow reliably rather than asking staff to manually check four separate platforms.

In Summary

A 360° student view is not a feature that a CRM vendor switches on. It is an architecture that must be designed: the right data model for HE complexity, governed integrations that maintain Banner as the source of truth, real-time deduplication across system boundaries, engagement scoring built on a complete behavioural record, and analytics that connect campaign activity to enrolment outcomes.

The institutions that build this architecture correctly gain a compounding advantage. Every recruitment cycle adds more data, produces more accurate scoring models, and enables more precise personalisation. The gap between those institutions and those still operating on fragmented systems widens with each year.

The data already exists in most universities. The work is in connecting it, governing it, and building the intelligence layer that turns it from a compliance burden into a competitive advantage.

ABOUT VE3

VE3 is a global technology and enterprise AI consultancy specialising in Microsoft Dynamics 365 student recruitment engagement hubs for higher education. We design and implement the full architecture: Dataverse data models, Banner and Gecko integration, real-time deduplication, UTM attribution, engagement scoring, and Power BI analytics, all hosted on UK Azure infrastructure and governed to UK GDPR standards from day one.