How Ovii Structures Campus Recruitment Through Institutions

Campus recruiting is not just a smaller version of public job distribution. The goal is not to create more traffic. The goal is to reach the right institutions, give those institutions enough context to pre-filter properly, and preserve a governed path from institution outreach to actual candidate intake.

Ovii’s implementation reflects that distinction. The campus promotion layer does not treat a college, a university, and a bootcamp as interchangeable exposure targets. It stores explicit job-to-institution relationships, tracks whether those relationships are active, and uses institution type to decide how the channel behaves.

That matters because early-career hiring often breaks when companies treat educational channels like broad top-of-funnel publishing. Volume rises, but the pre-screening logic disappears. Ovii is stronger when campus recruitment is described as institution-scoped distribution with downstream workflow controls, not as a generic post everywhere toggle.

Ovii treats campus recruitment as governed institution distribution, not as a lighter version of public job-board publishing.

A useful implementation detail is that Ovii uses one promotion model for two adjacent channels. Recruiters configure Campus Hiring for `COLLEGE` and `UNIVERSITY` institutions, and they configure Bootcamps & Training for `BOOTCAMP` and `ONLINE_PROGRAM` institutions. Both save through the same campus-promotion API and entity, but they carry different audience semantics.

That shared model is practical because the product can reuse the same storage, retrieval, and audit behavior while still preserving two distinct distribution strategies. A graduate program routed to colleges and universities is not the same as a skills-first role routed to bootcamps, even though both are institution-based channels.

The request DTO makes that split explicit. Each save can include `institutionTypes`, and the backend uses those types to decide which existing promotions to deactivate before writing the new set. That is the key reason campus and training promotions can coexist without trampling each other.

The recruiter UI does not ask someone to type institution names manually or run a free-form invitation flow. It loads an institution directory and filters that directory by institution type. The `InstitutionListService` returns institution DTOs with id, name, type, city, state, and country, and the recruiter-side channel card formats them into campus and training selections.

That matters because the distribution control is the institution selection itself. The recruiter is not saying “make this a campus role” in the abstract. They are saying “send this role to these specific institutions.”

It also means the product can keep channel intent clean. Academic institutions stay on the Campus Hiring side. Bootcamps and online programs stay on the training side. The selection list itself reinforces the product’s distinction between degree-led and skills-led outreach.

One of the strongest details in this feature is how updates are handled. When a recruiter saves a new campus audience, the backend first loads the active promotions for that job, then deactivates only the promotions whose institution types match the current request. If the request is for colleges and universities, only those active links are replaced. If the request is for bootcamps and online programs, only the training links are replaced.

The frontend mirrors that logic closely. The Campus Hiring save sends `institutionTypes: ['COLLEGE', 'UNIVERSITY']`, while the training save sends `institutionTypes: ['BOOTCAMP', 'ONLINE_PROGRAM']`. The toggle-off paths use the same type-specific deactivation behavior.

This is exactly the kind of operational detail worth explaining publicly. Without scoped replacement, one campus edit could accidentally erase a bootcamp strategy or vice versa. Ovii protects against that by treating the two audiences as siblings on one engine, not as one shared undifferentiated list.

In Ovii, saving or disabling campus promotion only affects the matching institution types, so academic and training audiences can coexist safely on the same job.

Campus Hiring is not just an institution list. The promotion record can also store `eligibilityCriteria`, and the recruiter UI exposes that field specifically on the academic campus path. That text is not there for decoration. It is there to help Training and Placement Officers understand who should be forwarded into the hiring process.

This is an important design choice because it shifts some screening work to the institution with clearer operating guidance. Instead of receiving a role and guessing which students are suitable, the campus side can read an explicit eligibility brief tied to that job promotion.

The training path deliberately behaves differently. Bootcamps & Training saves through the same model but sends `eligibilityCriteria: null`, which keeps that channel lighter and faster. The product is effectively saying that academic-campus workflows need more institution-side filtering structure than skills-partner outreach does.

The feature becomes more interesting when you follow it beyond the recruiter toggle. TPO users can fetch all active promoted jobs for their institution through dedicated campus-promotion endpoints. That response is not just a yes-or-no visibility list. The backend also calculates invited student counts from the eligibility table and applicant counts from actual job applications tied to that institution.

The campus-side UI uses those promotion records to build a jobs overview for the institution, then fetches full job details through a dedicated promoted-job endpoint. Those details include role information, company information, and eligibility criteria when present.

That means campus hiring in Ovii is not a fire-and-forget recruiter action. It becomes a real institution-side workspace where TPO users can see which jobs are live for them, inspect the job detail, upload students, and later track which students actually applied.

The student eligibility layer is one of the strongest parts of this flow. When a TPO uploads student emails for a promoted job, the backend first normalizes and deduplicates emails inside the request, validates email format, and then checks whether any registered users belong to the wrong institution. Those users are rejected from the upload even if the email itself is valid.

After that, the service checks which of the validated emails already exist for the same job and skips duplicates at the job level. New entries are written into `job_student_eligibility` with a unique `(job_id, student_email)` constraint, uploader email, uploaded timestamp, and active flag. The response reports how many students were added, how many were duplicates, how many emails were invalid, and how many belonged to the wrong institution.

That is much stronger than a casual share-by-email model. The institution can upload a batch confidently, understand what was accepted or rejected, and avoid quietly creating duplicate eligibility rows for the same job.

Ovii treats TPO student upload as a governed eligibility import: request dedupe, format validation, wrong-institution rejection, job-level dedupe, and explicit outcome counts.

Once students are eligible for a job, the campus side can retrieve that information in more than one way. A TPO can fetch raw eligible student emails for a job, or fetch full student profiles that include uploaded date plus hydrated branch, CGPA, and year details.

The profile-hydration path is worth calling out because it combines institutional and resume data instead of relying on only one source. Branch is first taken from department data when available. Year is first taken from batch membership. CGPA is read from the student resume when present, and branch or year can fall back to resume data if institutional records are missing.

Students also get a campus-job view of their own. The eligibility service can list all active eligible jobs for a specific student email, join promotion data to include campus eligibility criteria, and report whether that student has already applied. That keeps the campus workflow aligned for both the institution and the student.

The strongest trust signal appears when a student applies. The apply service does not create a detached campus-only record. It validates the student user, requires a completed student resume, fetches the job, creates or reuses a `TPO_STUDENT` candidate record, and then creates a real `JobApplicationEntity` for the job.

The application is initialized with the job-scoped `APPLIED` intake status using `ensureIntakeStatus`, which means campus applications join the same job pipeline model used elsewhere in the product. If the student has already applied, the service blocks the duplicate instead of creating another application.

From there, the workflow continues into the rest of Ovii’s hiring system. The candidate is queued for async resume scoring against the job description, and the service also publishes an embedding request for the `TPO_STUDENT` resume so the profile can participate in the public vector-search path. That is a much deeper integration story than simply collecting campus interest.

A campus application in Ovii becomes a real candidate record, a real job application, an async scoring task, and a vector-searchable resume, not a separate campus-only lead.

The access model also reinforces the product story. Recruiters, org admins, and employees can create or read campus promotions. TPO users can read campus jobs for their institution, upload eligible students, view job-level student lists, and apply to jobs through the student path.

That matters because the product is not relying on social convention to keep recruiter actions and institution actions separate. The API surface itself reflects which persona owns which part of the workflow.

This is particularly important for campus hiring, where the flow spans more than one organization boundary. The recruiter chooses the institutions. The institution decides which students to surface. The student applies. The job pipeline then absorbs that application into the main hiring workflow.

The help doc explains how to configure campus distribution. The stronger feature story is why the system is trustworthy. Ovii is not just pushing a role to campuses. It is maintaining institution-scoped promotion records, preserving separate academic and training audiences, carrying TPO-facing eligibility logic when appropriate, measuring invited and applicant counts, validating and deduplicating student uploads, and converting campus applications into the same governed hiring model used elsewhere.

That gives the feature a stronger identity than “campus jobs.” It becomes a structured institutional acquisition workflow. Recruiters can target specific educational partners. TPO teams can triage against explicit criteria. Students can apply through a real pipeline. And the resulting candidates still enter scoring, search, and downstream hiring operations.

That is the story worth publishing, because it shows Ovii is not treating campus recruitment as a side-channel. It is treating it as a first-class hiring path with its own controls and its own bridge into the rest of the platform.