The Hidden Hero Behind a Perfect Excel Import: A Mendix Story About NPEs

The Hidden Hero Behind a Perfect Excel Import

A Mendix Story About NPEs

Every enterprise app has that one feature customers can’t live without: Excel import. It looks simple from the outside — upload a file, click a button, done.

But inside any Mendix project, developers know the truth: One wrong Excel file can mess up everything.

This is exactly what happened in one of my projects.

A business user uploaded a list with thousands of rows. Most of them were correct, a few had spelling mistakes, and some rows had email addresses like “abc@.com” that made no sense at all.

The worst part of it all? All of it got saved into the main database, and we had to clean it manually — one row at a time! That’s when I promised myself: This will never happen again.

The Idea: What If We Don’t Save Anything At First?

Instead of committing the uploaded data directly to the database, what if we kept everything in memory, like a temporary workspace?

Something that holds all user details, validates them, highlights mistakes, and disappears when not needed.

That “something” became the hero of the story: Non-Persistent Entities (NPEs).

The Birth of the Temporary World

We created a tiny world inside the app. A world that exists only during the user’s session. A world that holds every detail from the Excel file but never touches the database until the user approves.

When the user uploads the file, Mendix quietly creates objects in this temporary world:

· Username

· Email

· Phone

· Location

It then checks whether the row is valid or not, whether it’s a duplicate. And an error message if something is wrong. It’s like a rehearsal before the real performance.

No commitments. No mistakes. No pressure.

The Truth Comes Out in the Preview (Table)

Then something magical happens. The user sees a preview table with rows neatly displayed, but now with honesty:

• Invalid emails glow in red
• Missing names show a warning
• Duplicate Users whisper, “Already exists.”

And clean rows sit confidently, ready to be saved. The temporary NPE world becomes a mirror. It reflects the truth of the Excel file without polluting the real database. The user no longer has to guess what went wrong.

They can clearly see it — It’s transparent. It’s safe. It’s fair.

The Calm Before the Commit

Users now have complete control. If they like what they see, they press Save. We take only the valid, perfect rows and convert them into real database objects.

The messy ones? We ignore them.

Why save trouble?

When the user is finished, the temporary NPE world quietly disappears. No records left behind. No cleanup needed — just a clean database and a happy user!

Why This Matters

When I look at this feature today, it feels like a life hack for developers. NPEs didn’t just solve a technical challenge — they changed the way users trust the system.

They feel more confident, and they make fewer mistakes. They need never fear importing Excel files again! It turned a risky operation into a safe, predictable, almost elegant experience.

Under the Hood: How This Entire Feature Actually Works

Behind the scenes, this Excel preview feels smooth and magical to the user, but there is a smart technical flow that makes it happen.

Let’s zoom in and see how each layer silently contributes to the final result.

Domain Model — Designing the Temporary World

We introduce two Non-Persistent Entities:

ImportSession (NPE): This keeps track of a single upload action — one user, one Excel file

UserPreview (NPE): This holds each row from the uploaded file, including validations and error indicators.

They are connected by a simple association: 1 ImportSession to many UserPreview (1-*)

Meaning:

One upload session can have many preview rows. Why should you use NPEs here? Because this is temporary data, once the user leaves the page or finishes importing, all data disappears automatically.

Excel Import Mapping — Transforming Rows into Objects

When the user uploads the file, Mendix reads the Excel sheet using Excel Importer. For each row, it creates a UserPreview object

Attributes like Name, Email, and Phone get filled in. It’s like pouring Excel rows into a temporary bucket — structured and separated.

At this point:

· No data touches the database

· Everything lives only in the memory of the current session

Data Validation — The Smart Filter

Then the system runs a validation microflow for each row:

1. Is the email properly formatted?
2. Is User Name missing?
3. Does the phone number look valid?
4. Does the same User already exist in DB?
5. Is there a duplicate within the uploaded file?

If something is wrong, the row gets a warning written into it:

IsDuplicate → Boolean

ErrorMessage → Clear human-readable text (e.g., “Email format invalid”)

This ensures users understand exactly what went wrong.

Preview UI — The Honest Table

All UserPreview objects are displayed in a grid/list linked to the ImportSession. Users visually see:

• Valid rows appear normal
• Invalid rows show red messages
• Duplicates show alert icons

Users now have full control to modify the file, reupload it, and see a fresh preview. Zero mistakes reach the DB unnoticed.

Final Commit Microflow — Only the Valid Ones Enter the Database

Once users approve, the system picks only the rows that satisfy:

• IsDuplicate = false
• AND ErrorMessage = empty/null

For each valid row:

• A Persistent User object is created
• Its attributes are copied from UserPreview
• Only then is it committed to the database

Invalid rows? Quietly ignored — they never become permanent.

The Database remains clean.

Final Thought

In Mendix, NPEs are like backstage workers in a theatre.

The audience never sees them, but the entire show depends on them.

By using NPEs for Excel preview imports, you give users the power to verify, correct, and confirm data before it ever touches your database!

Read more

[embed]Persistability Introduction The Persistable property of an entity in the domain model defines whether an object can be committed to…docs.mendix.com

[embed]Validation Rules Introduction Validation rules are conditions that should be satisfied before an object is committed. If a condition…docs.mendix.com

From the Publisher -

Inspired by this article to bring your ideas to life with Mendix? Sign up for a free account! You’ll get instant access to the Mendix Academy, where you can start building your skills.

For more articles like this one, visit our Medium page. And you can find a wealth of instructional videos on our community YouTube page.

Speaking of our community, join us in our Slack community channel. We’d love to hear your ideas and insights!