6.2 Entity Access Rules & Attribute-Level Security

Mendix Certified Intermediate Developer Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Exam Blueprint, Agile Collaboration & Project Structure

1.1 Exam Blueprint, Format & Logistics 1.2 Mendix Project Lifecycle & Agile Roles 1.3 Project Directory Structure & Architecture 1.4 Modules, Marketplace Content & Module Boundaries 1.5 Team Server, Branching & Version Control

2 Chapter 2: Advanced Domain Modeling & Entity Architecture

2.1 Persistable vs. Non-Persistable Entities 2.2 Entity Generalization & Specialization 2.3 Associations & Delete Behavior 2.4 System Members, Attributes & Indexing

3 Chapter 3: XPath Constraints & Data Retrieval

3.1 XPath Syntax & Association Traversal 3.2 XPath Functions, System Tokens & Date Math 3.3 Advanced Filtering Patterns & Database Performance

4 Chapter 4: Advanced Microflows & Business Logic

4.1 Sub-microflows & Modular Architecture 4.2 List Operations & Aggregations 4.3 Loops, Batch Processing & Rules 4.4 Error Handling & Transaction Management 4.5 Client Notifications & User Feedback Activities

5 Chapter 5: Advanced UI, Navigation & Atlas UI

5.1 Atlas UI Architecture & Design System 5.2 Advanced Widgets, Snippets & Building Blocks 5.3 Dynamic Behavior: Conditional Visibility & Editability 5.4 Multi-Language & Internationalization

6 Chapter 6: Application Security & Access Control

6.1 Security Architecture & Security Levels 6.2 Entity Access Rules & Attribute-Level Security 6.3 Row-Level Security via XPath Constraints 6.4 Anonymous Users & Public Access

7 Chapter 7: REST & SOAP Integrations

7.1 Consuming REST Services 7.2 Import & Export Mappings with JSON & XML 7.3 Publishing REST Services 7.4 Consumed SOAP Web Services & Error Handling

8 Chapter 8: Mobile Development & Nanoflows

8.1 Mobile Architectures: PWA vs. Native Mobile 8.2 Nanoflows Architecture & Client-Side Execution 8.3 Offline Synchronization & Conflict Resolution

9 Chapter 9: Debugging, Quality Assurance & Operations

9.1 Microflow Debugger & Diagnostic Tools 9.2 Logging, Error Tracking & Monitoring 9.3 Consistency Checks, Best Practices & Quality

6.2 Entity Access Rules & Attribute-Level Security

Key Takeaways Explain This Topic AI

Entity Access Rules define granular Create, Delete, Read, and Write permissions per attribute and association for specific Module Roles under Production security.

Mendix adheres to a strict deny-by-default architecture: without an explicit access rule granting permission to an entity, a Module Role has zero access to its records.

Access permissions across multiple rules or multiple assigned user roles are strictly additive: the effective permission is the mathematical union of all granted rights (e.g., Read + Read/Write = Read/Write).

Association security follows the ownership principle: modifying an association reference requires Read/Write access to the association on the owning entity, plus at least Read access to the target entity.

Microflows execute with elevated system privileges by default ('Apply entity access = No'), but can be toggled to 'Apply entity access = Yes' to enforce the calling user's entity access rules.

Last updated: September 2026

6.2 Entity Access Rules & Attribute-Level Security

Exam Focus: Entity Access is the cornerstone of data security in Mendix. Intermediate Developer certification exams test your ability to configure granular member access matrices, determine effective permissions when multiple rules overlap, navigate association security from owning versus non-owning ends, resolve security consistency check errors, and choose the correct 'Apply entity access' setting on microflows.

When an application operates under Production Security , the Mendix Runtime enforces an absolute deny-by-default model on data. If an entity exists in the domain model without explicit access rules granting privileges to a user's role, that user cannot query, view, create, update, or delete instances of that entity. Even if a user navigates to a page containing a data grid connected to that entity, the grid will render completely empty, and unauthorized REST/OData requests will return HTTP 403 Forbidden or empty payloads.

Anatomy of an Entity Access Rule

Entity access rules are configured inside the Domain Model by opening an entity's properties dialog and navigating to the Access Rules tab. Each rule consists of four architectural components: ENTITY ACCESS RULE

• ├── 1. Module Roles (One or more roles to which this rule applies)
• ├── 2. Instance Operations (Allow Creating new objects: Yes/No | Allow Deleting: Yes/No)
• ├── 3. XPath Constraint (Row-level filter, e.g., [System.owner = '[%CurrentUser%]'])
• └── 4. Member Access Rights (Matrix of attributes & associations: None / Read / Read-Write)
• 1. Module Roles

Specifies which Module Roles within the current module are governed by this rule. A single rule can target multiple module roles if they share identical data access requirements.

2. Instance Operations (Create & Delete Rights)

Allow creating new instances (Create): Permits the module role to instantiate new records of this entity via page 'New' buttons, Create Object microflow activities, or REST POST endpoints.

Allow deleting instances (Delete): Permits the module role to delete records via Delete buttons or Delete Object microflow activities.

3. XPath Constraint

An optional filter restricting the rule to a specific subset of rows in the database (explored in depth in Section 6.3). When omitted, the rule applies globally to all rows of the entity.

4. Member Access Rights (Attributes & Associations)

Defines the granular visibility and editability for every individual attribute and association belonging to the entity:

No Access (None): The attribute or association is completely invisible. The runtime strips this data before transmitting it to the client browser, and queries returning this member return null .

Read-Only (Read): The user can view the value in data grids, text boxes, and read it in expressions, but cannot edit it via UI controls or update it in microflows running with entity access enabled.

Read/Write (Write): The user can both view and modify the attribute value, or link/unlink the association.

The Member Access Matrix in Practice

Consider an enterprise entity CustomerOrder in a B2B commerce application. Different organizational personas require vastly different visibility into order details, pricing margins, and approval statuses:

• Member (Attribute / Association) Type Role: Customer Role: SalesRepresentative Role: FinancialController
• OrderNumber String (AutoNumber) Read-Only Read-Only Read-Only
• OrderDate DateTime Read-Only Read/Write Read/Write
• TotalAmount Decimal Read-Only Read/Write Read/Write
• ProfitMargin Decimal No Access Read-Only Read/Write
• ApprovalStatus Enumeration Read-Only Read-Only Read/Write
• InternalAuditNotes String No Access Read/Write Read/Write
• Order_Customer (Association) Reference Read-Only Read/Write Read-Only
• Allow Creating Instances Boolean ❌ No ✅ Yes ❌ No
• Allow Deleting Instances Boolean ❌ No ❌ No ✅ Yes

Critical Observations from the Matrix:

Data Leak Prevention: The Customer role has No Access to ProfitMargin and InternalAuditNotes . If a developer mistakenly places ProfitMargin on a customer-facing page, the Mendix client engine does not render the value, preventing sensitive financial data exposure.

Separation of Duties: SalesRepresentative can create orders and enter TotalAmount , but only FinancialController has Write permissions on ApprovalStatus and Delete privileges on the order records.

Loading diagram... Securing Associations: Navigating and Modifying Association References

Securing Associations: The Ownership Principle

Securing associations is a frequent source of confusion on the Intermediate Developer exam. In Mendix, associations are directional at the relational schema level:

Association Ownership Architecture

Every 1-to-1 and 1-to-Many association has an Owner entity (indicated by the dot or originating end in the domain model editor, or explicitly selected in the association properties dialog).

The foreign key reference is physically stored on the table of the owning entity .

In Studio Pro's Access Rules , the association appears as a configurable member in the Member Access list of the owning entity .

The Three Rules of Association Security:

Modifying an Association: To change, set, or clear an association (e.g., assigning a Customer to an Order using a reference selector widget or a Change object activity), the user must have Read/Write access to the association on the owning entity ( Order ).

Target Entity Requirement: To select an object to link, the user must have at least Read access to the target entity ( Customer ). The user does not need Write access to the target entity merely to reference it.

Navigating from the Non-Owning End: If an association is configured with ownership set to Both (common in Many-to-Many associations), the association member appears in the access rules of both entities, allowing security to be managed from either perspective.

Exam Trap: If a developer grants a role Read/Write access to both the Order entity and the Customer entity, but forgets to grant Write access to the Order_Customer association member on the Order entity, the user will be unable to set the customer on an order! The reference selector on the page will render disabled/grayed out.

Additive Permission Union: How Overlapping Rules Combine

A central rule of Mendix security evaluation is that permissions are strictly additive . When a user is assigned multiple user roles, or when an entity defines multiple access rules for the same module role:

Effective permission = the union of the permissions granted by every applicable rule.

Additive Evaluation Rules:

• No Access + Read = Read
• Read + Read/Write = Read/Write
• No Access + Read/Write = Read/Write
• Cannot Create + Can Create = Can Create
• Cannot Delete + Can Delete = Can Delete

There is no concept of a 'Deny' rule in Mendix. A restrictive rule cannot override or revoke a privilege granted by another rule. If Rule A grants Read-only access to CreditLimit and Rule B grants Read/Write access to CreditLimit for the same role, the user will enjoy full Read/Write access.

Microflow Security Context: 'Apply Entity Access' Yes vs. No

Every microflow in Mendix contains a critical security setting in its properties panel: Apply entity access (Boolean: Yes or No ). CALLING USER: JuniorClerk (Has Read-Only access to Invoices)

• │
• ├──► Executes Microflow A (Apply entity access = YES)
• │ └── Attempts to Change Invoice.Status to 'Paid'
• │ └── 🛑 RUNTIME ERROR: SecurityException (Write Denied!)
• │
• └──► Executes Microflow B (Apply entity access = NO)
• └── Attempts to Change Invoice.Status to 'Paid'
• └── ✅ SUCCESS: Status updated with elevated system privilege

Operational Differences:

Capability Apply Entity Access = Yes Apply Entity Access = No (Default)

Execution Context Executes within the security sandbox of the calling user . Executes with elevated system privileges (bypasses entity access).

Attribute Write Enforcement Throws a runtime SecurityException if microflow modifies an attribute without Write rights. Writes succeed regardless of the user's attribute permissions.

Database Retrieve Filtering Applies the user's row-level XPath constraints automatically to all retrieves. Retrieves all database records matching the activity's query, ignoring user constraints.

Recommended Use Case User-initiated transactions, custom validation logic, and self-service UI workflows. System integrations, scheduled background events, batch data processing, and administrative audit logging.

Best Practice: Always set 'Apply entity access = Yes' for microflows exposed directly to end-user buttons or REST endpoints, unless elevated privileges are explicitly required for a backend system calculation.