OQL View entities are one of those Mendix features that don't get enough attention, until you hit a performance wall that nothing else can fix.

They let you move complex logic out of microflows and into the database, turning slow apps into fast ones. But they come with trade-offs: you're writing OQL instead of visual flows, and you need to understand when the technique actually makes sense.

We recently used OQL View Entities to fix a dashboard that was taking 25 seconds to load. By pushing complex calculations and joins towards the database, we brought it down to 1.5 seconds.

In this blog, we’ll talk about what we did, why it worked, and when you should consider using OQL View Entities for your own performance problems.

The problem: a slow Mendix dashboard

The client needed a way to track employee absences and schedule well-being interviews. Requirements: show interviews for each manager's team, let them take action based on status and responsibility, and handle complex organizational hierarchies.

The first version used microflows to calculate everything per row: retrieve employees, check managers, compare users, determine which buttons to show. The logic made sense, the code was clean, but with 10,000+ interviews in production, suddenly it took 20-25 seconds to load.

Why it was slow: multiple issues compounding

When we analyzed the implementation, we found several performance problems working together:

Domain model: Calculated attributes for determining responsibility and action types, plus Before Commit flows for data validation.

Microflows: Per-row logic retrieving employees, navigating deep associations, calculating button states, for every single row, every page load.

Client-side: A microflow data source loading everything upfront and running calculations in the browser.

XPath: Deep association paths for authorization (manager → manager+1 → region), with filtering logic that couldn't leverage indexes.

Each problem made the others worse. We needed to rethink where the logic should live.

The solution for slow Mendix apps: OQL View Entities

The core problem was simple: every row triggered separate calculations in microflows. For 10,000 rows, that meant at least 10,000 calculations: retrieve the employee, check their manager and their manager, compare the current user and decide which user actions were allowed. The application layer was drowning.

OQL View Entities let us flip that around. Instead of calculating per row in the application, we moved the logic into the database. The database did the work once, returned the results, and the client just displayed them.

This is what we changed:

1. Responsibility logic. Some interviews need to be handled by a direct manager. Others need escalation to the manager's manager (what the client called "manager+1" in their org structure). We wrote conditional logic using subqueries and CASE-WHEN structures in OQL that calculated which person was responsible to handle the interview, if the attendance of the current user was required, etc. The database figured it out when the view was queried. No need for microflows or per-row calculation.

2. Action button logic. Should the button say "Plan", "Conduct", or "Details"? That depended on the interview status and whether a plan date existed. We calculated it as a database field using subqueries and CASE-WHEN structures.

3. Single query. All of this happened in one database round-trip. The database did the joins, the calculations, the filtering and returned clean results. The client  just displayed them.

The result: load time dropping from 25 seconds to 1.5 seconds

Load time dropped from 25 seconds to 1.5 seconds.

We kept the functionality intact and all the data visible, but we had to trade Mendix's visual modeling for raw OQL. The team had to learn OQL syntax they'd never used before.

Was it worth it? Absolutely. Managers started scheduling interviews directly from the dashboard and adoption went up because the tool finally felt fast enough to trust.

When to use OQL View Entities in Mendix

OQL View Entities solved this specific problem brilliantly, but they're not appropriate for every situation.

Use them when:

  • ✅ You have complex dashboards with heavy per-row calculations
  • ✅ It's a read-heavy scenario where data doesn't change constantly
  • ✅ You need to pre-aggregate or pre-join data for performance

Don't use them when:

  • ❌ Simple lists already perform fine with standard XPath and microflows
  • ❌ Users need highly dynamic filtering that changes frequently
  • ❌ Your team lacks SQL/OQL knowledge to maintain the queries
  • ❌ The logic is too complex to express cleanly in OQL

The trade-offs

OQL View Entities solve specific problems really well, but they're not without downsides.

Complexity. Writing OQL is closer to traditional database work than visual modeling. Your team needs OQL knowledge to maintain it—and not everyone on a low-code team has that background.

Security risk. Entity access rules don't carry over from source entities. You have to manually replicate security logic in the view. If you miss something, you might accidentally expose data to users who shouldn't see it.

Domain model clutter. Every view becomes a new "entity" in your model. Create too many, and your domain model gets harder to navigate. We've seen projects with 20+ views that slowed down onboarding for new developers.

For this project, those trade-offs made sense. The dashboard actually worked, and that mattered more than sticking to pure low-code principles. But we've also seen cases where simpler fixes, better indexes, smarter XPath, task queues, solved the problem without adding this level of complexity.

The key is knowing when you're dealing with a problem that genuinely needs this approach, versus when you're reaching for advanced tools too early.

Want help with your Mendix performance?

Dealing with slow dashboards or frustrated users? We've solved this before.  We know what to look for and how to fix it without rewriting your whole app.

Let’s get in touch