Mendix Advanced Developer Certification
Practice Examination 2026/2027 | Expert-Level
Assessment & Scenario Testing
50 Advanced Scenario-Based Questions | Domain-Aligned | Time Limit: 120 min
DOMAIN 1 – Advanced Data Modeling & Domain Model Integrity (Q 1-12)
1. Scenario: A logistics group needs to model Vehicle, Truck, and Van entities. Both
Truck and Van share attributes (licensePlate, purchaseDate) but have unique ones
(Truck has maxPayload; Van has cargoVolume). The app must often treat all items as
"Vehicles" for routing queries.
Current State: Separate entities with duplicated attributes.
Requirements: 1) Remove redundancy. 2) Enable polymorphic queries.
Most scalable / maintainable approach?
A. Single Vehicle entity + enumeration Type (Truck/Van) + validation rules.
B. Generalization: super-entity Vehicle (common attributes) + specializations Truck &
Van (unique attributes).
C. Keep separate entities; use OQL UNION in reports.
D. Association entity VehicleRole linking to attribute sets.
,Answer: B
I. Requirement Analysis: "Is-a" relationship, polymorphic queries, DRY.
II. Platform Best Practice: Mendix native generalization automatically creates single
table with discriminator; XPath on Vehicle retrieves all sub-types; no manual joins.
III. Solution: Create Vehicle generalization → specialize; routing microflow retrieves
Vehicle list and casts when needed.
IV. Pitfall: Option A produces sparse table, complex validations; C requires manual
SQL-like unions; D models "has-a," complicating logic.
2. Scenario: Order entity has Status (Draft, Processed, Shipped) and TotalAmount.
Rule: "Processed orders must have TotalAmount > 0."
Current State: Rule enforced only in UI form.
Requirements: 1) Domain-level enforcement regardless of change source (UI, API,
microflow). 2) Clear error message.
Developer must configure:
A. Before-commit event handler on Order throwing exception.
B. onChange microflow on Status attribute that validates and uses
ValidationFeedback if Amount ≤ 0.
C. Validation rule on TotalAmount field.
D. Dedicated microflow called from every entry point.
,Answer: B
I. Requirement: Cross-attribute validation triggered by state change.
II. Best Practice: onChange runs for any attribute change origin;
ValidationFeedback prevents commit and shows user-friendly message.
III. Implementation: onChange microflow: if $Order/Status = 'Processed' and
$Order/TotalAmount ≤ 0 → ValidationFeedback message.
IV. Pitfall: A runs too late; C cannot reference another attribute; D violates DRY and is
fragile.
3. Scenario: Multi-company app uses Company entity; Customer must be unique per
company (composite key).
Requirements: 1) Prevent duplicate Customer code within same Company. 2) No
custom Java.
Approach:
A. Store concatenated string CompanyCode_CustomerCode and apply unique
validation.
B. Use "Custom validation with before-commit event" microflow that checks existence
with XPath using both Company and CustomerCode.
C. Mark CustomerCode as unique in domain model.
D. Create separate Customer entity per company.
Answer: B
, I. Requirement: Composite uniqueness rule.
II. Best Practice: Before-commit microflow performs XPath retrieve:
[CustomerCode = $Customer/CustomerCode][Company =
$Customer/Company]; if count > 0 → raise message.
III. Advantage: Platform-native, no Java, works for any commit source.
IV. Pitfall: A requires maintaining concatenated field; C enforces global uniqueness; D
duplicates entities.
4. Scenario: Invoice and InvoiceLine (1-*). Lines are created via API. Rule: "Only
one line per unique Product per invoice."
Requirements: 1) Domain-level enforcement. 2) Clear user feedback.
Best pattern?
A. Before-commit on InvoiceLine → retrieve count of lines with same Invoice +
Product; if >1 → reject.
B. onChange microflow on Product in line-creation form; validate uniqueness and
show message immediately.
C. Use database unique constraint on Product attribute.
D. Delete duplicates nightly with scheduled event.
Answer: B
I. Requirement: Real-time feedback during line creation.
Practice Examination 2026/2027 | Expert-Level
Assessment & Scenario Testing
50 Advanced Scenario-Based Questions | Domain-Aligned | Time Limit: 120 min
DOMAIN 1 – Advanced Data Modeling & Domain Model Integrity (Q 1-12)
1. Scenario: A logistics group needs to model Vehicle, Truck, and Van entities. Both
Truck and Van share attributes (licensePlate, purchaseDate) but have unique ones
(Truck has maxPayload; Van has cargoVolume). The app must often treat all items as
"Vehicles" for routing queries.
Current State: Separate entities with duplicated attributes.
Requirements: 1) Remove redundancy. 2) Enable polymorphic queries.
Most scalable / maintainable approach?
A. Single Vehicle entity + enumeration Type (Truck/Van) + validation rules.
B. Generalization: super-entity Vehicle (common attributes) + specializations Truck &
Van (unique attributes).
C. Keep separate entities; use OQL UNION in reports.
D. Association entity VehicleRole linking to attribute sets.
,Answer: B
I. Requirement Analysis: "Is-a" relationship, polymorphic queries, DRY.
II. Platform Best Practice: Mendix native generalization automatically creates single
table with discriminator; XPath on Vehicle retrieves all sub-types; no manual joins.
III. Solution: Create Vehicle generalization → specialize; routing microflow retrieves
Vehicle list and casts when needed.
IV. Pitfall: Option A produces sparse table, complex validations; C requires manual
SQL-like unions; D models "has-a," complicating logic.
2. Scenario: Order entity has Status (Draft, Processed, Shipped) and TotalAmount.
Rule: "Processed orders must have TotalAmount > 0."
Current State: Rule enforced only in UI form.
Requirements: 1) Domain-level enforcement regardless of change source (UI, API,
microflow). 2) Clear error message.
Developer must configure:
A. Before-commit event handler on Order throwing exception.
B. onChange microflow on Status attribute that validates and uses
ValidationFeedback if Amount ≤ 0.
C. Validation rule on TotalAmount field.
D. Dedicated microflow called from every entry point.
,Answer: B
I. Requirement: Cross-attribute validation triggered by state change.
II. Best Practice: onChange runs for any attribute change origin;
ValidationFeedback prevents commit and shows user-friendly message.
III. Implementation: onChange microflow: if $Order/Status = 'Processed' and
$Order/TotalAmount ≤ 0 → ValidationFeedback message.
IV. Pitfall: A runs too late; C cannot reference another attribute; D violates DRY and is
fragile.
3. Scenario: Multi-company app uses Company entity; Customer must be unique per
company (composite key).
Requirements: 1) Prevent duplicate Customer code within same Company. 2) No
custom Java.
Approach:
A. Store concatenated string CompanyCode_CustomerCode and apply unique
validation.
B. Use "Custom validation with before-commit event" microflow that checks existence
with XPath using both Company and CustomerCode.
C. Mark CustomerCode as unique in domain model.
D. Create separate Customer entity per company.
Answer: B
, I. Requirement: Composite uniqueness rule.
II. Best Practice: Before-commit microflow performs XPath retrieve:
[CustomerCode = $Customer/CustomerCode][Company =
$Customer/Company]; if count > 0 → raise message.
III. Advantage: Platform-native, no Java, works for any commit source.
IV. Pitfall: A requires maintaining concatenated field; C enforces global uniqueness; D
duplicates entities.
4. Scenario: Invoice and InvoiceLine (1-*). Lines are created via API. Rule: "Only
one line per unique Product per invoice."
Requirements: 1) Domain-level enforcement. 2) Clear user feedback.
Best pattern?
A. Before-commit on InvoiceLine → retrieve count of lines with same Invoice +
Product; if >1 → reject.
B. onChange microflow on Product in line-creation form; validate uniqueness and
show message immediately.
C. Use database unique constraint on Product attribute.
D. Delete duplicates nightly with scheduled event.
Answer: B
I. Requirement: Real-time feedback during line creation.
