Automated Document Generation - VaultPDF Business Central

Overview

VaultPDF supports four ways to trigger document generation. All four paths funnel into the same Generation Queue - a persistent table that the VaultPDF Gen Processor job drains asynchronously.

The first three scenarios are covered in detail below. The interactive gallery is described in Processing Documents.

Architecture: The Generation Queue

The Generation Queue (VaultPDF Gen Request, table 77113) decouples the act of requesting PDF generation from the act of executing it. Any trigger path inserts a row; the VaultPDF Gen Processor (codeunit 77136), running as a recurring Job Queue entry, picks up Pending rows in batches and drives each one through the full VaultPDF pipeline (JSON build → SharePoint upload → Dispatcher call → Record Link).

Trigger (Post event / API call / AL code)
        ↓
  Gen Request row (Status = Pending)
        ↓
  Job Queue → VaultPDF Gen Processor (codeunit 77136)
        ↓
  SharePoint Upload + Dispatcher Call
        ↓
  Status = Completed  (or Failed / Dead after retries)

Key design properties:

• Trigger-agnostic - the processor does not know or care how a row was created
• Retry-safe - failed rows are retried up to VAULTPDF_GEN_QUEUE_MAX_RETRIES times before being marked Dead
• Concurrent-safe - the processor marks a row Processing before committing, so parallel Job Queue workers cannot double-process the same request
• Non-blocking for posting - the posting subscriber inserts Gen Request rows in a new transaction after posting commits, so a subscriber failure never rolls back a completed posting

Scenario 1: Auto-Generate on Post

Enable this flag on a template to have VaultPDF automatically queue a generation request whenever a Business Central document from that template's source table is posted.

Supported posting events:

• Sales Invoice posted from a Sales Order or Sales Invoice
• Sales Credit Memo
• Purchase Invoice
• Purchase Credit Memo

Scenario 2: External System Triggers Generation via API

Use this pattern when an external application - a custom ERP, an integration platform (Power Automate, Logic Apps, Boomi, MuleSoft), or a BC API client - creates or posts a BC document and then wants to trigger VaultPDF generation without requiring a user to open Business Central.

API Endpoint

POST /api/refractlogic/vaultpdf/v1.0/companies({companyId})/generationRequests

Authentication: Standard BC OData API authentication (OAuth 2.0 with Dynamics 365 Business Central scope, or Basic auth for on-premises).

Request body:

{
  "templateCode": "PINV-STANDARD",
  "tableId": 122,
  "docNo": "PINV-00001",
  "externalRef": "ERP-JOB-REF-789"
}

Common table IDs:

Response (201 Created):

{
  "requestId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "templateCode": "PINV-STANDARD",
  "tableId": 122,
  "docNo": "PINV-00001",
  "status": "Pending",
  "externalRef": "ERP-JOB-REF-789",
  "createdAt": "2026-06-20T14:32:00Z"
}

Polling for Completion

Poll the returned requestId to track processing:

GET /api/refractlogic/vaultpdf/v1.0/companies({companyId})/generationRequests({requestId})

Response when complete:

{
  "requestId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "status": "Completed",
  "blobPath": "RefractLogic/PurchaseInvoices/PINV-00001_PINV-STANDARD.pdf",
  "correlationId": "vpdf-corr-xyz",
  "processedAt": "2026-06-20T14:33:15Z"
}

End-to-End Example: External System Posts an AP Invoice

This is the canonical scenario: an external procurement system creates and posts a Purchase Invoice via the BC standard API, then triggers VaultPDF generation.

POST /api/refractlogic/vaultpdf/v1.0/companies({companyId})/generationRequests
Content-Type: application/json

{
  "templateCode": "PINV-STANDARD",
  "tableId": 122,
  "docNo": "PINV-00001",
  "externalRef": "PROC-SYSTEM-JOB-42"
}

Power Automate / Logic Apps Integration

To integrate with Power Automate or Azure Logic Apps, use the Business Central connector's Call a Bound Action action - or make a direct HTTP call to the OData endpoint using the HTTP with Microsoft Entra ID connector.

Recommended flow pattern:

1. Trigger: When a record is created/modified in Business Central (or on a schedule)
2. Action: POST to generationRequests using HTTP connector
3. Action: Do-Until loop polling GET generationRequests({requestId}) until status = Completed or timeout
4. Action: Send Teams/email notification with blobPath

Scenario 3: AL Developer Queues Programmatically

A partner or customer extension can queue generation requests directly from AL code without going through a user action or a posting event.

Using the Public API: QueueGenerationForPosting

The preferred way to trigger generation from AL code is VaultPDF Batch Dispatcher.QueueGenerationForPosting. This is the same path the built-in posting subscriber uses, so your requests participate in the same retry policy, queue monitoring, and extensibility hooks.

local procedure TriggerVaultGenerationForMyDoc(PostedHeader: Record "My Posted Header")
var
    BatchDispatcher: Codeunit "VaultPDF Batch Dispatcher";
    RecRef: RecordRef;
begin
    RecRef.GetTable(PostedHeader);
    BatchDispatcher.QueueGenerationForPosting('MY-TEMPLATE', RecRef);
end;

Calling QueueGenerationForPosting fires OnBeforeQueueForTable (described below) before inserting the Gen Request row. This means any partner or customer subscriber that intercepts or redirects posting-triggered generation will also apply to your call - consistent behaviour across the system.

Queue from a Custom Posting Flow (Low-Level)

If you need direct control over the Gen Request row fields, call QueueFromPosting on the table directly:

local procedure AfterMyDocumentPosting(var PostedHeader: Record "My Posted Header")
var
    GenRequest: Record "VaultPDF Gen Request";
    RecRef: RecordRef;
begin
    RecRef.GetTable(PostedHeader);
    GenRequest.QueueFromPosting('MY-TEMPLATE', RecRef);
end;

QueueFromPosting sets Source = Posting Event, captures the RecordId directly from the RecordRef, and resolves the Doc No. from the record's No. field. It is safe to call within a posting transaction - the Gen Request insert is committed independently.

OnBeforeQueueForTable

Published by "VaultPDF Posting Subscriber". Fires before the posting subscriber queues a generation request for a specific posted document table. Allows partners to skip, redirect, or substitute the template code before the Gen Request row is created.

[EventSubscriber(ObjectType::Codeunit, Codeunit::"VaultPDF Posting Subscriber",
  'OnBeforeQueueForTable', '', false, false)]
local procedure OnBeforeQueueForTable(
    TableId: Integer;
    var TemplateCode: Code[20];
    var IsHandled: Boolean)
begin
    // Example 1: Skip generation entirely for a specific custom table
    if TableId = Database::"My Custom Header" then begin
        IsHandled := true; // Prevent default queue; handle in your own subscriber
        exit;
    end;

    // Example 2: Redirect to a different template per company
    if (TableId = Database::"Sales Invoice Header") and (CompanyName = 'SUBSIDIARY') then begin
        TemplateCode := 'SINV-SUBSIDIARY';
        IsHandled := true; // Use the overridden template code instead of the default
    end;
end;

Setting IsHandled := true prevents the default posting subscriber from inserting a Gen Request row. Set it without changing TemplateCode to suppress generation completely, or set it after assigning a new TemplateCode to redirect to a different template.

Queue a Specific Record Internally

Use QueueInternal when triggering generation from a background codeunit, upgrade routine, or any non-posting context:

local procedure ReprocessDocument(DocNo: Code[20])
var
    InvHeader: Record "Sales Invoice Header";
    GenRequest: Record "VaultPDF Gen Request";
    RecRef: RecordRef;
begin
    InvHeader.Get(DocNo);
    RecRef.GetTable(InvHeader);
    GenRequest.QueueInternal('SINV-STANDARD', RecRef);
end;

Queue from an API (Server-Side Validation)

If you need to add validation logic before accepting an API-originated request, subscribe to the OnInsertRecord trigger override pattern by creating a page extension on VaultPDF Gen Request API (page 77138) and adding your logic in OnBeforeInsertRecord or a custom validation codeunit.

Configuring Maximum Retries

The Gen Processor retries failed requests up to a configurable maximum before marking them Dead (Max Retries Reached).

Navigate to VaultPDF System Settings and find the key VAULTPDF_GEN_QUEUE_MAX_RETRIES.

Log Retention and Auto-Purge

VaultPDF automatically purges old batch job entries and upload log rows to prevent unbounded table growth. The purge runs at the start of each VaultPDF Batch Job Runner execution (codeunit 77132).

Configure this key in VaultPDF System Settings after running Initialize Default Keys.

What gets purged:

• VaultPDF Batch Job Entry records with status Completed or Failed that are older than the retention threshold
• VaultPDF Upload Log rows linked to purged batch job entries
• VaultPDF Batch Detail Line rows linked to purged batch job entries

What is not purged:

• Queued, Running, or Partial batch jobs (regardless of age) - active records are never deleted
• Generation Queue rows (VaultPDF Gen Request) - these are managed independently via Purge Completed on the Generation Queue page

Monitoring the Generation Queue

Generation Queue Page

Open VaultPDF Generation Queue from the Tell Me bar to view all requests across all templates.

From the Template Card, the Generation Queue action in the action bar opens the same list pre-filtered to the current template.

Page columns:

Status color coding:

Actions

Troubleshooting