Dispatcher Deployment and Link Lifecycle
How your Dispatcher deployment relates to the signing, workflow, and delivery links your recipients receive, and what happens to outstanding links when you redeploy or move your Dispatcher.
This page explains how your Dispatcher deployment relates to the REFRACT eSign, REFRACT Workflow, and REFRACT Delivery links your recipients receive, and what happens to outstanding links when you redeploy or change your Dispatcher. Read this before redeploying a production Dispatcher.
Summary
Redeploying your Dispatcher in place is safe and invisible to outstanding links. Deleting and recreating your Dispatcher at the same address keeps links working, but issues a new identity that must be re-granted access to your storage, Key Vault, and Service Bus before your Dispatcher can function. Changing your Dispatcher's address (the URL recipients' links point to) requires a new deployment session and will invalidate links that have already been sent. Expired or invalidated links show recipients a clean "link expired, request a new link" message, not an error.
How Signing, Workflow, and Delivery Links Reach Your Dispatcher
When your Dispatcher creates a REFRACT eSign, REFRACT Workflow, or REFRACT Delivery link, that link routes recipient actions back to your Dispatcher deployment. This address is established during your onboarding deployment session, tied to your license, and does not need manual configuration afterward.
Because this address is fixed at deployment, the lifecycle of your Dispatcher deployment determines what happens to links that are already out in the world.
Redeploying in Place: Safe, No Action Needed
If you redeploy your Dispatcher to the same application (a code update, a configuration change, a restart, or a scale operation), nothing about link routing changes. Your Dispatcher comes back at the same address, and all outstanding signing, workflow, and delivery links continue to work normally.
This is the common case. Routine redeployments are invisible to your recipients and require no re-issuing of links.
Deleting and Recreating at the Same Address: Links Keep Working, Access Does Not
If you delete your Dispatcher's Function App and recreate it under the identical name, in the same resource group, your Dispatcher comes back at the same address, and outstanding signing, workflow, and delivery links continue to route to it correctly, exactly as in the case above.
What does not carry over is the deployment's identity. Your Dispatcher authenticates to its own storage, your Key Vault, and Service Bus using a system-assigned managed identity, a credential Azure creates and destroys along with the Function App itself. Recreating the Function App issues a brand-new identity, even though the app's name and address are unchanged. Every role your original deployment granted, storage read/write access, Key Vault secrets access, Service Bus send access, was granted to that specific identity, not to "your Dispatcher" in the abstract. Those role assignments do not transfer to the new identity: they are orphaned, left pointing at an identity that no longer exists.
Your Dispatcher will look deployed but cannot do anything
After a delete-and-recreate, your Dispatcher accepts requests and links still route to it, but it cannot read secrets from Key Vault, cannot read or write its storage accounts, and cannot send to Service Bus, until the same roles are re-granted to the new identity. Re-running your deployment template does not resolve this by itself: the old, orphaned role assignments are still in place and block the same roles from being cleanly re-created for the new identity.
Before redeploying, remove the orphaned role assignments left by the old identity. Open Access control (IAM) on your storage accounts, Key Vault, and Service Bus namespace, and delete any assignment referencing an identity Azure can no longer resolve (shown as an unresolvable or "Identity not found" principal). Once those are cleared, redeploying your template grants the same roles to the new identity cleanly. If your Dispatcher also has SharePoint access configured, that access is granted separately via Microsoft Graph and is orphaned the same way, re-run that grant step from your deployment guide once the new identity is in place.
Do not delete the resource group itself
Deleting your Dispatcher's resource group deletes its storage accounts along with it, including the storage that holds in-flight session state and your audit trail. That data cannot be recreated. If you need to recreate your Dispatcher, delete and recreate only the Function App resource; leave the resource group and its storage accounts in place.
Changing Your Dispatcher's Address: Requires a New Deployment Session
If your Dispatcher's address changes, for example if you delete and recreate the application under a different name or move it to a different location, this is treated as a new deployment and requires a new deployment session to reconnect it to your license.
Consequences to plan for:
- Outstanding links break. Any signing, workflow, or delivery link already sent to a recipient points at your previous Dispatcher location. After an address change, those links can no longer reach your Dispatcher and will show recipients the "link expired" message.
- New links work once the new deployment is connected. Links created from that point forward route to the new location correctly.
- Recipients with outstanding links must be re-sent. If you have signing sessions or deliveries in flight when you change your Dispatcher's address, plan to re-issue those links afterward.
Treat an address change like a maintenance window
Complete or drain any in-flight signing, workflow, or delivery sessions first where possible, then complete the new deployment session, then re-issue any links that were still outstanding.
Changing Your Hosting Plan: Requires a New Deployment
Your Dispatcher runs on Azure Functions' Flex Consumption plan. Azure does not support migrating a Function App in place to or from Flex Consumption, so moving to a Premium plan (for example, for VNet integration or to eliminate cold starts) means your Dispatcher's Function App must be deleted and recreated on the new plan. There is no in-place upgrade path.
What happens next depends on whether the recreated app keeps the same address:
- Same address. If your new deployment keeps the same hostname, this is the delete-and-recreate case above: outstanding links keep working, and the only work is re-granting your new identity's access to storage, Key Vault, and Service Bus.
- Different address. If the recreated app comes up at a new hostname, every outstanding signing, workflow, and delivery link is dead and must be re-issued once the new deployment is live, the same consequence as an address change above.
A hostname change also requires your license to be rebound
Your license is bound to a specific Dispatcher hostname, and that binding does not update itself. If your hosting-plan migration changes your hostname, new links will not work either until Refract Logic rebinds your license to the new address. Rebinding is an internal operation you request from your onboarding team, not something you can do yourself. Until the rebind happens, your Dispatcher will appear to deploy and run successfully, but the links it issues will still point at your previous address. Request the rebind as part of planning any hosting-plan migration that changes your hostname, not after you discover links are failing.
When a Recipient Opens an Expired or Invalidated Link
Whether a link has passed its own expiry or was invalidated by a Dispatcher address change, the recipient sees a clean, self-explanatory "link expired, request a new link" message. This is expected behavior, not a fault or an outage.
If a recipient reports this message:
- Confirm whether the link is simply old (past its normal validity window) or whether the Dispatcher address changed.
- Issue the recipient a fresh link. New links generated by your current Dispatcher deployment route correctly.
There is no error page and no support escalation required for an expired link. Re-issuing is the resolution.
Normal validity windows are configurable and vary by product: see Session Expiry for REFRACT eSign, Delivery Modes for REFRACT Delivery, and Portal Access & OTP for REFRACT Workflow.
Quick Reference
| Situation | Outstanding Links | Action Needed |
|---|---|---|
| Redeploy in place (same address) | Keep working | None |
| Restart, scale, or configuration change | Keep working | None |
| Delete-and-recreate at the same address | Keep working | Re-grant storage, Key Vault, and Service Bus access (and SharePoint access, if configured) to the new identity |
| Address change (delete-and-recreate, move) | Break, show "link expired" | Complete a new deployment session, then re-issue outstanding links |
| Hosting-plan change with a new hostname | Break, show "link expired" | Complete a new deployment session, request a license rebind from Refract Logic, then re-issue outstanding links |
| Link past its normal validity window | Shows "link expired" | Issue a fresh link |
Planning a Dispatcher Migration?
If you are planning to move or recreate your Dispatcher deployment and need guidance on draining in-flight sessions first, contact your REFRACT onboarding team before you begin.
Audit Logs
How to configure REFRACT PDF's audit system. Covers all three audit tiers -- basic (SharePoint JSONL), blob (Azure Blob AppendBlob), and enterprise (Service Bus + Audit Worker) -- including the AuditEvent schema, file naming, and setup steps for each tier.
Payload Structure
Complete reference for the top-level REFRACT PDF JSON payload. Covers templateId, metadata, theme, header, footer, layoutSchema, templateSettings, hierarchyRules, and all other recognized top-level keys.