The short version: R4 puts HTML content on the same footing as everything else you proof, and speeds up processing on your largest projects by handling files in parallel instead of one at a time. For regulated online proofing, where a single campaign can span dozens of state-by-state variants, that means the content reaches your reviewers faster and the HTML a designer exports is the HTML compliance and legal actually review.
This is the fourth release of the 2026 cycle: 3 new features, 11 improvements, and 2 bug fixes. Here are the three that matter most for regulated teams, and where each one lands.
HTML now has a dedicated project type
Pillar: atomic extraction.
HTML content used to be awkward to bring into Aproove: the right project type was not obvious, and choosing wrong meant re-creating the project. R4 adds a dedicated "HTML (Local)" project type that runs on the same processor you already use for everything else.
It also fixes the packaging problem. When you upload a ZIP for an HTML project, Aproove needs to know which file opens the proof. It now accepts both common conventions: a plain index.html, or a name built from the project itself. The expected structure is configurable per configuration, and if nothing matches, Aproove falls back to index.html and reports a clear error if that is missing too. In practice: your existing export tooling works without repackaging.
For a marketing, compliance, and legal team working the same asset, that means the HTML a designer exports is the HTML everyone reviews. No conversion step in between, no separate copy that drifts from the one that ships.
Proofs from a web link now render the way a browser does
Pillar: built-in auditability and governance.
When you generate a proof PDF from a web link, R4 captures it with a new Chromium engine. The previous capture path could render pages with broken or shifted layouts that did not match what you would see in a browser. The new engine matches the browser.
That distinction matters most when the approval is the record. If compliance signs off on a proof, that proof needs to be a faithful copy of what the member actually receives. When the captured layout and the live page disagree, you are approving something the audience never sees. R4 closes that gap, so the proof marketing uploads, the version legal reviews, and the page that goes live are the same thing.
Large projects now process files in parallel, not one at a time
Pillar: decision-based workflows.
For projects with large numbers of files, the Agent now processes files concurrently during the Rip and Slicing stages instead of one at a time. Total processing time no longer grows in step with file count. The concurrency is configurable with resource limits, so a single large project cannot monopolise the machine, and a failure on one file no longer stops the rest of the batch.
If a single campaign spans dozens of state variants, this is the difference between a review queue that opens promptly and one that makes everyone wait on the machine. The work reaches your reviewers sooner, so the human decisions, the routing, the escalations, the sign-offs, start sooner too.
Also in this release
R4 includes a set of smaller refinements: the first step of a workflow can now be an "Action step" and appear in dashboard filters, on-hold planning tasks can be shown or hidden consistently, the asset tree loads progressively instead of stopping at 50 items per folder, duplicate metadata columns collapse into one on the Home screen, and task decision disclaimers now save reliably. Two bug fixes are included: releasing an on-hold task with a release date no longer expires it immediately, and file uploads from a project-creation form no longer fail silently. Platform work this cycle also makes Aproove upgrades more reliable, which shortens upgrade windows without changing day-to-day use.
Where this lands for regulated teams
Consider a health plan sending Medicare member communications. The annual notice goes out as an HTML email and a set of web pages, and the wording changes state by state to meet each market's mandated language. Marketing produces the variants, compliance checks each one against the rules for its state, and legal signs off before anything publishes.
Two R4 changes fit that work directly. The HTML project type lets marketing bring each variant into Aproove as the exact file it will ship, so compliance and legal review the real thing rather than a converted approximation. Browser-accurate capture means the proof compliance approves matches what the member opens, which is the version that has to hold up if a regulator asks. And when the campaign is fifty variants rather than five, parallel processing gets them all into review without the queue stalling on volume.
FAQ
Do I need to repackage my HTML exports to use the new project type?
No. Aproove accepts either a plain index.html or a name built from the project, configurable per configuration, and falls back to index.html. Your existing export tooling should work as-is.
Does the browser-accurate capture change proofs I have already approved?
No. It applies to new proofs generated from a web link. It changes how future captures are rendered, so they match the browser, not anything already in your history.
Up next
R5 will continue the MS365 migration groundwork started this cycle, extend HTML proofing, and follow up on the Agent performance work.
