In Tech Thursday with SNOK we take one technology and check what it actually changes in our clients’ work. Today: the new Document Understanding preview which at first glance looks like a list of minor improvements - and in practice closes three architectural gaps that enterprise document-processing teams kept tripping over.
The versions in question: UiPath.DocumentUnderstanding.Activities 3.4.0-preview, UiPath.PDF.Activities 4.4.0-preview and UiPath.IntelligentOCR.Activities 7.4.0-preview, plus the Public Preview of IXP models as solution resources (IXP release notes, 23 July 2026). Let us take them in turn.
Gap one: documents were locked inside XAML
Until now, document classification and extraction lived in the world of visual workflows. Teams that write automations in C# - with loops, LINQ, exception handling and unit tests - had to return to the canvas whenever documents entered the picture.
As of 26.7, the DU and PDF packages expose their capabilities as services callable directly in coded workflows. The du service covers classification, data extraction and the human-in-the-loop validation artifacts; the pdf service covers the whole toolbox: reading text, counting and splitting pages, merging files, extracting attachments and converting documents to PDF. A complete classify-then-extract flow is now a dozen lines of C#, without a single XAML file.
Why does this matter right now? Because code is the language coding agents move in most fluently. We recently wrote about how coding agents are changing the work of UiPath teams - and document processing was a blind spot on that map. After this release an agent can generate, test and maintain document logic the same way it handles any other code.
One caveat from practice, confirmed in the discussion under the announcement: the suspend/resume mechanism (persistence) does not work inside coded workflows. Design human validation so that the validation artifacts are created in code, but the actual process suspension happens outside it - otherwise the architecture will surprise you during integration testing, not earlier.
Gap two: the model lived a separate life from the automation
Anyone who has deployed Document Understanding across dev, test and production environments knows the pain: the workflow travels in a solution package, while the extraction model has to be moved and configured separately, environment by environment.
In Public Preview, IXP models become a regular solution resource: they appear in the Resource Explorer in Studio Web, are packaged and versioned with everything else, and travel with the whole package at deployment time. The Extract Document Data and Document Understanding Project Extractor activities gained a “Use Solution Resource” toggle - switch it on, pick the model, and from that moment the model’s lifecycle is the same lifecycle as the automation’s.
It sounds like a detail, but details like this decide whether an agent or automation makes it from proof of concept to production - governance and repeatable deployments are usually the harder half of the project, not the extraction itself.
Gap three: the pipeline assumed a “ready” PDF
The reality of an inbox looks different: an invoice arrives as an email body, a report as HTML, a confirmation as plain text. Three new activities - Convert Email to PDF, Convert HTML to PDF and Convert Text to PDF - normalise these formats into PDF, the shape the rest of the pipeline expects. They work in both Windows and cross-platform projects, with a shared set of rendering options.
The pattern this unlocks: an email trigger fires, the message is converted to PDF, data gets extracted - a complete mailbox-to-structured-data path with no manual steps in between.
A separate, strong building block is the Extract Attachments From PDF activity (available since the PDF package 4.3.0, late June), which pulls embedded XML files out of a document. This is the daily reality of e-invoicing: in Poland the domestic flow has moved to structured XML in KSeF (Poland’s mandatory e-invoicing system), while foreign suppliers still send hybrid invoices such as ZUGFeRD or Factur-X - a PDF with XML sewn inside. Instead of OCR-ing an image of such an invoice, you now take the ready structured data out of it with a single activity.
A bonus for compliance teams: field-level redaction
The Redact Document activity gained a public RedactionOptions argument - granular control over how each field is redacted: full fill or strikethrough, colour and opacity, plus redaction codes printed over the blacked-out areas, exactly the way legal and audit practice does it. An entry with an empty field identifier acts as the default rule for every phrase on the provided list.
For companies working with personal data this is tangible: document anonymisation stops being a separate manual stage and becomes a policy written into the automation.
What to do with it
This is a Preview release - UiPath explicitly recommends evaluating it in non-production environments, and we second that. A sensible plan for the coming weeks:
- Inventory the places where documents enter your processes - especially those where someone manually saves emails as PDFs or retypes data from hybrid invoices.
- If you have a team writing C# or working with coding agents - run a pilot with the
duandpdfservices on one real document type, with human validation designed outside the coded workflow. - If you deploy DU through Solutions - test IXP models as solution resources on the dev-test path; it is the shortest route to repeatable deployments.
As a UiPath Platinum partner, SNOK - an IT consulting firm from Warsaw - helps take this road: from a review of your document stream, through architecture, to production with governance that passes an audit. Get in touch if you would like to see these mechanisms working on your own documents.