REFRACT Notification

REFRACT Notification is the cross-cutting notification infrastructure that powers outbound communications for REFRACT Delivery recipient invitations and REFRACT Workflow participant and approver notifications. It is not a standalone product - it is the shared layer underneath those flows.

REFRACT eSign emails start in a different place. Because the signing experience is hosted by REFRACT, eSign emails are composed by the REFRACT eSign Portal; EMAIL_PROVIDER still decides where they are sent from - see REFRACT eSign emails below.

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 Notification service (HMAC-signed). REFRACT Shared Services' Azure Communication Services instance handles the actual email delivery.

Customer Azure Subscription                          REFRACT Shared Services
──────────────────────────────────────   ────────────────────────────────────
Dispatcher
  └─ enqueue notification message
       └─ [Customer Service Bus]
             └─ Processor NotificationWorker
                  └─ POST /api/notifications/send
                       (HMAC-SHA256 signed)
                                                    └─ REFRACT Notification service
                                                          └─ ACS (email)

The HMAC-signed POST carries recipient email, portal link, notification type, document name, any one-time code, and - for OTP and other pre-rendered notifications - the fully rendered subject, HTML, and text body, plus any custom message text. Document content, file bytes, signatures, and form field values are never included.

customer-acs

Your Processor sends REFRACT Delivery and REFRACT Workflow notification emails directly through your own Azure Communication Services instance. For these features, the REFRACT Notification service is never called and no notification metadata transits REFRACT Shared Services.

Customer Azure Subscription
──────────────────────────────────────
Dispatcher
  └─ enqueue (metadata-only message)
       └─ [Customer Service Bus]
             └─ Processor NotificationWorker
                  └─ sendViaCustomerAcs()
                       └─ Your own ACS
                            (ACS_EMAIL_ENDPOINT + ACS_EMAIL_KEY)

REFRACT eSign emails

The REFRACT eSign signing experience is hosted by REFRACT. Signers open a REFRACT-hosted portal to view the document, request an access code, and sign. The emails that support that experience are composed by the portal. Where they are sent from follows EMAIL_PROVIDER on the Dispatcher that created the envelope, recorded on the envelope when it is created:

In customer-acs mode the portal hands each finished email to your Dispatcher, signed with that envelope's key. Your Dispatcher sends it only to that envelope's signer or requester, queues it, and your Processor sends it from your own Azure Communication Services. It is never sent through the shared service instead.

In both modes every eSign email is recorded on the envelope's audit trail, as queued or as not sent with the reason.

The reminder email uses the invitation's layout and the signer's same link, worded as a reminder ("Reminder: please sign ...", "Your signature is still needed"). Its purpose is to prompt a signer who has not yet signed. The expiry warning says "Your signing link expires soon", states when the link stops working, and says that the sender will need to send a new request. Both are sent on the schedule described in eSign Reminders, and are recorded on the audit chain as SIGN_REMINDER_SENT. Setting REFRACT_REMINDERS_DISABLED=true on the Dispatcher Function App stops every automatic reminder for REFRACT eSign, REFRACT Workflow and REFRACT Delivery.

If your Dispatcher cannot be reached (customer-acs mode), the portal keeps the email, encrypted, and keeps trying for 24 hours. If it still cannot hand it over, the email is recorded on the audit trail as not sent, and the Lifecycle panel shows it against that signer or the requester so someone can act. One-time access codes expire within minutes, so they are not kept: the signer is told the code could not be sent and can ask for another.

What crosses the boundary for these emails is notification metadata only: recipient email address, signer name, document name, requesting organization, and the signing link. Document content, rendered PDF bytes, signature images, and form field values never leave your Azure subscription - the portal holds a link, not the document.

Environment Variable Reference

Required variables for customer-acs mode:

Choosing a Mode

What Each Product Sends