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, likeUserManagement
orCommunicationsAndInteractions
.Entities represent real-world objects, so names like
Customer
orProduct
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 buttonsDS_
for data sourcesVAL_
for validationsSUB_
for sub-microflowsACO_/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
andPriceMin/PriceMax
to theUser
orProduct
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 likeCategory
,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
, orSalesRep
— followingUpperCamelCase
.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.
Subscribe to my newsletter
Read articles from Md Salik Aqdas directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
