Here's something that bothered me for years working inside enterprise environments: the moment you need to generate a PDF, someone has to explain to Legal why your customer's invoice data is travelling to a third-party server in a region you've never heard of.
The vendor's answer is always "we're SOC 2 compliant." Which is fine. But SOC 2 doesn't mean your data didn't leave your building. It just means someone organised around that fact.
We built REFRACT because we thought there was a better answer, one where the question never comes up in the first place.
The Problem We Kept Running Into
Before this, I spent years implementing document generation for mid-to-large enterprises: construction companies, financial services firms, and legal practices. The same cycle repeated almost everywhere.
A business user needs a new document type. Say, a site inspection report with photos, QC notes, and a signature block. They go to IT. IT evaluates options. Then one of three things happens.
Option A: SSRS or Crystal Reports. A developer spends two weeks building a report. The template is rigid. Any nested data, say, inspection items grouped by location with sub-items under each, requires subreports that are fragile and slow. Six months later the business wants a small change: add a computed total, update the logo. Back to the developer queue. The template lives inside SQL Server Reporting Services or a legacy app server, and nobody knows which version of the template produced which document anymore.
Option B: Word mail merge. Someone builds a .docx template with merge fields. It works for simple letters. The moment the data has variable-length line items, or you need totals that aren't pre-calculated in the source system, it falls apart. Word doesn't compute. Word merges. If the payload has 40 line items one day and 2 the next, the table formatting breaks. If a field is null, the layout corrupts. Someone ends up manually fixing PDFs before they go out.
Option C: A SaaS PDF API. There are plenty, and they come in two flavours.
The first accepts a JSON payload and returns a rendered PDF. Fast to integrate, decent templates. But your invoice payload, which contains your customer's name, order details, and pricing, now travels to a third-party server. For a construction company generating safety reports with site photos, that data lives on someone else's infrastructure, even briefly. Legal and compliance teams are not enthusiastic.
The second accepts an HTML document and uses a headless browser to render it to PDF. This approach feels appealing at first because you can style documents with CSS and the integration looks familiar. The problem is non-determinism. Run the same HTML through the same tool twice and you may get subtly different output: slightly different line breaks, misaligned table columns, or fonts that render at minutely different point sizes depending on which version of the headless browser is running. In a document that carries a digital fingerprint for compliance, or one that two people are comparing side-by-side to resolve a dispute, "almost identical" is not good enough. You cannot confidently say two documents are the same without generating them again and hoping.
The result in every case: fragile documents, high maintenance costs, and a compliance conversation that never quite goes away.
What We Actually Wanted
We wanted something specific:
- The rendering engine runs inside the customer's subscription. Not ours. Theirs. A REFRACT Edge Engine they deploy to their own Azure region. A storage account they own. Rendering never sends document content outside your Azure subscription.
- Templates that a business analyst can edit. Not a developer. Someone who understands the document but doesn't want to write SSRS expressions or fiddle with Word field codes.
- Real support for nested data. Not a workaround. Not subreports. A table that can render orders, line items, and serial numbers with subtotals at each level, styled consistently, and without page break issues.
- Version control that works. Templates as
.rpkgfiles, portable JSON that you can commit to Git, export from the Designer, import anywhere, and know exactly which version produced which document.
That's it. That was the whole brief.
The Zero Document Egress Decision
The zero document egress architecture wasn't a marketing decision. It came from a specific conversation with a client in the construction sector who asked, before signing anything: "Can you guarantee that our site photos never touch a server we don't control?"
The answer we wanted to give was yes, for document content, and that only works if the rendering happens in the customer's subscription.
With REFRACT, the entire processing chain, The Dispatcher, The REFRACT Engine, the template files, the generated PDFs, and the audit logs, all live inside the customer's Azure subscription. Rendering never sends document content outside your Azure subscription, and we are not in the loop.
A .rpkg template file looks like this:
{
"templateId": "site-inspection-report-v3",
"templateSettings": {
"locale": "en-GB",
"dateFormat": "DD MMM YYYY",
"timezone": "Europe/London"
},
"theme": {
"primaryColor": "#0D3B66",
"accentColor": "#0077B6",
"fontFamily": "Roboto"
},
"layoutSchema": { "...": "component tree defining what appears in the document" },
"hierarchyRules": { "...": "per-level styling and computed fields for nested tables" }
}
It's a JSON file. Commit it to Git. Diff it. Roll it back. The rendering topology that processes it sits entirely inside your subscription:
Customer's Microsoft 365 Tenant
│
├── REFRACT Compute Node ←── The REFRACT Engine (deployed to customer subscription)
├── SharePoint ←── Templates, payloads, generated documents
└── Azure Blob Storage ←── Archive, audit logs
The source system drops a payload into SharePoint. The Dispatcher picks it up, fetches the template, passes it to The REFRACT Engine, and writes the PDF back to SharePoint. All of it runs in the customer's subscription. Documents are generated and stored in your Azure subscription. Every document download, for REFRACT eSign, Delivery, and Workflow alike, redirects the browser to your own Dispatcher or SharePoint site, which serves the bytes directly; the REFRACT-hosted portal never receives them. Signature images and field values, and REFRACT Workflow attachment uploads, are the two exceptions: they pass through the portal in memory on their way to your Dispatcher and are never written to its storage. The portal keeps signer contact details, one-time-code hashes and session state. Invitation and one-time-code emails are sent through a REFRACT shared notification service, which receives recipient email addresses and names, requester details where provided, document names, the rendered message body, any custom message text, one-time codes, links and correlation identifiers. License validation sends your tenant identifier, license key, identity token and deployment address. Usage reporting sends counts. Neither includes document content.
Why This Matters More in 2026
A few years ago, the conversation about data residency was mostly limited to regulated industries: financial services, healthcare, and government. That's changed.
Construction firms are generating safety audit documents with geo-tagged photos that are legally sensitive. Legal practices are producing contract packs with clauses that can't touch external servers without explicit client consent. Mid-market manufacturing companies are under pressure from their enterprise customers to demonstrate supply chain data governance.
The regulatory pressure is real. GDPR enforcement has become more aggressive, not less. Sector-specific frameworks in the UK and EU are tightening. And the reputational risk of a data incident involving customer documents, even a brief transit through a third party, has become something boards actually talk about.
The "just use a SaaS API, it's fine" answer gets harder to defend every year.
What We Decided to Build
We didn't try to out-feature every PDF library on the market. We focused on the specific problems that kept causing pain in enterprise environments.
Layout that holds under real data. Whether a table has 2 rows or 2,000, whether a field is null or overflows to multiple lines, the layout adapts without breaking. We spent a disproportionate amount of time on page break logic, because "the table split awkwardly across pages" is genuinely the most common complaint about auto-generated documents in enterprise environments.
Nested data as a first-class problem. The Hierarchical Table renderer handles five or more levels of nesting with per-level styling, conditional field visibility, computed subtotals at each level, and group headers. It's the part of the product we're most proud of technically.
Templates that don't require a developer to change. The Designer lets a business analyst adjust column widths, change fonts, add a logo, and reorder sections, then export a new .rpkg file that goes straight back into SharePoint. No code deployment. No developer queue.
Audit trails designed to support compliance review. Every render writes a structured event to the tenant's audit log: template ID and version, timestamp, payload hash, who triggered it, and where the output was stored. Not because we needed to build it, but because the first enterprise customer asked where they could prove what was generated and when.
Read the follow-up post for a technical look at what The REFRACT Engine actually produces, from the .rpkg format and Hierarchical Tables to Signature Zones, Supplementary Annexes, and audit-grade output.
If you're evaluating document generation options and the data residency question is on your list, we're happy to walk through the architecture. Reach us at [email protected].