For IT & Security
“Native” with nothing to take on faith.
Rendering happens in your org, in-transaction, as the requesting user. No callout, no rendering server, no sub-processor, nothing to whitelist. The security review is short because the architecture is.
The complete data-flow diagram
Your Salesforce org
Record data → render → ContentVersion
One box. There is no second box. No arrows leave it, which is the entire diagram and the entire DPA conversation.
Every vendor says “native.” Then you read the egress logs.
You’ve run this review before. The deck says “100% native Salesforce.” The egress logs say there’s a callout to the vendor’s rendering service, which means a DPA to negotiate, a sub-processor to track, an endpoint to whitelist, and a data-residency question with a paragraph-long answer.
Sometimes you don’t even need the logs; the output gives it away. A “native” tool whose PDFs are stuck at an old PDF version, whose styling tops out at legacy CSS, with a documented font ceiling, is describing a legacy renderer somewhere, whatever the deck says.
The architecture is the answer to the questionnaire.
In-org, in-transaction
Rendering executes inside your Salesforce org, inside the transaction that requested it. There is no rendering server because there is no rendering callout. Your org's data has nowhere else to go; we have no cloud to put it in.
Runs as the requesting user
Every render executes under the requesting user's permissions. Field-level security, sharing rules, record access: enforced by the platform on every document, not promised by a contract. A rep cannot generate a document containing data that rep cannot see.
Nothing to whitelist, no sub-processor, no egress
Your DPA review has no LinePDF rendering clause to write, because there's no processing outside your org to govern. The data-flow diagram is one box, and you already audited it: it's Salesforce.
The agent inherits the guarantee.
No vignette needed; the architecture is the moment. LinePDF’s employee-agent actions run as the logged-in user, so when a rep asks their agent for a document, the render executes under that rep’s FLS and sharing. The agent can only produce what the rep could already see.
An external-render vendor cannot make that guarantee. Their server either holds elevated credentials or it doesn’t render. Ours doesn’t exist.
The receipts
- 01The security page is the published architecture: full install footprint, what the package can and cannot do, template sanitization, no diagram hand-waving. It prints as a one-pager for your review file.
- 02Verifiable claims, not marketing: search the package source for HttpRequest (zero occurrences), check Setup for connected apps (none added), check OAuth policies (no scopes requested).
- 03AppExchange security review: in progress, not passed. We publish the status as it is, and we recommend sandbox-first installs until it clears.
Close this review in one sitting.
The one-pager and the architecture page are everything your review needs. No NDA, no call required, and the founder answers security email personally.
Free tier: unlimited documents, 3 templates, full line-item engine. No card, no minimums, no sales call. AppExchange listing in security review.