VaultWorkflow

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:

StateDescription
draftCreated but not yet started by the participant.
in-progressParticipant is actively filling steps.
validatingServer is evaluating schema validation rules (transient).
validation-failedOne or more error-severity rules failed. Participant must correct data.
pending-approvalAll steps submitted and validation passed. Awaiting approver action.
under-reviewApprover has opened the submission for review.
changes-requestedApprover returned the submission with structured change requests.
approvedApprover accepted the submission. Seal is being queued.
sealingSeal message enqueued; processor is rendering the final PDF.
completeFinal PDF sealed and stored in Blob Storage.
rejectedApprover rejected the submission. No PDF is produced.
escalatedSubmission was escalated to a secondary approver.
cancelledWorkflow was cancelled before completion.

Step Lifecycle States

Each step within a workflow tracks its own state independently:

StateDescription
pendingNot yet started by the participant.
in-progressParticipant has opened the step.
submittedParticipant completed and submitted the step.
approvedStep accepted during review (sub-flow).
rejectedStep 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 → complete

Scenario 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 emitted

Scenario 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 inbox

Ready to Configure a Workflow?

See the Workflow Schema reference for step definitions, validation rules, and approval routing configuration.

On this page