VaultWorkflow
VaultWorkflow is a governed multi-step document workflow engine. It orchestrates structured data collection, validation, approval routing, and final PDF sealing, all within your Azure tenant.
VaultWorkflow provides structured, form-driven document generation with multi-step data collection, schema-defined validation rules, conditional approval routing, and cryptographic sealing to a final PDF.
Enterprise Feature
VaultWorkflow requires the vaultWorkflow feature gate on your licence. Contact your licence administrator if this feature is not enabled on your tenant.
What VaultWorkflow Does
Unlike direct render requests (where a caller submits a complete payload), VaultWorkflow builds the document payload incrementally across multiple participants and steps. When all steps are submitted and validation passes, the workflow routes to the designated approver(s), and on approval the processor seals the final PDF using the full VaultPDF render engine.
Multi-Step Data Collection
Schema-defined steps guide participants through structured form fields. Each step is saved independently; participants can return and continue.
Schema Validation
YAML-defined validation rules evaluate collected data before submission. Error-severity rules block advancement; warning-severity rules surface to the approver.
Conditional Approval Routing
Routing rules evaluate collected data to determine the correct approver(s). Supports first-match, sequential, and parallel routing modes.
Review & Change Requests
Reviewers can return a submission with structured change requests. Participants address each item and resubmit without restarting the workflow.
Governed PDF Sealing
On approval, VaultWorkflow enqueues a seal message. The processor renders the final PDF using the workflow template and the complete collected data snapshot.
Post-Seal Automation
VaultESign and VaultDelivery can be triggered automatically after sealing, configured in the workflow session at creation time.
Workflow Lifecycle States
A workflow instance moves through the following states:
| State | Description |
|---|---|
draft | Created but not yet started by the participant. |
in-progress | Participant is actively filling steps. |
validating | Server is evaluating schema validation rules (transient). |
validation-failed | One or more error-severity rules failed. Participant must correct data. |
pending-approval | All steps submitted and validation passed. Awaiting approver action. |
under-review | Approver has opened the submission for review. |
changes-requested | Approver returned the submission with structured change requests. |
approved | Approver accepted the submission. Seal is being queued. |
sealing | Seal message enqueued; processor is rendering the final PDF. |
complete | Final PDF sealed and stored in Blob Storage. |
rejected | Approver rejected the submission. No PDF is produced. |
escalated | Submission was escalated to a secondary approver. |
cancelled | Workflow was cancelled before completion. |
Step Lifecycle States
Each step within a workflow tracks its own state independently:
| State | Description |
|---|---|
pending | Not yet started by the participant. |
in-progress | Participant has opened the step. |
submitted | Participant completed and submitted the step. |
approved | Step accepted during review (sub-flow). |
rejected | Step returned during review (sub-flow). |
Portal Access & OTP
When a workflow is created, the dispatcher issues a portal access token (HMAC-signed, 4-hour TTL) for the participant. If requireOtp is enabled in the session, the participant must verify a one-time passcode sent to their email before accessing any steps.
Token Security
Portal tokens are single-use per session and scoped to a specific workflow instance. They are not reusable across workflows and cannot grant access to other dispatcher endpoints.
Post-Seal Actions
The workflow session can carry postSealActions to trigger downstream services automatically after the PDF is sealed:
{
"postSealActions": {
"esign": {
"signers": [
{ "slotIndex": 0, "role": "manager", "email": "[email protected]" }
],
"signingMode": "sequential",
"expiresInHours": 72
},
"delivery": {
"mode": "secure-email",
"recipients": [
{ "email": "[email protected]", "name": "Vendor Contact" }
],
"expiresInHours": 168
}
}
}Scenarios
Scenario 1 — Customer Contract (Standard, Multi-Step)
Business context: Sales team creates a vendor contract workflow from Dynamics 365.
Vendor fills three steps over the portal; Finance Lead approves; sealed PDF
auto-triggers VaultESign for counter-signature.
Step 1: Vendor Contact Details (name, email, company, ABN/EIN)
Step 2: Contract Terms (value, start date, payment terms)
Step 3: Compliance Declaration (sanctions check, insurance confirmation, T&C acceptance)
Create session:
POST /api/workflow
{
"templatePath": "templates/vendor-contract.vpdf",
"correlationId": "vc-2026-0601-acme",
"templateSettings": {
"workflow": {
"recipients": [{ "email": "[email protected]", "displayName": "ACME Contact" }],
"organizationName": "Contoso Ltd",
"message": "Please complete and submit the vendor contract form."
},
"esign": {
"enabled": true,
"signers": [{ "slotIndex": 0, "role": "vendor", "email": "[email protected]" }],
"signingMode": "single"
}
},
"options": { "documentId": "VC-2026-0601", "docType": "vendor-contract" }
}
Flow:
Vendor receives portal link → fills 3 steps → submits
├─ Form field data (text, selects, dates): browser → your Dispatcher (portal token auth)
│ → stored in your Azure Table Storage; portal server not in data path
├─ File attachments (e.g. business registration, insurance certificate):
│ browser requests pre-signed SAS URL from your Dispatcher
│ → browser uploads directly to your Azure Blob Storage via SAS
│ → portal server never in file byte path; bytes stay in your subscription
Validation passes → Finance Lead receives approval notification
Finance Lead approves → Processor seals PDF
Post-seal: VaultESign auto-triggers → vendor receives signing invitation
Vendor signs → evidence certificate appended → completeScenario 2 — AP 3-Way Match (Governance, Auto-Validate)
Business context: D365 Finance triggers a 3-way match check on receipt of an invoice.
All data is pre-populated; no portal interaction required from the submitter.
Validation runs immediately; AP Manager (or Finance Director for high-value) approves.
POST /api/workflow
{
"templatePath": "templates/ap-3way-match.vpdf",
"correlationId": "inv-2026-0601-8821",
"initialData": {
"po_number": "PO-2026-0412",
"po_amount": 42500.00,
"po_quantity": 100,
"po_vendor_id": "VEND-0098",
"gr_number": "GRN-2026-0187",
"gr_quantity": 100,
"invoice_number": "INV-2026-8821",
"invoice_total": 43200.00,
"invoice_quantity": 100,
"invoice_vendor_id": "VEND-0098",
"lines_all_price_match": true,
"lines_all_qty_match": true
},
"options": { "documentId": "INV-2026-8821", "docType": "ap-invoice" }
}
Flow:
Session created → validation runs immediately (autoValidateOnCreate: true in schema)
invoice_total ($43,200) within 5% of po_amount ($42,500) → tolerance warning surfaced
All error rules pass → AP Manager receives approval notification with variance panel
AP Manager approves → Processor seals PDF with Governance Validation page
Sealed PDF stored → WORKFLOW_SEALED audit event emittedScenario 3 — Employee Expense Claim (Standard, Changes-Requested Flow)
Business context: Employee submits an expense claim via the portal.
Approver requests a correction (receipt amount mismatch); employee corrects and resubmits.
Create session:
POST /api/workflow
{
"templatePath": "templates/expense-claim.vpdf",
"correlationId": "exp-2026-0601-jsmith",
"templateSettings": {
"workflow": {
"recipients": [{ "email": "[email protected]", "displayName": "J. Smith" }],
"organizationName": "Contoso Ltd"
},
"delivery": {
"enabled": true,
"recipients": [{ "email": "[email protected]" }]
}
},
"options": { "documentId": "EXP-2026-0601", "docType": "expense-claim" }
}
Flow:
Employee receives portal link → fills expense details, uploads receipts
├─ Expense receipt attachments: browser requests pre-signed SAS URL from your Dispatcher
│ → browser uploads directly to your Azure Blob Storage via SAS
│ → portal server never in file byte path; attachment bytes stay in your subscription
├─ Form field data (amounts, dates, categories): browser → your Dispatcher
│ → stored in your Azure Table Storage; portal server not in data path
Employee submits → validation passes → Line Manager notified
Line Manager reviews → requests change: "Receipt for lunch on Jun 3 is $85.50, not $95.50"
Employee corrects field → resubmits
Line Manager approves → Processor seals PDF
Post-seal: VaultDelivery delivers approved expense PDF to employee inboxReady to Configure a Workflow?
See the Workflow Schema reference for step definitions, validation rules, and approval routing configuration.
VaultPacks - Template & Process Catalog
Pre-built content bundles that combine document templates, governance workflows, validation workflows, approval processes, and delivery configurations into deployable business solutions.
Workflow Schema Reference
Complete reference for the VaultWorkflow YAML schema, covering step definitions, field types, validation rules, and approval routing configuration.