Getting Started with Mendix: What I Wish I Knew in My First Few Projects

When I first started using Mendix, I was amazed at how quickly I could build and deploy applications. But as I dove deeper, I ran into issues that slowed me down. Looking back, there are a few things I really wish I had known early on.

Whether you’re just starting your Mendix journey or gearing up for your first few projects, these tips can help you build cleaner, more scalable apps — and avoid some of the growing pains I went through.

Think Long-Term When Naming Your Entities and Microflows

When you're just starting out in Mendix, naming might feel like a minor detail. But trust me poor naming conventions can snowball into a real mess down the line, especially when your app scales or when someone else (or future you) has to maintain it.

Here’s what I wish I had known early on:

Use Consistent Naming Conventions

Names are the first and most important form of documentation in Mendix. The official guidelines emphasize clarity and structure — and for good reason. Think of your app as a team sport: the more consistent your naming, the easier it is for everyone to stay on the same page.

• Modules should use UpperCamelCase and describe functionality clearly, like UserManagement or CommunicationsAndInteractions.

• Entities represent real-world objects, so names like Customer or Product work best. Avoid plural forms (Orders) or abbreviations (Prod, Cust).

• Attributes should follow the same pattern: FirstName, OrderTotal, etc. Only use an underscore (_) for purely technical attributes (e.g., _HasBeenSynced)

Microflow Naming Made Easy

Microflows often become the brain of your application logic, so make sure their names reflect what they actually do. A good format to follow is: {PREFIX}_{Entity}_{Action}

For example:

• ACT_Product_Create

• ACT_Order_GenerateInvoice

• ACT_Section_Delete

Mendix even has a set of standard prefixes based on the purpose:

• ACT_ for action buttons

• DS_ for data sources

• VAL_ for validations

• SUB_ for sub-microflows

• ACO_/BCO_ for entity event handlers (After/Before Commit)

These prefixes aren’t just for show they make debugging, refactoring, and onboarding 10x easier.

In short: treat your names like long-term investments. Spend the extra few seconds to get them right, and your future self (and teammates) will thank you.

Use Non-Persistent Entities for UI and Temp Data

When I first got started with Mendix, I had a habit of storing everything in the database, even values that only lived for a few seconds. Sounds harmless, right? But it didn’t take long before my database was cluttered with junk data, and the domain model looked more like a dumping ground than a design.

That’s when I learned the value of non-persistent entities.

What Are Non-Persistent Entities?

Non-persistent entities (NPEs) are data structures that exist only in memory. They don’t get saved to the database, which makes them perfect for temporary logic, UI screens, and fast processing.

According to Mendix’s official best practices, NPEs are ideal for:

• Wizard-style UIs where the data is collected step-by-step before committing

• Filtering and searching in list views or dashboards

• Previewing data before saving it

• Temporary data manipulation during logic-heavy microflows

Why Use Them?

• Cleaner logic: No need to clean up "junk" data from the database after.

• Better performance: You avoid unnecessary database writes and reads.

• Simpler rollback: Since nothing is saved, canceling is easy and clean.

• More flexible UIs: Great for customizing user interactions before committing anything.

How to Use Them Smartly

• Structure your UI pages around NPEs when no actual persistence is needed.

• Use microflows to map persistent data into NPEs for display or manipulation.

• Avoid using NPEs for data that must be saved or reported — that’s what persistent entities are for.

What to Avoid

• Don’t overuse NPEs for core business logic or long-running workflows.

• Avoid accidentally “over-modeling” temporary data — keep them lightweight.

• Don’t use NPEs in background processes or scheduled events, as their data is session-specific and will be lost.

Looking back, using non-persistent entities was one of the best performance and design improvements I made. Once you start using them effectively, your domain model gets cleaner, your app runs faster, and your logic becomes easier to manage.

Example: Building a Product Filter Page

Let’s say you're creating a dashboard where users can filter products by category, price range, and availability.

Here’s how you'd typically approach it as a beginner (like I did initially):

Beginner Approach:

• Add attributes like SelectedCategory and PriceMin/PriceMax to the User or Product entity.

• Use those attributes to filter products.

• Forget to clean them up afterward — leading to stale data and unnecessary clutter in the DB.

Better Approach with Non-Persistent Entity:

• Create a non-persistent entity called ProductFilterHelper with attributes like Category, MinPrice, MaxPrice, InStockOnly.

• Bind this entity to a data view on the filter UI.

• Use it in a microflow to dynamically return filtered results.

Result:

• Your domain model stays clean.

• No junk data is saved.

• You get fast, responsive filtering logic.

Start With Access Rules Early

This one hit me hard on my first real Mendix project. Everything worked beautifully during development — until we went live. Suddenly, users couldn’t see or do half the things they were supposed to. Why? I had barely touched access rules during development.

In Mendix, security isn't something to patch on later — it’s something you build with from the start.

Why It Matters

Access rules determine who can see or modify what in your app. Setting them up early helps avoid:

• “It worked on my machine” moments.

• Security gaps or unexpected data exposure.

• Wasted hours debugging access issues at the finish line.

Best Practices (Straight from the Source)

Mendix recommends:

• Defining user roles early and giving them meaningful, singular names like Customer, Manager, or SalesRep — following UpperCamelCase.

• Each user role should map to only one module role per module. This keeps your security model clear and manageable.

• Use XPath constraints to limit access at the entity level. Example: only allow users to retrieve orders they created — //[CreatedBy = '[%CurrentUser%]']

This is especially helpful when dealing with multi-tenant apps or sensitive data.

Also Consider:

• Testing each role before go-live — make sure what a User sees is really what a user should see.

• Keep entity access rules as strict as possible, and only loosen them when truly needed.

• Don’t assign default access to new users unless you’re absolutely sure about it.

Common Mistakes to Avoid

• Relying solely on page-level security — it’s not enough.

• Leaving access rules open during dev and forgetting to lock them down later.

• Giving one user role access to multiple module roles — it gets messy fast.

In short: secure as you go. You’ll build a safer, more reliable app — and save yourself a ton of last-minute fixes.

Break Big Microflows Into Smaller Reusable Ones

In my early Mendix projects, I often found myself building monster microflows — huge chains of logic crammed into one screen. At the time, it felt efficient: “Why split it up? It’s all part of the same process!”

But as the flow grew, so did the headaches:

• Debugging was painful.

• Reusing logic? Impossible.

• Even understanding what the flow did took five scrolls and a prayer.

Turns out, big isn’t better. It’s just harder to work with.

What Mendix Recommends

According to Mendix best practices:

• Keep microflows under 25 elements — that’s decisions, loops, actions, etc.

• Split complex logic into sub-microflows using prefixes like SUB_.

• Clearly annotate your microflows — especially if they contain more than 10 actions or 2+ decisions.

Pro Tip: Place a description annotation at the top of each complex flow — include purpose, parameters, and return values. It saves future devs (and you) from reverse-engineering it later.

Benefits of Smaller Microflows

• Easier to test: You can isolate and validate parts of your logic without stepping through a 50-block maze.

• Easier to debug: When something breaks, you can narrow down the issue fast.

• Reusable: That “calculate tax” logic? Reuse it across checkout, invoicing, and reporting.

• Cleaner UI: You avoid the visual spaghetti that comes from massive flows crossing lines and jumping directions.

How to Do It Right

• Use action prefixes (e.g., ACT_, SUB_, VAL_) to clearly indicate purpose.

• Keep business logic separate from UI or persistence logic — use sub-microflows.

• Annotate edge cases or integrations like REST calls or Java actions so others understand what’s happening behind the scenes.

What to Avoid

• Don’t use one microflow as a catch-all.

• Don’t rely on nested logic expressions (if…else if…else) within one decision block — spread them out for clarity.

• Avoid excessive parameters — too many inputs reduce reusability and readability.

Looking back, breaking down microflows wasn’t just about neatness — it was about building smarter. It turned messy logic into reusable, testable components I could rely on.

Reuse and Customize Marketplace Modules Wisely

One of the best things about Mendix is the Marketplace — a treasure trove of ready-to-use modules that can save you days (or weeks) of development time. Early on, I relied on it a lot — which was great... until I started modifying modules directly and broke upgrade compatibility later.

Here’s what I wish I knew from the start:

• Don’t modify Marketplace modules directly. If you do, you’ll run into upgrade issues when a new version comes out — your changes may be overwritten.

• Instead, create a wrapper or extension module. Use this module to:

  • Call into the original Marketplace logic

  • Extend microflows or entities without touching the original

  • Keep your customizations isolated

• Mark any changes clearly if modifying a module is absolutely unavoidable (though it’s still not ideal).

Using Marketplace modules wisely is about balancing speed and control. They’re fantastic tools — just make sure you treat them as external packages, not internal code. If you build with that mindset, you’ll future-proof your app and avoid some serious upgrade headaches.

Getting started with Mendix is exciting the platform makes it easy to jump in and start building. But as I’ve learned, taking the time to apply good practices early on makes all the difference later.

From naming conventions to microflow design and Marketplace usage, these are the things I wish someone had told me before my first real project. I made mistakes so you don’t have to.

If you’re new to Mendix, I hope these insights help you build smarter and avoid the early pitfalls. And if you’re already a few projects in, maybe this sparked a few “ah, I’ve been there” moments.

Either way, here’s to building better — one lesson at a time.