Constructor University needed to replace a legacy student-housing system, but replacing old software with another isolated database would only create a new problem.
Constructor University already relied on Salesforce for student information. Booking Ninjas worked with that existing environment so housing could become another connected part of the student's university record.
The project brought together housing reservations, student self-service, allocation rules, payments, operational data, and reporting around the Salesforce foundation Constructor already trusted.
The challenge: housing touched much more than room availability
Constructor was moving away from its former housing system, Mercury.
That meant existing properties, student contacts, reservations, housing history, and operational processes had to be considered as part of the transition.
But housing itself was also more complicated than assigning an empty room.
- Student records
- Housing preferences
- Room eligibility
- Reservations
- Deposits and payments
- Room allocation
- Residential Life reporting
- Check-in and checkout
Freshers and returning students could follow different paths. Some room types had different eligibility rules. Housing teams needed changing reports. Students needed a usable way to complete their part of the process.
The most important decision: keep Salesforce as the student-data foundation
Constructor already had its own Salesforce environment and established student records.
An early concern was whether the new housing platform would create a separate custom data structure that would then need another integration back to the university.
Booking Ninjas instead worked with Constructor's existing Salesforce Contact and Person Account structure.
Housing information could remain connected to student records already used elsewhere in the university, and authorised teams could access relevant information without every user needing to work inside the Booking Ninjas application itself.
That addressed one of the clearest concerns raised during the project: housing did not need to become another data island.
Booking Ninjas explains this wider structure in What Is a Salesforce Org?
The student housing journey could become one connected flow
The useful experience starts with the student record and continues through the housing lifecycle.
Start from the student information Constructor already maintains in Salesforce.
Give the student a branded housing entry point with the information and actions relevant to them.
Student status, preferences, room type, and applicable requirements shape the next step.
The reservation can follow the payment or approval rule that applies to that student.
The housing record remains available for assignments, Residential Life, reporting, and later lifecycle work.
How the Constructor setup fit together
| Constructor need | Booking Ninjas approach | What it made possible |
|---|---|---|
| Replace legacy housing data | Salesforce-native migration structure | Properties, contacts, reservations, and relevant historical data could move toward the new environment instead of starting with an empty housing system. |
| Keep existing student records | Existing Salesforce Contact / Person Account structure | Housing could work around the university's established student information instead of creating another independent student database. |
| Give students self-service | Student Portal | Students could receive access to a Constructor-branded environment and complete relevant parts of the housing journey themselves. |
| Apply different housing rules | Reservation rules + Salesforce workflows | Freshers, returning students, room types, preferences, and other student attributes could influence the process shown to the student. |
| Handle housing deposits | Payment Processing | Applicable payment activity could remain connected to the student and reservation rather than being reconciled separately. |
| Keep incomplete reservations usable | Reservation status + payment workflow | A student could return to an outstanding step instead of having to rebuild the housing request from the beginning. |
| Support changing reports | Salesforce Reports + Dashboards | Residential Life could build different views around buildings, rooms, occupancy, student attributes, or assignments from the same data. |
Students could handle more of the housing journey themselves
Constructor needed more than an administrative housing screen.
Students also needed a clear place to interact with the process.
Booking Ninjas configured a branded Student Portal where student access could be connected to the university's housing workflow.
The portal could become the place where students see the housing information relevant to them, maintain applicable preferences, continue reservation steps, and complete actions such as an applicable housing payment.
That moves routine work closer to the person who already knows the answer.
Booking Ninjas' current Student Portal keeps student self-service directly connected to Salesforce records rather than maintaining another copy of the student outside the platform.
University housing rules could become part of the workflow
Constructor did not have one identical housing process for every student.
Freshers and returning students could have different requirements. Certain room types could have different eligibility. Student preferences and existing university information could also affect what needed to happen next.
Instead of asking staff to remember and explain every variation manually, Salesforce data and Booking Ninjas workflows could help determine the appropriate housing path.
The project also explored deeper allocation requirements such as room preferences, floor preferences, nationality, smoking preferences, roommate considerations, and controlled inventory behaviour.
Those advanced matching and allocation ideas should be understood as areas Constructor and Booking Ninjas were defining and refining during implementation, rather than all being presented as confirmed production functionality.
Payment could become part of the reservation state
Constructor also had different financial paths depending on the student.
For example, returning students could need a housing deposit while freshers could follow another process.
Booking Ninjas worked on connecting Stripe payment activity with the student and reservation so an applicable payment could become part of the housing workflow itself.
That creates a much clearer sequence:
The same structure also helps with students who begin the reservation but do not complete payment immediately. The reservation can retain its state so the student can return to the outstanding step rather than start again.
Booking Ninjas' current payment tools similarly connect transactions directly with bookings, invoices, and Salesforce customer records. :contentReference[oaicite:3]{index=3}
Residential Life did not want to wait for a software vendor every time it needed a new report
University housing questions change constantly.
One person may need students in a particular building. Another may need occupancy. Another may need minors, nationality information, room assignments, or other student attributes.
Constructor's team made clear that a fixed list of reports would not be enough.
Because the housing records remained in Salesforce, authorised teams could use Salesforce reporting and permitted exports to answer different questions from the same underlying data.
- Buildings and rooms
- Student assignments
- Occupancy
- Student attributes
- Reservation status
- Payment status
- Housing exceptions
- Operational exports
Real users kept shaping the system
User acceptance testing exposed the details that matter when software reaches daily university operations.
Constructor and Booking Ninjas worked through questions around student types, room eligibility, reservation states, payment behaviour, reports, preferences, inventory, terminology, and housing lifecycle work.
The team also explored how checkout and room inspection could become more structured, including identifying exceptions and reducing the amount of manual processing required for normal end-of-year departures.
Some of those advanced workflows were still being defined, but that implementation process itself showed how Constructor's version of the platform could continue to take shape around real housing operations.
What became more connected for Constructor
We do not have verified numerical post-launch results for this story, so the value is best shown through the work Booking Ninjas connected and the manual handoffs the system was designed to reduce.
The university did not need to treat housing as an entirely separate student-information environment.
The housing journey could move through a branded portal instead of depending only on staff instructions and manual follow-up.
Student status and other Salesforce information could help determine which housing process applied.
Applicable housing deposits could become part of the same reservation history instead of another disconnected check.
Salesforce reporting gave Residential Life more flexibility than relying only on a fixed vendor report library.
Real UAT scenarios could feed back into configuration rather than forcing Constructor to accept one fixed housing process.
Their university. Their students. Their housing rules. Their org.
Constructor University is a particularly clear example of the Booking Ninjas Salesforce-native model.
The university already had an org, student records, fields, permissions, reports, and data relationships.
Booking Ninjas did not need to ask the university to throw away that foundation in order to modernise housing.
Instead, housing could become another operating layer inside the same broader environment.
That is also how Booking Ninjas describes the current Student Housing platform: student, room, bed, assignment, payment, maintenance, and operational information can stay centralised in Salesforce.
A housing reservation can become the start of a wider residential workflow
Reservation Management can provide the core housing record.
Around it, a university can connect student portals, availability, room and bed assignments, payments, reporting, maintenance, check-in, checkout, communication, and other Residential Life workflows as needed.
Constructor needed a richer setup because its housing operation already touched many parts of the university.
A smaller residence can start with fewer pieces.
The useful point is that both can use the same Salesforce foundation without forcing every institution into the same housing process.
For the wider use case, see the Student Housing solution .
Learn more about this student housing setup
See how student self-service can stay directly connected to Salesforce data, permissions, billing, and university workflows.
Explore Student Portal →See how records, workflows, users, reporting, automation, and other operational tools can live in one organisation-specific environment.
What Is a Salesforce Org? →See how reservations, policy rules, availability, changes, and operational reporting can remain connected inside Salesforce.
Explore Reservation Management →About this story: This page reflects Constructor University's Booking Ninjas implementation and user-acceptance-testing material, including legacy migration, Salesforce student records, housing reservations, portal self-service, payment workflows, reporting, and housing-rule configuration. Advanced roommate matching, controlled overbooking, and inspection workflows are described only as areas explored or refined during implementation unless later production evidence confirms their final deployment.
Modernise student housing without creating another student database.
See how Booking Ninjas can connect reservations, rooms, students, payments, portals, reporting, and Residential Life workflows around the Salesforce environment your institution already uses.
.jpeg)
.jpg)
.png)
