DocsUpdates & Customer Emails
How to publish a new version, announce it to your customers, rehearse the email first, and recover when a send doesn't go to plan.
The Product Action Bar
Every product's Overview tab leads with four guided, full-page wizards. Each walks you through one job end to end, with a step rail showing your progress:
Publish a version
Pick an uploaded version, review what changes for customers, write release notes, and make it live — with or without emailing anyone.
Announce to customers
Email everyone who owns the product about the current live version — for when you published silently or want to send a follow-up.
Invite beta testers
Send version-pinned invite links to testers before a build goes live. Works on draft (unpublished) products too.
Retry a past send
Re-send an announcement to exactly the recipients whose emails failed, without re-emailing everyone who already got it.
Actions that aren't currently possible show as disabled with the reason — for example "Upload a version first" or "No customers have bought this product yet".
Publishing With or Without an Email
The Publish wizard's release-notes step has two exits:
Publish and email customers
Activates the version and queues an update announcement to the recipient cohort shown on the review step. The live "Email N customers" count tells you exactly how many people will be mailed.
Publish without emailing
Just switching the live build? Skip the email — customers get the new version automatically on their next download, and nobody is notified. No blast is queued and no send appears in history.
Who gets the announcement: completed purchases only — pending, cancelled, and refunded buyers are excluded, as are test purchases and beta testers. Customers imported from a legacy store (migrated purchases) are included by default, with a per-send opt-out on the audience step.
Release Notes
Notes you write during upload or in the Publish wizard aren't locked in: they're editable afterwards from the version's detail page ("Edit version & notes"). One set of notes is used everywhere they surface — the customer download page, the versions list, and the {{version_notes}} placeholder in delivery emails.
Email Templates & Overrides
Email copy resolves through four scopes, most specific first:
Version override
Copy written for one specific version — e.g. a beta build with its own instructions.
Product override
Copy written for this product, used by all its versions without their own override.
Organisation template
Your org-wide default for this email type.
System default
Continuata's built-in copy — used until you customise anything.
The product's Emails tab lists every version-specific override by name with Edit and Delete. Creating one is a two-step wizard: pick the build, then pick the copy to start from (the product's, the org's, a sibling version's, or the system default — each shown with its subject). Deleting an override names the template that takes over. The beta_tester template can be overridden per product and per version too, and the beta-invite page shows exactly which template will fire before you send.
You can also tweak the subject or body for a single send at the review step — and optionally save that tweak back as a stored override.
Deleting a version also deletes its email overrides (you'll be warned with the count), revokes its beta invite links, and can't be undone.
Rehearsing a Send
Before announcing to real customers, send yourself a rehearsal from the version detail page. The rehearsal email renders the exact template and notes that will go out, and links the version being rehearsed — not whichever version happens to be live — so a pre-release dry run shows the real build.
- Owner/admin only — members can't send rehearsals
- The rehearsal link uses a throwaway token that expires after 2 hours — it never touches a customer's real download link
- Rehearsals appear in the email log like any other send
How Delivery Works
Announcements are paced at roughly 8 emails per second to stay inside provider limits, so a large blast takes a few minutes to finish — a ~1,300-recipient send completes in about 3 minutes, trickling into the email log as it goes. Individual sends that hit a temporary rate limit are retried automatically, so a failed row in the email log means genuinely failed, not "sent too fast".
The product Overview's "Last send" banner shows live delivery state: after a successful retry it reflects the true delivered count, and any failure count shown is the honest remainder still outstanding.
Retrying Failed Sends
The Retry a past send wizard re-sends only to recipients whose emails failed:
- Each past blast shows a live badge — "N still failed", "Recovered — all delivered", or "All delivered" — and the wizard pre-selects the blast with real outstanding failures
- Retries of 50 or fewer recipients run immediately; larger retries are queued as a background job ("Retry queued") and results land in the email log over the following minutes
- Submitting the same retry twice within 10 minutes is refused while the first is still running — no double sends from a second tab
- Retried sends stay attached to the original blast's history
Repairing Purchases Without Download Links
If some owners of the product can't be emailed because their purchase never got a download link minted (common after a partial legacy import), the audience step tells you with an amber warning and a Repair button.
- Repair mints download links in batches of up to 500 — the result line reports repaired · already complete · could not be repaired · still to go, and you run it again to continue
- Owner/admin only; refunded and cancelled purchases are never repaired
- Once repaired, those customers count into the recipient cohort immediately
Resending a Customer's Purchase Email
When a customer says they never received their download email, resend it from the Purchases page — this is a per-customer action, separate from the blast "Retry a past send" wizard (which only covers update announcements):
- Go to Purchases and search for the customer's email address
- Click the purchase row to expand it
- Click the envelope icon (Resend Purchase Email) in the row's actions
- The button flips to "Email sent" and the send appears in Logs → Emails immediately
The resent email contains the customer's download link and serial (if any). If their old link had expired it self-heals on open, so a resend is always safe. The button appears on completed purchases; if you get "No download token for this purchase", the purchase never had a link minted — use the Repair flow below.
Diagnose before (or after) you resend: open the purchase and click View journey to see the order's full story — whether the receipt was sent, held, failed with an error, or never attempted — alongside webhook delivery and download activity. And remember the customer can always self-serve at continuata.io/my: they enter their purchase email and get a fresh link to every purchase, no vendor action needed.
Receipts Held for Unpublished Products
Store orders that match a product which isn't deliverable yet — still in draft, or with no live version — don't create a purchase or send a receipt. The store webhook is acknowledged (so the store doesn't retry forever) and the order is recorded in Logs → Webhooks as held, with a reason naming the SKU and cause. Manually recorded sales for a not-yet-live product do create the purchase, but the receipt email is held with an amber badge and the hint "Resend once it's live".
Beta invites are never held — inviting testers to a draft product is a supported flow.
What Customers See
Besides the announcement email, customers discover updates on their own in the customer portal: each purchase shows its own update state — "Update available" with the version delta (e.g. v1.0.0 → v1.1.0) once they've completed a download of an older version, and "Up to date" when they're current. The Update button delivers only the changed files when they pick their existing product folder. See Downloads for the customer-side experience.