Single-asset Fund & Portfolio editing from the building screen
Company admins can set or change the Fund and Portfolio of an individual asset directly from the building screen, restricted to a new "Manage Funds & Portfolio" admin role.
What challenge/problem does this solve for users?
Until now, when a company admin needed to change the Fund or Portfolio of a single asset, there was no way to do it from the building screen — every change had to be requested from CS, which forwarded it to the dev team. This created a constant trickle of small support tickets just to update one field, and slowed customers down when their portfolio structure shifted.
For whom is this especially valuable?
Company admins working with portfolios that change frequently — reorganising funds, moving assets between portfolios, or onboarding new buildings into existing structures.
What can the feature do?
Edit the Fund of a single asset directly on the building screen
Edit the Portfolio of a single asset directly on the building screen
Restricted to a new "Manage Funds & Portfolio" role, enabled for admins only
Bulk changes from Company Settings continue to work as before
What are the benefits?
Admins no longer have to file a support ticket for a single fund or portfolio change — they can do it themselves on the building screen in seconds. This frees up CS and engineering time and gives customers immediate control over their portfolio structure.
Building Out of Management — Deactivate and Reactivate Buildings
A clean way to mark a building as inactive when a property manager stops managing it — freezing all activity while keeping the full history accessible to authorised users.
What challenge/problem does this solve for users?
When a property manager stops managing a building, today there is no clean way to handle it. The building stays fully active (so notifications, tickets and integrations keep running for someone who shouldn't be touching it) or it gets removed entirely (so the outgoing manager loses access to the history they still need for handover). Both options cause real problems — typically for several months after a handover, when the outgoing manager still gets asked questions about prior work.
For whom is this especially valuable?
Property managers handing buildings over to other managers, and the tenants and suppliers connected to those buildings who need to understand why a previously active building is no longer accepting actions.
What can the feature do?
Deactivate a building from building settings, with a warning dialog listing every consequence before confirmation
Optionally revoke all user access in the same step, or keep users on read-only access
Hide inactive buildings from the dashboard by default, with a filter to show them when needed
Read-only access to all historical data (tickets, projects, documents, contacts, certificates) on inactive buildings
Clear message shown to tenants and suppliers explaining the building is no longer under active management
Reactivate a building later, restoring soft-deleted relations automatically
What are the benefits?
Handovers stop being a disruptive event. The outgoing manager keeps access to history for as long as they need it, the building stops generating activity it shouldn't, and tenants and suppliers see a clear explanation instead of broken or silent actions. Customers no longer need to choose between "leave it active" and "delete it forever".
Customer Success can now reset a user's password directly from the BOT user management page, removing engineering from a recurring support request.
What challenge/problem does this solve for users?
Customer Success has had no way to reset a user's password on behalf of a customer — every request had to be passed to engineering, which interrupted dev work for what should be a simple admin action. This was recurring often enough to become a noticeable support drain.
For whom is this especially valuable?
Customer Success — they can now resolve a category of recurring customer requests immediately, without escalating. Customers benefit indirectly through faster turnaround on password issues.
What can the feature do?
What are the benefits?
Faster support turnaround on password issues, less dev interruption, and one less queue for CS to wait on.
Long-Term Maintenance Plans — Round 2 of usability improvements
A second pass over the LTMP module addressing the friction points raised after the first release, captured as sub-tasks under this story.
What challenge/problem does this solve for users?
The first version of Long-Term Maintenance Plans surfaced several small but recurring friction points once customers started using it day to day. Workarounds were piling up around the edges of the module, slowing down property managers who rely on the plans for their long-term budgeting and maintenance scheduling.
For whom is this especially valuable?
Property managers and asset owners working with multi-year maintenance plans — the people in and out of the module every week.
What can the feature do?
Multiple targeted improvements to the LTMP workflow, captured as sub-tasks under this story
Smoother day-to-day management of maintenance plans
Reduced need for workarounds across the module
What are the benefits?
Property managers feel less friction when working with maintenance plans, fewer small annoyances accumulate over the course of a session, and the module behaves more predictably across common tasks.
A dramatic speed-up of the buildings dashboard (the first screen everyone sees after login), with no change to what the dashboard shows.
What challenge/problem does this solve for users?
The Buildings dashboard is the first screen everyone sees after login, and on large accounts it could take several seconds to load — sometimes up to 10. The slow load made the very first interaction of the day frustrating, and it got worse the bigger the portfolio. There was no visible change in functionality needed; the dashboard just had to be dramatically faster and lighter to keep up with growing customers.
For whom is this especially valuable?
Every user who lands on the dashboard after login — and especially users on large portfolios (hundreds of buildings, dozens of team members) who were hit hardest by the slow load times.
What can the feature do?
Dashboard loads in a fraction of the time, typically near-instant after the first load
No change in what the dashboard shows — same data, same fields, same layout
Performance now stays steady as the portfolio grows
What are the benefits?
The first screen of the day stops being a wait. Customers with large portfolios feel the biggest improvement — what used to take several seconds now happens in well under one. This also frees up platform capacity, which means smoother behaviour across the rest of the product as customer volumes grow.
Editable phone number in Company Settings
Company admins can now edit the company phone number in Company Settings, and the value flows through automatically to Work Orders.
What challenge/problem does this solve for users?
Work Orders include a phone number field, but until now there was no place anywhere in the product to fill it in. The field stayed empty on every Work Order, and customers were forced to work around it — for example by typing the phone number into the address field.
For whom is this especially valuable?
Company admins who manage their company's contact details and want the phone number to appear correctly on outgoing Work Orders. Especially clients whose suppliers expect to see a phone number on the document.
What can the feature do?
Edit the company phone number in Company Settings
Phone number flows through automatically to Work Orders
No more need to use the address field as a workaround
What are the benefits?
Work Orders carry the right contact information out of the box. Company admins keep their data tidy and don't need to invent workarounds. Suppliers receive Work Orders that look complete and professional.
Stakeholder Data Export — Multi-tab Excel from the Reports section
A new card in the Reports section that downloads a single Excel file with five tabs covering every stakeholder in the portfolio, respecting the user's building and contacts-page permissions.
What challenge/problem does this solve for users?
Customers regularly ask for a clean export of their portfolio's stakeholder data — all their companies, all their tenant and supplier contacts, and the per-building relations. Until now this only existed as a one-off built for one customer; every other request meant CS gathering the data manually. There was no self-service way for a customer to pull their own stakeholder snapshot.
For whom is this especially valuable?
Property managers and customer admins who need to share a stakeholder snapshot with their team, audit their contact data, or hand over a portfolio overview to a new colleague.
What can the feature do?
New report card in the Reports section that downloads a single Excel file
Five tabs included: All Companies, Tenant Contacts, Supplier Contacts, Suppliers per Building, Tenants per Building
The per-building tabs respect the user's building access — they only see the buildings they're allowed to
The three company-wide tabs are hidden in the export when the user lacks the "Companies/Contacts - Access the Companies and Contacts page" permission
New "environment" column added on the Suppliers per Building tab
No customisation in V1 — the user filters the resulting Excel themselves
What are the benefits?
Customers get their stakeholder data on demand without going through CS. CS stops doing the same export-by-hand for different customers. The export respects existing permissions, so what each user can download mirrors what they can already see in the platform.
Invoices Integration with Bloxs
Daily automatic import of all purchase and sales invoices from the Bloxs ERP into Proprli, with detailed line items visible on Ticketing work orders, Project Contracts, and Maintenance Contracts.
What challenge/problem does this solve for users?
Until now, invoices lived only in Bloxs and there was no way to see them inside Proprli without switching tools. Property managers had to leave the platform every time they wanted to check what had been billed against a work order, contract, or asset, and there was no single place that tied invoices back to the work that generated them.
For whom is this especially valuable?
Property managers, asset owners, and finance staff using the Bloxs ERP integration.
What can the feature do?
Automatically fetches all purchase and sales invoices from Bloxs every day at 02:00
Imports amounts, dates, references, and line items with ledger account and property
Automatically links invoices to the relevant work order, project contract, or maintenance contract
Surfaces invoices directly on the work order screen via a new endpoint
Incremental and idempotent — no duplicates, no missing data when retrying
Respects the Bloxs API rate limit with automatic throttling and graceful recovery
What are the benefits?
Users stop bouncing between Proprli and Bloxs to reconcile invoices and work. Everything is one click away on the same screen, refreshed automatically every day. Finance and operations work from the same source of truth without any manual import effort.
Maintenance Contract Integration with Bloxs
Read-only sync of Bloxs supplier contracts (and their line items) into Proprli's Maintenance Contracts module, automatically associated with existing maintenance contracts.
What challenge/problem does this solve for users?
Bloxs supplier contracts and Proprli maintenance contracts existed in two separate worlds. Users had to maintain context in both tools and re-enter the same data manually, with no easy way to cross-reference a maintenance contract in Proprli with its underlying Bloxs supplier contract.
For whom is this especially valuable?
Property managers and customer admins on Bloxs-integrated customers who manage maintenance contracts — they get the Bloxs supplier contract context inside Proprli without manual reconciliation.
What can the feature do?
Pulls supplier contracts from Bloxs via the API
Pulls all line items per supplier contract for cost breakdown visibility
Associates the imported Bloxs data with existing Proprli maintenance contracts using the agreed field mapping
Read-only and one-way — no writes back to Bloxs
Does NOT create maintenance contracts that aren't linked to an asset
What are the benefits?
Maintenance contract data stays in sync with Bloxs without manual effort. Property managers see the Bloxs context — references, line items, dates — alongside their Proprli maintenance contract record, removing the need to switch tools to confirm details.
Bloxs — Tenant Leases section in Proprli
A new Tenant Leases area inside Proprli that surfaces lease contract details, payment arrears, and invoices for Bloxs-integrated buildings, so tenants no longer need to log into Bloxs separately.
What challenge/problem does this solve for users?
Today, tenants of Bloxs-integrated customers have to log into the Bloxs portal to see their lease contract, payment status, and invoices. The Bloxs portal's ticketing experience is very limited, so the strategy is to move tenants fully onto Proprli for all interactions — but the lease information they need has to be inside Proprli for that to work.
For whom is this especially valuable?
Tenants of Bloxs-integrated customers who today juggle two portals.
What can the feature do?
Shows the tenant's lease contract details directly in Proprli
Shows the contract breakdown (item, amount excl. VAT, VAT) per line
Shows payment arrears and lease invoices
Only visible to buildings that have a Bloxs integration enabled
Data fetched live from Bloxs via the supplier API endpoints
What are the benefits?
Tenants stop needing a second login. Everything they need — tickets, chats, leases, invoices — is in one place. This unlocks the broader move of tenants off the Bloxs portal and onto Proprli, where the ticketing experience is stronger.
Better Integration Errors across all integrations
Unified, human-readable error messages and notifications across every integration (REMS, Informant, and others), plus the same notification behaviour now extended to Project Contracts.
What challenge/problem does this solve for users?
When an integration failed, users saw raw JSON error blobs that meant nothing to them. CS and customers couldn't tell whether to retry, wait, or report — and the cleaner notification behaviour that already existed for Informant tickets had not been extended to Project Contracts or other integrations.
For whom is this especially valuable?
Customer Success investigating integration issues, and property managers / admins who get notified when something fails on their behalf. Applies to all clients with an active integration.
What can the feature do?
Replaces raw JSON error messages with clear, presenter-formatted text
Same error-handling behaviour now extended to Project Contracts (was Ticketing only)
Unified naming for integration events so all integrations behave the same way
New flag on the user account showing whether they have an active integration, used to drive the right error experience
What are the benefits?
Users get error messages they can actually understand and act on. CS spends less time decoding payloads and more time fixing the underlying issue. The platform behaves consistently regardless of which integration is involved.
DataRotonde — Correct ticket transitions on updates
Updates coming from DataRotonde now trigger the correct number of ticket transitions every time — not zero, not double — so ticket statuses always match reality.
What challenge/problem does this solve for users?
Property managers and CS noticed tickets sometimes ended up in the wrong status after a DataRotonde update — either no transition fired, or two fired at once. That mismatch made it impossible to trust the ticket board at a glance and forced manual cleanup.
For whom is this especially valuable?
Customers using the DataRotonde integration whose ticket flow depends on accurate status updates.
What can the feature do?
Maps each DataRotonde update to the correct ticket transition
Prevents duplicate transitions when a single update is received
Prevents missed transitions when an update should change ticket state
What are the benefits?
Ticket statuses match what's happening in the field. CS doesn't have to manually correct mis-transitioned tickets, and the ticket board becomes a trustworthy real-time view again.
REMS — Disable "Included in guarantee" on Work Orders
The "Included in guarantee" option is hidden/disabled on Ticket Work Orders for REMS customers, since it was breaking the push to REMS.
What challenge/problem does this solve for users?
Work Orders marked with "Included in guarantee" were failing to push to REMS. CS spent time investigating push failures that ultimately traced back to this single option being incompatible with the REMS payload.
For whom is this especially valuable?
REMS-integrated customers.
What can the feature do?
What are the benefits?
Work Orders for REMS customers push cleanly to REMS every time, and CS stops chasing the same recurring failure category.
REMS — GL Account is now mandatory on Project Contracts
The "GL Account" field on Project Contract forms is now mandatory for REMS customers, with frontend validation and the red-asterisk marker.
What challenge/problem does this solve for users?
Project Contracts were saving and pushing to REMS without a GL account, which left the REMS side with incomplete data and forced manual cleanup. The "GL Account" field looked optional because it had no asterisk, even though REMS needs it.
For whom is this especially valuable?
REMS-integrated customers and their finance teams, who need every contract to land in REMS with the correct GL account assigned.
What can the feature do?
Adds the red asterisk to the GL Account field for REMS users
Blocks save when the GL Account is empty (REMS users only)
Prevents the contract from being pushed to REMS without a GL account
What are the benefits?
Contracts reach REMS complete on the first push. Finance no longer has to chase users for missing GL accounts after the fact.
Revantage — Back-office GL account lists now respected
For Revantage buildings, Proprli now shows the GL account list configured in the back office, instead of falling back to the hardcoded list.
What challenge/problem does this solve for users?
A hardcoded rule was overriding any back-office GL account list configured for Revantage. The back-office connection was being created in the database but the UI ignored it, so users on Revantage buildings saw the wrong GL accounts.
For whom is this especially valuable?
Revantage — and indirectly the CS team who could otherwise see the back-office relation in the DB but not on the screen.
What can the feature do?
Revantage buildings display the GL account list specifically linked via the back office
The back-office relation takes precedence over the legacy hardcoded fallback
Behaviour is preserved — the change is scoped to Revantage
What are the benefits?
Revantage users see the correct GL accounts on their buildings. CS can configure GL account lists via the back office and trust that the configuration takes effect.
DataRotonde — Support for multiple CompanyIDs
The DataRotonde client now accepts multiple CompanyIDs, so customers operating with scoped DataRotonde credentials can sync data for several companies under the same connection.
What challenge/problem does this solve for users?
Some DataRotonde customers receive credentials scoped to multiple CompanyIDs — but the client could only handle one at a time. That blocked correct setup for any customer whose access needed to span more than one CompanyID.
For whom is this especially valuable?
DataRotonde-integrated customers whose credentials cover multiple CompanyIDs.
What can the feature do?
Accepts multiple CompanyIDs as input to the DataRotonde client
Routes calls correctly per CompanyID under the same connection
Works seamlessly for customers with single-company credentials too
What are the benefits?
DataRotonde customers with scoped multi-company credentials can finally be set up correctly without workarounds. CS doesn't need to maintain parallel connections for the same customer.
REMS Sync — Replace null with empty strings on payload
The REMS sync payload now sends empty strings ("") instead of null for a set of fields, eliminating the data artefacts (e.g. "?") that were appearing on the REMS side.
What challenge/problem does this solve for users?
Sending null for certain REMS fields (storingscode, repdat, contactuitv, ruimte, specialismeoms, zmelddat, statoms, fase, uitvdat) caused data artefacts in REMS — most visibly a stray "?". Testing confirmed empty strings work cleanly, but the payload generation still used null in those positions.
For whom is this especially valuable?
REMS-integrated customers and the staff who read the REMS records — no more inexplicable "?" characters in fields that should be blank.
What can the feature do?
Sends "" (empty string) instead of null for the affected REMS fields
Applies to fields always null today AND fields conditionally null
Eliminates the visual artefact on the REMS side
What are the benefits?
REMS records look correct out of the box. CS stops fielding "why is there a question mark here?" tickets.