Workflow `CALL MICROFLOW`: v0.16.0 writes the pre-11.9 `$Type`, so every scripted call activity is a red pin in Studio Pro and blocks app boot

[MendixMau]

Repo: mendixlabs/mxcli
Affects: v0.16.0 (current Latest release, built 2026-07-12)
Mendix: 11.13.0 (reproduced); applies to any project ≥ 11.9
Severity: High — affects every CALL MICROFLOW written from MDL regardless of syntax; both checkers pass, and the app will not boot.
Status of fix: Already fixed in main (253d60d8, 2026-07-29, FINDINGS #39). This report is "please cut a release" — the fix has been sitting unreleased while v0.16.0 remains Latest.

---

Summary

mxcli v0.16.0 writes workflow call-microflow activities with the on-disk $Type
Workflows$CallMicroflowTask. Mendix 11.9 (WOR-2802) split MicroflowBasedActivity into
CallMicroflowActivity + AIAgentTaskActivity and renamed that $Type to
Workflows$CallMicroflowActivity. Writing the pre-11.9 name into an 11.9+ project produces:

• In Studio Pro: every call-microflow activity renders as a red pin and cannot be
  double-clicked or configured. The rest of the workflow (user tasks, outcomes, branching) renders
  normally, which makes it look like a modelling mistake rather than a tool defect.
• At runtime: the entire model fails to load —
  Failed to load model: ... Class 'Workflows$CallMicroflowTask' could not be found.

This is independent of the WITH clause. It reproduces with a correct short WITH key, with a
fully-qualified key, and with no WITH clause at all. It is a separate defect from the
double-prefixing reported in the companion issue about fully-qualified WITH keys — that one
corrupts the parameter mapping; this one corrupts the activity type. A model can hit both at
once, and fixing only the WITH form leaves the red pin in place.

Why it is easy to miss

Both checkers pass. The commit message for 253d60d8 says so explicitly:

Both checkers passed (mxcli check ✓, mx check → 0 errors), but on an 11.9+ project the
runtime refused to load the ENTIRE model at boot

mx check is a load-and-validate pass, so "0 errors" reads like proof the model is good. It is not
sensitive to this $Type. The only cheap gate that catches it is opening the workflow in Studio
Pro and looking at the activity icons.

We lost roughly a day to this: a six-variant trigger-boundary probe of WITH-clause forms, every
arm graded by mx check, all six "passing" — and all six producing red pins, because the variable
under test was never the one that mattered.

Reproduction

Any workflow with a call-microflow activity, on a project ≥ 11.9:

CREATE WORKFLOW TFC."WF_Probe"
  PARAMETER $WorkflowContext: TFC."TFCStub"
BEGIN
  CALL MICROFLOW TFC."WF_ACT_TCCopilot_Prefill";
END WORKFLOW;

./mxcli check probe.mdl -p App.mpr --references   # => Check passed!
./mxcli exec  probe.mdl -p App.mpr                # => Created workflow: TFC.WF_Probe
"…/Mendix Studio Pro 11.13.0 Beta.app/Contents/modeler/mx" check App.mpr
                                                  # => The app contains: 0 errors.

Then read what was actually stored, rather than trusting either checker:

LC_ALL=C grep -rla "WF_Probe" mprcontents/            # locate the unit
LC_ALL=C strings -n 4 <unit> | grep -oE 'Workflows\$Call[A-Za-z]+'

Actual

Workflows$CallMicroflowTask

Studio Pro shows a red pin for the activity. mendix-runtime aborts model initialization.

Expected

Workflows$CallMicroflowActivity on any project ≥ 11.9 — which is what main now emits.

Controlled A/B — only the binary varied

Same MDL script, same .mpr (an rsync copy of one real project), same gate binary
(Mendix Studio Pro 11.13.0 Beta.app/Contents/modeler/mx). BSON read directly out of
mprcontents/*.mxunit, so these are stored bytes, not a reader's interpretation.

binary	stored $Type (×5 activities)	mx check	Studio Pro
v0.16.0 (tagged, 2026-07-12)	Workflows$CallMicroflowTask	0 errors	red pins, not clickable
504aec67 (main, 2026-07-31)	Workflows$CallMicroflowActivity	0 errors	renders and opens normally

The 5-activity workflow used here is a rebuild of a production workflow (3 user tasks, nested
Required/WaveOff branching, XPath user targeting). A hand-dragged workflow in the same model
stores CallMicroflowActivity, which is what made the diff obvious — the two units were otherwise
byte-comparable.

Impact

v0.16.0 is tagged Latest; the 2026-08-03 nightly (689e8ce4) is a Pre-release. So on
the current official release, no MDL-authored workflow containing a microflow call is usable on
any supported Mendix version (11.9 and later — i.e. all of them). Since both checkers report
success, users discover this either by opening Studio Pro or by watching the app fail to boot.

The practical consequence downstream is that teams conclude workflow authoring is "Studio-Pro-only"
and adopt a hand-dragging workaround — which is exactly the wrong lesson, since main already
writes this correctly.

Workaround for users on v0.16.0

There is no MDL-level workaround; no WITH form avoids it. Either build from main
(253d60d8 or later), or hand-drag call-microflow activities in Studio Pro.

Recovery from an already-broken model

mxcli reads models the Studio Pro loader rejects, so this is surgical:

./mxcli -p App.mpr -c "DROP WORKFLOW <Module>.<BadWorkflow>"

Then re-create with a fixed binary. Verified here: back to 0 errors, unrelated production
workflow (10 activities / 3 user tasks) untouched.

Suggested docs change

Worth a line in the bundled write-workflows skill: mx check returning 0 errors does not
establish that a workflow's activities are well-formed, and the storage-name class of defect is
only visible in Studio Pro. The skill currently presents mxcli check + mx check as the
validation step before presenting work to a user.

Environment

• mxcli v0.16.0 (2026-07-12T11:44:17Z) vs main 504aec67 (2026-07-31)
• Mendix Studio Pro 11.13.0 Beta; gated with that bundle's own mx
• macOS 15 (Darwin 25.5.0), Apple silicon
• A/B run in a throwaway copy in /tmp; baseline 0 errors before each arm