With template-based Excel export (XLSReport / Excel Exporter), you usually start by running a microflow before generating the Excel file. This gives you a lot of flexibility, because you can prepare the data exactly how you want, apply filters, do calculations, aggregate values, merge multiple datasets, or add derived rows and columns. Once the data is ready, it gets mapped into the Excel template and the file is generated. This makes it a great fit for report-style exports or more complex scenarios.
With template-free DataGrid2 export, things are much more straightforward. The export mainly reflects what is already shown in the grid. Any data shaping is limited to the grid’s datasource, and there is no separate “pre-export” microflow for more advanced transformations.
So in short, if you need to prepare or reshape your data in a microflow before exporting, template-based Excel export is the better and more appropriate choice.
Ahmet really explained it in a very good way. What I would add is to be aware of the size of rows you are exporting. XLSReport module will help you with bigger tables compared to the basic nanoflow export, but performance tends to be poor with this kind of modules. I would suggest to use csv instead of Excel formatting but it really depends on your task.
No, an XLSReport template is NOT required to export data from a DataGrid2.
However:
YES, an XLSReport template is mandatory if you use XLSReport-based Java actions like GenerateExcelDoc.
NO, DataGrid2’s built-in Excel export does not use XLSReport at all.
These are two completely different Excel export patterns in Mendix, meant for different use cases.
The Root of the Confusion
Your confusion is very understandable because:
Both approaches ultimately produce an .xlsx file
Both are called “Excel export”
Both can coexist in the same project
Some examples mix concepts unintentionally
But internally, they are architecturally unrelated.
The Two Excel Export Patterns in Mendix (Conceptual Model)
Mendix supports two fundamentally different Excel export mechanisms:
PatternUses XLS Template?Uses DataGrid2?Typical UsageDataGrid2 Native ExportNoYesSimple, user-driven exportsXLSReport (Template-Based)Yes (mandatory)NoStructured, formatted reports
Let’s break them down properly.
Pattern 1: DataGrid2 Native Excel Export (Template-Free)
What this is
This is the built-in Excel export feature of DataGrid2.
It is:
UI-driven
Template-free
Zero-code (or minimal configuration)
How it works internally
DataGrid2 already knows:
Columns
Attribute types
Visible rows
Filters and sorting
Mendix serializes the client-side grid state
The client generates an Excel file based on the grid definition
No microflow.No Java action.No XLS template.No XLSReport module.
What you get
One sheet
Column headers = grid column captions
Rows = grid data (respecting filters & sorting)
Basic formatting only
When this is the correct choice
Use DataGrid2 export when:
You want to export exactly what the user sees
No complex formatting is required
No calculated summary sections
No multiple sheets
No custom layout rules
This is the recommended and intended approach for simple exports.
Important limitation (by design)
No control over:
Fonts
Colors
Merged cells
Multiple sheets
Header sections
No business logic beyond what’s in the grid
This is not a reporting engine, it’s a data extraction feature.
Pattern 2: XLSReport / Template-Based Excel Export
What this is
This is server-side Excel generation using templates.
It relies on:
XLSReport.MxTemplate
Java actions like:
GenerateExcelDoc
ExportExcel
Why the template is mandatory here
The template:
Defines structure
Defines sheets
Defines formatting
Defines placeholders for data
Without a template:
The Java action has no instructions
So it throws an error
This is expected behavior, not a bug
This is like asking a report engine to generate a report without a report definition.
How it works internally
Retrieve an XLSReport.MxTemplate
Retrieve business data
Inject data into named placeholders
Generate Excel document
Store or download file
Everything happens server-side.
When this is the correct choice
Use XLSReport when you need:
Multiple sheets
Custom formatting
Headers, footers, logos
Calculated totals
Regulatory or audit reports
Scheduled or background exports
Data not directly visible in UI
This is not connected to DataGrid2 at all.
Why GenerateExcelDoc Fails Without a Template
This part is critical for conceptual clarity.
GenerateExcelDoc is not a generic “export to Excel” function.
It is specifically:
“Generate an Excel document based on a predefined XLS template”
So when:
No XLSReport.MxTemplate exists
Or retrieval returns empty
The action must fail, because:
There is nothing to generate from
This does not mean:
DataGrid2 export needs templates
Excel export always needs templates
It only means:
You used a template-based API
Why Some Examples Look Confusing
Many examples online:
Pre-date DataGrid2
Were built for DataGrid (classic)
Use XLSReport because it was the only option
Are reused without context
So people sometimes:
Add XLSReport to a DataGrid2 use case
Call GenerateExcelDoc
Expect grid-style behavior
Get confused when template is required
This is a misuse of the reporting mechanism, not a platform inconsistency.
Recommended Best Practice
Decision rule you can always rely on
Ask yourself one question:
“Do I need layout control and report-style formatting?”
If NO → Use DataGrid2 native export
If YES → Use XLSReport with templates
Never mix them unless you have a very specific reason.
Final Conceptual Clarification
DataGrid2 Excel export is template-free by design
XLSReport Excel generation is template-mandatory by design
These are two separate export paradigms
GenerateExcelDoc is not meant for DataGrid2 exports
Your expectation about DataGrid2 was correct
Once you treat these as separate tools for separate jobs, the confusion disappears completely.