VaultNotification

VaultNotification is the shared notification layer for the REFRACT Platform. It routes email and SMS notifications for VaultDelivery, VaultESign, and VaultWorkflow through either Vault Shared Services ACS or your own Azure Communication Services instance.

VaultNotification is the cross-cutting notification infrastructure that powers outbound communications across the entire REFRACT Platform. It is not a standalone product - it is the shared layer underneath VaultDelivery recipient invitations, VaultESign signing invitations and OTP codes, and VaultWorkflow participant and approver notifications.

Scope

The EMAIL_PROVIDER environment variable controls all outbound notification emails sent by the REFRACT Platform - not just one product. Setting it on your Dispatcher and Processor affects VaultDelivery, VaultESign, and VaultWorkflow simultaneously.

Two Modes

Two notification routing modes are supported. The mode is set via the EMAIL_PROVIDER environment variable on both your Dispatcher and Processor Function Apps.

`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 REFRACT 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.

Environment Variable Reference

Setting	`vault-shared` (default)	`customer-acs`
`EMAIL_PROVIDER`	`vault-shared` or blank	`customer-acs`
`VAULT_NOTIFICATION_API_URL`	required	not needed
`VAULTNOTIF_SIGNING_KEY`	required	not needed
`ACS_EMAIL_ENDPOINT`	blank	customer's ACS URL
`ACS_EMAIL_KEY`	blank	customer's ACS key

Required 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. `noreply@contoso.com`)

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

What Each Product Sends

Product	Notification	Routed via `EMAIL_PROVIDER`
VaultDelivery	Recipient delivery invitation	Yes
VaultDelivery	OTP code (when `requireOtp: true`)	Yes
VaultESign	OTP code	Yes
VaultESign	Completion notification	Yes
VaultESign	Signer invitation (initial + sequential)	No - sent directly by eSign Portal via Vault Shared Services ACS
VaultWorkflow	Participant portal link	Yes
VaultWorkflow	Approver notification	Yes
VaultWorkflow	Change-request and resubmission notifications	Yes

Data Sovereignty

In both modes, document content, rendered PDF bytes, form field values, and file attachments are never included in any notification message. Notifications carry only the minimum metadata required to perform delivery: recipient email, portal access link, notification type, and document name.