REFRACT Notification
REFRACT Notification is the shared notification layer for the REFRACT Platform. It routes email and SMS notifications for REFRACT Delivery, REFRACT eSign, and REFRACT Workflow through either REFRACT Shared Services ACS or your own Azure Communication Services instance.
REFRACT Notification 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 REFRACT Delivery recipient invitations, REFRACT eSign signing invitations and OTP codes, and REFRACT Workflow 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 REFRACT Delivery, REFRACT eSign, and REFRACT Workflow 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 REFRACT PDF notification service (HMAC-signed, metadata only). REFRACT PDF's Azure Communication Services instance handles the actual email delivery.
Customer Azure Subscription REFRACT PDF 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)
└─ REFRACT PDF 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 REFRACT PDF notification service is never called - no notification metadata transits REFRACT PDF 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: REFRACT Delivery and REFRACT Workflow fully, REFRACT eSign partially
Setting EMAIL_PROVIDER=customer-acs on both your Dispatcher and Processor routes all notification queue emails through your own ACS - this covers REFRACT Delivery invitations and OTP codes, REFRACT eSign OTP codes and completion notifications, and REFRACT Workflow participant notifications.
REFRACT eSign invitation emails (initial and sequential) are currently also sent directly by the eSign Portal via REFRACT 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 |
| REFRACT PDF infrastructure in notification path | Yes (metadata only - email address, portal link, notification type) | No - REFRACT PDF infrastructure not involved |
| Document data crosses boundary | Never | Never |
| Applies to | REFRACT Delivery, REFRACT eSign, REFRACT Workflow | REFRACT Delivery, REFRACT eSign, REFRACT Workflow |
| Use when | Standard deployments | Strict zero-transit requirements for any notification metadata |
What Each Product Sends
| Product | Notification | Routed via EMAIL_PROVIDER |
|---|---|---|
| REFRACT Delivery | Recipient delivery invitation | Yes |
| REFRACT Delivery | OTP code (when requireOtp: true) | Yes |
| REFRACT eSign | OTP code | Yes |
| REFRACT eSign | Completion notification | Yes |
| REFRACT eSign | Signer invitation (initial + sequential) | No - sent directly by eSign Portal via REFRACT Shared Services ACS |
| REFRACT Workflow | Participant portal link | Yes |
| REFRACT Workflow | Approver notification | Yes |
| REFRACT Workflow | 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.
REFRACT Delivery API Reference
HTTP endpoint reference for creating delivery sessions, querying session state, downloading documents, OTP verification, and revoking access.
REFRACT Dispatch
REFRACT Dispatch is a governed batch document generation engine. Submit a payload with hundreds of records, get a validation report, obtain approval, and let the Processor render and deliver each document independently - with a per-record audit trail and REFRACT Delivery integration.