Agentforce for Portwood puts a Generate with Agentforce button in the Visual Designer. Tell it what you want in plain English and it writes the HTML template: built around your own fields, in correct Portwood syntax, within what the PDF engine can actually render. Then it checks its own output against that engine and tells you what it had to fix.
As of v1.1.0 the extension is free for everyone, with no installation key — same terms as Portwood itself. It requires Portwood 3.46+ and Einstein / Prompt Builder in your org; Salesforce enforces both at install.
Every feature of the app works exactly the same whether you install this extension or never touch it: every merge tag, loop, aggregate, barcode, signature, bulk run and Flow action. It doesn't unlock capability. It removes the afternoon you'd spend writing the template by hand, and it makes sure what comes back will actually survive the PDF engine.
A Statement of Work, start to finished PDF. The breakdown underneath is the honest sequence, including the step you do first, before the agent is involved at all.
Prefer to watch it on YouTube? Open the demo in a new tab → Nothing loads from YouTube until you press play.
In Portwood's visual query builder: base object, fields, parent lookups, child relationships. Point and click, no SOQL. This has to exist first, because it's what the agent writes against.
Open the Designer, press Generate with Agentforce, and say what you want in sentences. Everything it needs to know about your org and the engine goes with it. You don't assemble anything.
Built strictly from the fields your query returns. It won't reach for one you haven't got, because a tag with nothing behind it renders as empty space in the finished document.
Before anything is saved, the output is checked against the PDF engine's measured limits, repaired where it can be, and you're told what changed. Then it lands on the canvas.
Editing is the default, not starting over. Once a template is on the canvas, your next instruction is sent with the current body, unsaved edits included, so it revises rather than regenerates. Every edit is diffed against what went in, and if a merge tag went missing you're told which one, by name. Generation runs 10–25 seconds and consumes Einstein usage against your org.
Ask any general model for print HTML and it returns flexbox, rounded corners and translucent tints. We asked for CSS 2.1 explicitly and it still emitted display:flex three times in one generation. Portwood renders with Flying Saucer, which silently ignores all of that. So every generation is checked against what the engine measurably supports before it is saved.
Translucent rgba() tints composited over white into flat hex, because they don't fall back to a color: they resolve to nothing and the panel renders invisible. Gradients collapsed to their first stop, var() substituted, numeric font weights mapped, Visualforce-style {!Field} rewritten, markdown fences stripped.
border-radius in every form, box-shadow, text-shadow, opacity, transform, calc(), CSS columns, @media, <script>, <svg>, external stylesheets. The engine ignores them, so deleting them changes nothing on the page and leaves the source honest.
Things it won't silently rewrite, because the fix is a judgment call: display:flex or grid that needs a real table rebuild, position:absolute, ZapfDingbats, a {PageNumber} stranded in the body, unbalanced braces. Flagged for you, left alone.
The single most common thing a model gets wrong: it wraps {#Rel} around the whole <table>, which repeats headers and all, once per child record. The validator moves the loop tags into the first and last cells of the data row where they belong.
A bad generation is obviously bad. A bad edit is invisible: a dropped {Amount:currency} renders as nothing and the canvas looks fine. Every edit is compared against what went in, and lost tags, truncation, a dropped @page and vanished tables are reported specifically.
The model is reached through ConnectApi, not an HTTP callout, so Limits.getCallouts() stays at 0. It's Salesforce AI in your own org, under your org's own Einstein configuration. Portwood stays 100% native, exactly as it was.
Better to read this before you install than after.
The Visual Designer is for HTML templates, and the Agentforce button lives in the Designer, so that's the whole of what the agent authors. Word, Excel and PowerPoint templates you still build by hand in Word, Excel and PowerPoint, exactly as before.
This is a limit on authoring, not on Portwood. The engine still merges and outputs Word, Excel, PowerPoint and PDF just as it always has, and nothing about your existing templates changes. Office templates are hand-built in Office, and the User Guide covers the merge syntax for them.
The agent writes against a query config that already exists. It can only use fields your query actually returns, since anything else would render as empty space, so there has to be a query before there can be a template.
You build that first, in the visual query builder: base object, fields, child relationships. It's point-and-click rather than SOQL, but it's a real step and the agent does not do it for you.
It writes a template. It doesn't build the record-triggered Flow that fires it, the scheduled bulk run, the e-signature routing, or the integration on the other end.
That's implementation work and it goes where it always did: the User Guide if you're doing it yourself, or our implementation partners if you'd rather not.
It won't walk you through its reasoning or annotate the syntax it chose. You get a template, not a lesson. The one thing it does explain is what the validator changed, and why. That report you always get.
If you want to understand what's underneath, and it's worth knowing since you'll hand-edit eventually, the free User Guide is where that lives.
Each generation takes 10–25 seconds and consumes Einstein usage against your org, on your org's own entitlement. We don't meter it; Salesforce does.
Pick the model deliberately. Prompt Builder defaults to GPT 5 Mini, which we measured applying multi-part edits only partially and sometimes replying "I don't know." instead of returning a document. A stronger model applied 4/4 changes every run.
The base package is the app. The extension is the provider and the prompt template. Both are free, and neither asks for a key.
Version 3.46 or later, from the AppExchange listing, the same place everyone installs Portwood. Already running it? Take the latest anyway, since the extension depends on 3.46+. Upgrading is a normal managed-package install: templates, query configs, generated documents and permission set assignments all carry through untouched.
Prefer the CLI? sf package install --package 04tVx000000s7yzIAA --wait 10 --target-org your-org
Version 1.1.0 or later. Carries the Einstein provider class and a ready-made prompt template, so there's nothing to write or configure. Installing it is a normal managed-package install: no password, no code to request, nothing to sign up for first.
Trying it in a sandbox first is the sensible move, and it's the same install either way. Prefer the CLI? sf package install --package 04tVx000000zxUbIAI --wait 10 --target-org your-org
Not packaging strategy, but a hard platform constraint, and we measured both halves of it. An Apex class referencing ConnectApi.EinsteinLLM builds fine but is refused at install in any org without the Einstein entitlement. A packaged GenAiPromptTemplate is worse: it makes the entire package declare a feature requirement, so every customer without Einstein would be blocked from installing Portwood at all. Keeping both outside the base package is precisely what lets Portwood stay installable everywhere, for everyone, for free.
Install the base first. Salesforce enforces both the Portwood 3.46+ dependency and the Einstein requirement at install time, so a wrong order or a missing entitlement fails fast rather than half-installing.
The extension used to be the one thing behind a password. It isn't any more: from v1.1.0 it installs free, with no key, on the same terms as Portwood itself. Nothing to buy first, nothing to request, no account to open.
Build as many as you want. We don't add a ceiling; your Salesforce org and its Einstein usage are the only limits.
Every revision, reword and restyle. Iterating is the whole point, so it isn't metered.
Every new version as it ships, to everyone, at no cost. No install codes to chase, no version you get stranded on.
The parts the agent can't do. It writes a template; it doesn't debug the query that won't cooperate, the layout that renders wrong on page three, or the Salesforce release that moved something underneath you. A membership is a private channel in Slack or Microsoft Teams with the people who build Portwood, on a one-business-day target. It's help with your org, and it's entirely optional — the app and this extension are complete without it.
Generation runs on your org's own Einstein entitlement, so Salesforce meters the usage and we never do. Everything the agent writes is an ordinary Portwood template in your org, yours to keep and edit by hand whether or not the extension stays installed.
ConnectApi rather than an HTTP callout, so Limits.getCallouts() stays at 0. It's Salesforce AI running in your own org under your own Einstein configuration, and Portwood keeps its "no external services" guarantee intact. We never see the prompt or the response. Document generation itself is completely unchanged: merging and PDF rendering happen in-org, as always.display:flex three times in a single generation. So every result is checked against the PDF engine's measured limits, repaired where a safe equivalent exists, stripped where the engine would ignore it anyway, and flagged where the fix needs your judgment. You're told what changed and why, every time. Then you preview it as a PDF against a real record before it goes anywhere near a customer.@page and vanished tables. It never blocks or silently rewrites, since losing a tag can be exactly what you asked for. Previous bodies stay in the template's file history, and the raw model output is staged separately so it can always be compared against what was saved.DocGenAiProvider is a global interface in the free base package. Implement it, point Portwood Settings > AI Provider Class (named DocGen Settings before 3.50) at your class, and Portwood will use that instead. The extension is simply the turnkey version: the Einstein implementation plus a ready-made, activated prompt template, so there's nothing to write or configure. Which model Prompt Builder uses is also yours to choose, and worth choosing, since it defaults to GPT 5 Mini, which we measured applying multi-part edits only partially. See User Guide section 5.7.11.04tVx000000zxUbIAI. Nothing else about the install changed: Salesforce still enforces the Portwood 3.46+ dependency and the Einstein requirement at install time.