Deal Flow 0.9.4: What Shipped and What It Means

0.9.4 made two specific changes

The first 0.9.4 fix is in the task queue. Selecting a pipeline while leaving the owner filter at “All owners” had returned HTTP 400. The 0.9.4 release notes, dated June 10, 2026, say empty optional query parameters are now treated as absent, so that valid combination is no longer rejected.

For a buyer, the useful signal is the specificity. This is not a broad claim about every task view; it names the filter combination, the observed response, and the handling change. A team evaluating the task queue can reproduce that exact path in its own environment instead of trying to interpret a generic “bug fixes” label.

The second change is informational. On the Updates page, both the “Update available” and “Up to date” cards now show the latest version’s actual release date beside the license update window. That gives an administrator two different dates in context: when the release shipped and the update-window information already shown by the page. The changelog records a display change; it does not describe a change to license behavior.

0.9.3 and 0.9.2 show how the line handled defects

The 0.9.3 entry, dated June 4, 2026, documents a modal-specific New Deal save problem. When the form was opened from Reports, Pipeline, or the deal list, saving could display a raw AJAX payload instead of rendering the board. The same entry explicitly says full-page creation and editing were unaffected. That boundary matters during evaluation: a successful full-page test would not have exercised the modal path that changed.

Version 0.9.2, also dated June 4, addresses packaging rather than an application workflow. The shipped notes say the withdrawn 0.9.1 archive came from stale source, omitted required controller classes, and caused HTTP 500 responses on deal pages for fresh installations. They also say release archives are now produced from the canonical packaging step.

The same notes direct anyone on 0.9.1 to move to 0.9.2 or later and state that 0.9.0 was unaffected. That is the practical boundary to preserve when reviewing an installed archive: identify its exact version before using a symptom from one build to judge another.

The wider 0.9.x line covered compatibility and integration surfaces

The 0.9.0 entry, dated March 25, 2026, records Mautic 7 compatibility, service-registered controllers, and a rendering compatibility layer with a version adapter and Twig extension for Mautic 5, 6, and 7. It also records structured logging for legacy routes and a command-line update command that replaced web-request file operations.

That release included documented fixes across the API controller, deal titles, note handling, and kanban stage moves. Those are separate surfaces, not one blanket result. An evaluator should map each relevant changelog line to the corresponding workflow used by the team.

Elsewhere in the March 26, 2026 0.9.1 entry, the changelog records pipeline and stage listing API endpoints for n8n integration, plus gate, integration, end-to-end, and upgrade workflows covering Mautic 5, 6, and 7. These entries document the named release workflows and integration endpoints; they are not a substitute for testing the target instance and its installed extensions.

Turn the changelog into an evaluation checklist

A release history is most useful when it produces testable questions. For this line, verify the installed archive version first. Then test the task queue with a selected pipeline and “All owners,” save a New Deal from both a modal and a full page, and inspect both Updates-page card states when they are available in the environment.

If an integration depends on pipeline or stage listings, exercise those endpoints with representative permissions and data. If the team is crossing major Mautic versions, verify the actual screens and routes it uses rather than treating a compatibility entry as environment-wide proof.

That release-level verification sits beside the broader workflow decision covered in How to Track Deals in Mautic. First decide how deals should be represented and operated; then use the changelog to test the specific product paths that support that choice.

A visible record is useful because it is inspectable

For someone evaluating a paid plugin, a dated changelog provides more value than an undifferentiated claim of quality. It exposes the scope of each release, identifies affected paths, and preserves version boundaries when an archive is withdrawn. In the 0.9.x line, that means a buyer can see a focused filter fix, a modal save fix, a packaging correction, and earlier compatibility and integration work as distinct changes.

The record does not remove the need for staging checks, nor does it make every release equally relevant to every team. Its value is that the claims are narrow enough to inspect. That is the standard we want this release commentary to preserve: state what shipped, name the boundary, and leave the evaluator with a concrete verification path.

Release facts in this post come from the Deal Flow changelog as published and checked August 28, 2026.