Mendix Advanced Developer common mistakes
Mendix Advanced Developer · Understand the traps and how to avoid them.
Sets an association's owner to "Both" so child objects can be created from either side, then deletes the parent and expects the children to disappear; at runtime the children remain and the delete fails or leaves orphan records.
Mendix stores an association on the owning side only. With Both ownership the child can hold a reference the parent does not, and delete behavior is not inferred from the domain model. Candidates model for UI convenience instead of persistence semantics.
What to do instead
Set ownership to the parent side (default for one-to-many), configure delete behavior per association (Cascade for dependent children, or Remove/Delete explicitly in the microflow), and avoid Both unless a many-to-many genuinely needs it. Test parent deletion with child data present.
Grants a module role access to a page and to the microflow, then assumes users in that role can read the entity; the page opens but the data grid is empty or throws an access error.
Mendix enforces three independent layers: module role access for pages and microflows, entity access rules at attribute level with optional XPath row constraints, and published service security. Page access does not grant entity access.
What to do instead
Add an access rule on the entity for the module role, set read/write per attribute, and scope rows with an XPath constraint such as [Owner = '[%CurrentUser%]']. Test with a user actually assigned to that role, not with Administrator.
Adds an error event with "Custom without rollback" on a microflow that has already changed and committed objects, then throws a validation error and expects the changes to be undone.
The error handling option controls what happens to uncommitted changes and the transaction. Custom without rollback leaves committed data in place and can leave partially changed objects, so a validation error does not restore state.
What to do instead
Perform validation checks before any commit, use "Custom with rollback" or a validation microflow that returns a message, and place the call activity in a parent microflow with rollback error handling. Commit only after all checks pass.
Builds an offline-first nanoflow that calls a Java action or a microflow-only activity such as Execute database query, and expects it to work offline; at runtime the nanoflow fails or the activity is unavailable.
Nanoflows run on the client and support a restricted activity set. Java actions and many server-side activities cannot execute in the browser or offline. Candidates reuse microflow patterns without checking the nanoflow toolbox.
What to do instead
Use nanoflow-supported activities, or call a microflow via Call microflow and design for online/offline behavior. Replace Java logic with nanoflow expressions, client-side actions, or a REST call where appropriate, and test in offline mode.
Maps a JSON array to a list but does not handle an empty array or a missing optional attribute; the first response with zero records throws an expected-object error or a null conversion error.
Import mappings expect the structure they were modelled on. JSON readers return null or an empty list, and Mendix does not automatically treat an absent array as an empty list unless the mapping is configured to do so.
What to do instead
In the import mapping, map the array to a list and enable handling for empty lists. For optional attributes use conditional mapping or a default value. Add tests with an empty array and with a missing field.
Publishes an OData service and grants the integration user access to the microflow, but forgets entity access and association exposure; metadata loads but queries return 403 or association navigation returns nothing.
Published OData services enforce entity access rules and require associations to be explicitly exposed. Module role access on the service alone is not enough, and candidates often test only with the Administrator role.
What to do instead
Create a dedicated module role for the integration, add entity access rules with the required XPath, expose the needed associations in the OData resource, and test with a user in that role using $expand to verify association access.
Retrieves a list of orders, then inside a loop retrieves the customer for each order with a separate database retrieve; on 500 orders the page takes seconds and the log shows hundreds of queries.
This is the N+1 pattern: each iteration issues a query. The microflow editor makes a per-object retrieve look natural, and it only hurts at scale, so it passes with small test data.
What to do instead
Retrieve related objects once with an association path or an IN clause, or join in memory using a hash map. Use list operations instead of per-object retrieves, add indexes on searched attributes, and measure with performance logs.
Copies entities, pages, and microflows from a reusable module into the app instead of extending them, so upgrades require manual merges and the same bug is fixed in three places.
Candidates model for the current app and avoid the overhead of module boundaries. Mendix modules are the unit of reuse and versioning, and copy-paste feels faster until a second app needs the same logic.
What to do instead
Put reusable domain and logic in a separate module with a clear API: published microflows, module roles, and entity access. Use module import and versioning, extend via generalization or microflow calls, and document the module's public interface.
Deploys to acceptance with database and mail server constants still set to development values, or edits constants in the Modeler and expects Mendix Cloud to change without a redeploy.
Constants are environment-specific configuration. The Modeler default is not the runtime value, and Mendix Cloud stores constant values per environment. Candidates confuse model constants with environment settings.
What to do instead
Define constants in the model and set values per environment in the Mendix Portal or cloud settings, or in a configuration file for on-premise. Never hard-code endpoints, and add a deployment checklist covering constants, scheduled events, and admin password.
Writes a Java action that changes objects and throws an exception without calling Core.rollback or declaring the exception; the calling microflow catches the error but the objects remain committed or the transaction is left inconsistent.
Java actions run inside the Mendix runtime transaction. A Java exception does not automatically roll back the transaction, and checked exceptions must be declared in the action definition to surface as microflow errors.
What to do instead
Declare exceptions in the Java action, wrap the body in try/catch, call Core.rollback(context) before rethrowing, and let the calling microflow handle the error with rollback. Use Core.commit only after successful validation.