4.5 Client Notifications & User Feedback Activities

4.5 Client Notifications & User Feedback Activities

Exam Focus: "Client notifications" is one of the twelve topic areas named in the official Mendix exam guide. You must know which activities belong to the Client activities group, which of them are microflow-only or nanoflow-only, the difference between a blocking and a non-blocking Show message, when Validation feedback is the right tool instead, and why Refresh in client is a property rather than an activity.

Business logic that runs perfectly but tells the user nothing is a defect. In Mendix, everything a flow says or shows to the user comes from one clearly bounded group of activities — the Client activities — and knowing that group cold is worth several marks.

---

The Client Activities Group

Availability differs between microflows (server-side) and nanoflows (client-side), and the exam tests exactly that split:

Exam Trap: Download file and Show home page are microflow-only. Call nanoflow and the offline synchronization trio are nanoflow-only. Show message, Validation feedback, Show page, and Close page are the four that work in both.

---

Show Message: Type and Blocking

Show message is the general-purpose notification. Two properties carry all the exam weight:

Type

• Information (default) — neutral confirmation: "Order 10432 has been submitted."
• Warning — the action succeeded but something needs attention: "Two of the 40 rows were skipped."
• Error — the action failed: "The payment provider could not be reached."

The type controls the styling the client applies; it does not change the flow. An Error message does not abort the microflow or roll anything back — you still have to model that yourself.

Blocking

• Yes (default) — "The message appears in a pop-up in the center of the screen and does not let the user continue work until the pop-up window is closed."
• No — the pop-up still appears centrally, but the rest of the screen stays usable, so the user can carry on working with it open.

Because Blocking defaults to Yes, a Show message dropped inside a loop over 500 records produces 500 modal dialogs the user has to dismiss one at a time. Aggregate first, then send one message after the loop.

Template and Parameters

The message text is a template that may contain numbered parameters written between braces — {1}, {2} — and each parameter is supplied by an expression resulting in a string:

Template:   Order {1} was submitted for customer {2}.
Parameter 1: $Order/OrderNumber
Parameter 2: $Order/Sales.Order_Customer/Sales.Customer/Name

Building the sentence by string concatenation instead of a template works, but it breaks translation: templates are translatable texts, so the same message can be maintained per language (see Section 5.4).

---

Validation Feedback: The Right Tool for Field-Level Errors

Validation feedback performs the same job a mandatory-attribute error does out of the box: it shows a red message directly beneath the widget the user has to fix. Its properties are:

• Variable — the object being validated.
• Member — the attribute or association the message is attached to. For a reference selector or reference set selector, pick the associated element being edited.
• Template and Parameters — the message shown, using the same {1} numbered-parameter syntax as Show message.

Two documented limitations matter:

• Nanoflows do not support text templates in validation feedback. Only static message text can be provided there.
• Validation feedback is ignored when the microflow is called from an offline or native app — offline validation must be modelled some other way (see Section 8.3).

The Page Requirement

The feedback message is rendered by the widget bound to that member. If the object is not displayed on the page — or the attribute is not on the page at all — the user sees nothing, and the microflow appears to fail silently. This is the single most common source of "my validation does not work" tickets.

The Canonical Validation Pattern

[Start] → [Decision: $Order/DeliveryDate < [%CurrentDateTime%] ?]
             │ true                                    │ false
             ▼                                         ▼
   [Validation feedback on DeliveryDate]        [Commit Order]
             ▼                                         ▼
        [End: false]                              [End: true]

Return false from the validating microflow so the caller knows not to proceed. A validation feedback message does not stop the flow by itself.

Show Message or Validation Feedback?

---

Two Things That Are Not Client Notifications

1. Refresh in client is a property, not an activity. It sits on Change object, Change list, Commit, and Delete activities and tells the client to re-render widgets bound to the changed object. Candidates hunt for a "Refresh in client" activity in the toolbox and pick a wrong answer built around it. Setting it to Yes inside a loop is also a performance antipattern — refresh once, after the loop.
2. Log message writes to the server log. It has a log node and a level (Trace through Critical) and is invisible to end users. Use it alongside a Show message when something goes wrong: the user gets a readable sentence, operations get the diagnostic detail. Never put $latestError/Stacktrace in a Show message (see Section 9.2).

Flows With No Connected Client

Client activities need a client to talk to. In a scheduled event, a published REST or web service microflow, or an after-startup microflow, there is no user session to notify, so a Show message there accomplishes nothing useful. Log the outcome instead, or write it to an audit entity a user can actually open.