Per-Building Requester Override on Work Order Templates
Admins can now configure a custom requester (including company registration number and phone number) per building in the work order document template, instead of always inheriting from the company profile.
What challenge/problem does this solve for users?
For companies that manage properties across multiple countries or legal entities - for example, one company covering both Belgium and Luxembourg - the requester on every work order was always pulled from the top-level company profile. This meant work orders for Luxembourg properties incorrectly showed Belgium as the requester, with no way to override it per building.
For whom is this especially valuable?
Property managers and admins at companies that operate across multiple countries, regions, or legal entities under a single Proprli company account, where different buildings need different requester details on printed work orders.
What can the feature do?
- Define a custom requester at building level in the work order document template setup
- Override company name, company registration number (KVK), and phone number per building
- Default to the company profile when no building-level override is set - no disruption to existing setups
- Ensure the correct requester details appear on printed work orders for every building
What are the benefits?
Work orders now show the correct legal entity and contact details for each building, making them accurate for compliance and supplier communication. Companies with multi-country portfolios no longer need to manually correct work order details before sending them out.
Remove Tenant from Unit - One-Click Unlink
A small but impactful UX fix that lets admins remove a tenant's association from a unit with a single action, without having to delete and recreate the unit.
What challenge/problem does this solve for users?
When a tenancy ended or was entered incorrectly, there was no way to simply remove the tenant from a unit. The only workaround was to delete the entire unit and recreate it from scratch - a slow, error-prone process that risked losing other data attached to the unit.
For whom is this especially valuable?
Property managers and admins who regularly update tenancy status - particularly those managing high-turnover buildings where tenant changes happen frequently.
What can the feature do?
- Remove a tenant from a unit directly from the unit record with a single remove action
- Leave the unit itself intact - no data loss, no need to recreate
- Handle both planned move-outs and data corrections cleanly
What are the benefits?
Routine tenancy updates now take seconds instead of requiring a full delete-and-rebuild. Admins can keep unit records accurate without any risk of accidentally losing other data, and the building overview stays clean and up to date.
Notes Field on Tenant Records
A free-text notes field is now available at the tenant company level within a building, giving property managers a place to record context and observations directly alongside the tenant's record.
What challenge/problem does this solve for users?
Property managers often need to store informal but important notes against a tenant - things like communication preferences, agreed exceptions, or context from previous interactions. Without a dedicated notes field, this information lived in emails or external tools and wasn't visible to anyone else accessing the tenant record in Proprli.
For whom is this especially valuable?
Property managers who deal with the same tenants over time and need shared, visible context on the tenant record - especially useful in teams where multiple people manage the same building.
What can the feature do?
- Add free-text notes to a tenant's company record within a building
- Store and display notes alongside all other tenant details
- Follow the same familiar pattern already in use on supplier and maintenance records
What are the benefits?
Tenant context stays in Proprli where it's visible to the whole team, instead of being scattered across emails and spreadsheets. Less time spent chasing down background information before a call or meeting, and a more complete picture of each tenant relationship in one place.
Persistent Filters on the Projects Dashboard
The Projects Dashboard now remembers each user's last-applied filters, so they're automatically restored every time the user returns to the page.
What challenge/problem does this solve for users?
Every time a user navigated away from the Projects Dashboard and came back - whether to open a project, check another module, or return after a break - all their filters reset to default. Users who
work with a specific subset of projects (by building, status, or responsible person) had to reapply their filters from scratch on every visit.
For whom is this especially valuable?
Project managers and property managers who check the Projects Dashboard multiple times a day and consistently work with a filtered view - for example, tracking only active projects in a specific building or assigned to their team.
What can the feature do?
- Remember the last-applied filter selection per user across sessions
- Restore those filters automatically when the user returns to the Projects Dashboard
- Follow the same persistence pattern already in use on the Buildings, LTMP, and Certificates dashboards
What are the benefits?
Users no longer lose their view every time they navigate away. The dashboard opens exactly where they left it, saving repeated clicks and keeping focus on the right subset of work. It's a small change with a meaningful daily impact for anyone who uses the Projects Dashboard regularly.
Configurable Sealed Bid Process via BOT
CS can now enable or disable the Sealed Bid Process per company directly in the Back Office Tool, giving clients control over whether submitted bids in a tender are hidden from each other until the deadline passes.
What challenge/problem does this solve for users?
The Sealed Bid Process was previously hardcoded - whenever multiple bidders were included in a tender, no one could view any submitted bid until the deadline had passed. For clients like Keij & Stefels who don't need or want this restriction, there was no way to turn it off. This was actively blocking their tendering workflow and forcing them to manage bids outside of Proprli via email - exactly the kind of fragmentation the platform is meant to eliminate.
For whom is this especially valuable?
Clients who make heavy use of the Projects and Tender features and run tender processes that don't require sealed bids. CS teams who need to configure tendering behaviour per client without requiring a code change.
What can the feature do?
- Enable or disable the Sealed Bid Process per company from the Back Office Tool
- When disabled, users can view submitted bids on a tender even before the deadline - keeping the full workflow inside Proprli
- When enabled (default), the existing behaviour is preserved - bids remain hidden until the deadline passes
What are the benefits?
Clients who don't need sealed bids can now manage their entire tender process inside Proprli, with no need to fall back to email. CS can configure this per client in minutes, without involving engineering. The change keeps the platform flexible enough to support different tendering workflows without compromising clients who do rely on the sealed process.