VaultDelivery

VaultDelivery provides secure document dispatch and delivery for VaultPDF-generated documents. Send documents to external recipients via time-limited access links or write directly to SharePoint, with full access auditing and proof of delivery.

VaultDelivery handles the final stage of the document lifecycle, getting a rendered PDF securely to an external recipient or writing it to a designated SharePoint location, with a full tamper-evident delivery audit trail.

Enterprise Feature

VaultDelivery requires the vaultDelivery feature gate on your licence.

Data Sovereignty — What Crosses the Boundary and What Never Does

VaultDelivery is built on a data sovereignty model, not a simple "no-egress" rule. The distinction matters:

What never leaves your Azure subscription: Document content, rendered PDF bytes, form field values, SharePoint file paths, PII data fields, and file attachments are never transmitted outside your tenant under any configuration.

What is designed to cross (metadata only): The notification infrastructure carries the minimum metadata required to perform delivery — correlationId, recipient email address, portal access link, and notification type. No document content is included. This is intentional by design.

For customers who require zero data transit through VaultPDF infrastructure for any reason, customer-acs mode sends notifications directly from your Azure tenant — VaultPDF infrastructure is not involved at all.

What VaultDelivery Does

Secure Email Delivery

Recipients receive a notification email with a time-limited access link. The document is never attached directly to the email; it is retrieved through the secure portal.

Token-Gated Access

Each delivery session issues a unique, cryptographically signed access token. Tokens carry an expiry and are revocable by the initiator at any time.

OTP Verification

Optional one-time passcode challenge before a recipient can download the document, providing an additional layer of identity assurance.

Access & Download Auditing

Every open, view, and download event is recorded in the immutable audit log, providing verifiable proof of delivery for compliance purposes.

SharePoint Write-Back

Documents can be delivered directly to a designated SharePoint library and folder, without requiring external recipient interaction.

Configurable Expiry

Access links expire after a configurable window (default 7 days). Expired sessions are recorded in the audit log and the document becomes inaccessible via the delivery portal.

Delivery Modes

Mode	Description
`secure-email`	Sends a notification email to each recipient with a unique, time-limited access link to the delivery portal. The document is retrieved on demand.
`sharepoint`	Writes the rendered PDF directly to a designated SharePoint document library and folder. No recipient email is sent.
`both`	Combines secure email delivery and SharePoint write-back in a single session.

Email Provider Configuration

The EMAIL_PROVIDER environment variable controls how all outbound notification emails are sent across the Vault Platform — not just VaultDelivery. It applies to VaultDelivery invitations and OTP codes, VaultESign signing invitations and reminders, and VaultWorkflow participant notifications. Two modes are supported.

`vault-shared` (Default)

The Dispatcher queues notification messages to your Azure Service Bus. Your Processor picks them up and relays each message to the VaultPDF notification service (HMAC-signed, metadata only). VaultPDF's Azure Communication Services instance handles the actual email delivery.

Customer Azure Subscription                          VaultPDF Subscription
──────────────────────────────────────   ────────────────────────────────────
Dispatcher
  └─ enqueue (metadata-only message)
       └─ [Customer Service Bus]
             └─ Processor NotificationWorker
                  └─ POST /api/internal/email
                       (HMAC-SHA256 signed, metadata only:
                        recipient email, portal link, notification type)
                                                    └─ VaultPDF notification service
                                                          └─ ACS (email / SMS)

The HMAC-signed POST carries only: recipient email, portal link, notification type, and document name. Document content, file bytes, signatures, and form field data are never included.

`customer-acs` (Zero Transit Mode)

Your Processor sends all notification emails directly through your own Azure Communication Services instance. The VaultPDF notification service is never called — no notification metadata transits VaultPDF infrastructure under any Vault Platform feature.

Customer Azure Subscription
──────────────────────────────────────
Dispatcher
  └─ enqueue (metadata-only message)
       └─ [Customer Service Bus]
             └─ Processor NotificationWorker
                  └─ sendViaCustomerAcs()
                       └─ Your own ACS
                            (ACS_EMAIL_ENDPOINT + ACS_EMAIL_KEY)

customer-acs scope: VaultDelivery and VaultWorkflow fully, VaultESign partially

Setting EMAIL_PROVIDER=customer-acs on both your Dispatcher and Processor routes all notification queue emails through your own ACS — this covers VaultDelivery invitations and OTP codes, VaultESign OTP codes and completion notifications, and VaultWorkflow participant notifications.

VaultESign invitation emails (initial and sequential) are currently also sent directly by the eSign Portal via Vault Shared Services ACS, independently of this setting. The notification queue path respects customer-acs, but the portal's direct send is not yet suppressed. If strict zero-transit of signer invitation emails is required, evaluate whether this meets your needs.

Required environment variables for customer-acs mode:

Variable	Set on	Description
`EMAIL_PROVIDER`	Dispatcher + Processor	Set to `customer-acs` on both Function Apps
`ACS_EMAIL_ENDPOINT`	Dispatcher + Processor	Your ACS endpoint URL
`ACS_EMAIL_KEY`	Dispatcher + Processor	Your ACS access key
`ACS_EMAIL_FROM`	Dispatcher + Processor	Verified sender address (e.g. `[email protected]`)

Choosing a Mode

	`vault-shared`	`customer-acs`
Setup required	None (default)	ACS resource in your tenant; set on both Function Apps
VaultPDF infrastructure in notification path	Yes (metadata only — email address, portal link, notification type)	No — VaultPDF infrastructure not involved
Document data crosses boundary	Never	Never
Applies to	VaultDelivery, VaultESign, VaultWorkflow	VaultDelivery, VaultESign, VaultWorkflow
Use when	Standard deployments	Strict zero-transit requirements for any notification metadata

Delivery Session States

State	Description
`pending`	Session created; notification email not yet enqueued.
`sent`	Notification email successfully enqueued (set immediately after comms queue write).
`opened`	Recipient opened the delivery portal.
`downloaded`	Recipient downloaded the document.
`expired`	Session TTL elapsed before the recipient accessed the document.
`revoked`	Session manually revoked by the initiator.

Proof of Delivery

Each access and download event is appended to the immutable audit JSONL blob for the document's correlationId. This provides a timestamped, tamper-evident delivery record that can be exported from the Lifecycle Workspace or queried via the audit API.

Recorded events include:

Event	Description
`delivery-created`	Session created; access link issued.
`delivery-opened`	Recipient opened the portal and the document was displayed.
`delivery-downloaded`	Recipient downloaded the PDF.
`delivery-expired`	Session expired without access.
`delivery-revoked`	Session revoked by initiator.

Batch Dispatch

VaultDelivery is used as the delivery layer for VaultDispatch governed batch operations. Batch dispatch is initiated via POST /api/render with a template that has distribution.mode configured. The Dispatcher validates and queues the batch; after approval (or immediately if requireApproval: false), the Processor picks up the queue message and processes each record independently — rendering a PDF per record and issuing a DeliveryJobMessage to the vaultpdf-delivery Service Bus queue for each recipient.

Batch Size

Each batch dispatch processes records sequentially within the processor queue message. For large batches (over a few hundred records), the payload is written to Blob Storage (vault-dispatch-payloads container) at intake time and loaded by the Processor from there — the queue message carries only the batchId reference.

Scenarios

Scenario 1 — Invoice Delivery to External Vendor

Business context: After AP approves a purchase order, the signed invoice PDF is
delivered securely to the vendor via email link. The vendor can download it for
7 days; access is logged for audit.

POST /api/delivery
{
  "correlationId": "inv-2026-0601-acme",
  "documentName": "Invoice INV-2026-0601.pdf",
  "pdfBlobPath": "generatedDocuments/2026/06/inv-2026-0601-acme.pdf",
  "mode": "secure-email",
  "recipients": [
    { "email": "[email protected]", "name": "ACME Accounts", "role": "vendor" }
  ],
  "requesterOrg": "Contoso Ltd",
  "message": "Please find your invoice attached. This link expires in 7 days.",
  "expiresInHours": 168
}

Flow:
  Session created → notification email queued → vendor receives email with portal link
  ├─ Portal link: opens portal.vaultpdf.io UI (Vault Shared Services)
  │   → portal renders session metadata only (document name, expiry, state)
  │   → portal server never buffers document bytes
  Vendor opens link → delivery-opened event recorded
  Vendor downloads PDF
  ├─ PDF download: portal calls your Dispatcher SAS endpoint
  │   → Dispatcher issues time-limited SAS URL → browser fetches directly from your Blob Storage
  │   → document bytes: your Azure Blob Storage → recipient browser only
  delivery-downloaded event recorded
  Audit JSONL updated: proof of delivery for SOX/AP audit trail
  Session expires after 7 days → further access refused

Scenario 2 — Confidential HR Document with OTP Verification

Business context: HR sends an employment contract to a new hire. The document
contains personal data; OTP verification adds a second layer of identity assurance
before the recipient can download.

POST /api/delivery
{
  "correlationId": "hr-contract-2026-jsmith",
  "documentName": "Employment Contract — J. Smith.pdf",
  "pdfBlobPath": "generatedDocuments/hr/hr-contract-2026-jsmith.pdf",
  "mode": "secure-email",
  "recipients": [
    { "email": "[email protected]", "name": "J. Smith", "role": "employee" }
  ],
  "requesterOrg": "Contoso Ltd",
  "expiresInHours": 72,
  "requireOtp": true
}

Flow:
  Session created → invitation email sent
  Recipient opens portal link → document metadata shown
  ├─ Portal serves: document name, expiry, requireOtp flag — no document bytes
  │   → portal server never buffers document content
  Recipient requests OTP → 6-digit code sent to [email protected]
  Recipient enters OTP (10-minute expiry, 5 attempts max)
  OTP verified → SAS download URL issued → PDF downloaded
  ├─ PDF bytes: your Dispatcher → SAS URL → recipient browser → your Azure Blob Storage
  │   → portal server not in document byte path at any stage
  Audit: OTP verification timestamp + download event recorded
  Personal data (email) stored AES-256-GCM encrypted in your Table Storage

Scenario 3 — Batch Contract Distribution After Approval

Business context: After a VaultDispatch batch is approved and processed by the
Processor, each record in the batch receives its rendered PDF via a delivery session.
This is triggered automatically by the Processor's DeliveryJobMessage queue handler
— no manual API call is required per recipient.

Processor (automatic, triggered from vaultpdf-delivery queue):
  For each record in the batch:
    Generates deliveryId + HMAC-signed access token
    Writes DeliverySessionEntity to Table Storage
    Enqueues CommJobMessage → notification email sent to recipientEmail field

What crosses to Vault Shared Services (vault-shared mode):
  Recipient email address — for ACS delivery
  Portal access link — time-limited token
  Document name — shown in email and portal
  ├─ No document bytes in any of the above — portal serves UI metadata only

What stays in your subscription:
  Document bytes — never transmitted externally
  ├─ PDF download: browser → your Dispatcher SAS endpoint → your Azure Blob Storage
  │   → portal server not in document byte path at any stage
  All delivery session state and audit events
  Proof of delivery for each recipient

API Reference

Full reference for creating delivery sessions, querying session state, revoking access, and recording access events.

VaultDelivery API Reference

VaultDelivery

API Reference

On this page