8/6/2026 Release
This release opens up boarding form lifecycle webhooks — five new events that tell your system the moment a form is created, started, updated, completed, or expired — alongside a rebuilt merchant label filter, a rich text editor for boarding form welcome content, and a broad design-system refresh across the dashboard — plus a set of validation, upload, and rendering fixes.
Jump to: New Features · Improvements · Bug Fixes
New Features
Boarding form lifecycle webhooks
Your endpoint can now be notified at every meaningful stage of a boarding form's life, so you can track provisioning, engagement, drop-off, and completion without polling the Forms API. Full envelope and per-event payload shapes are documented in Boarding Form Webhook Payloads.
- Five new subscribable events.
form.created,form.started,form.updated,form.completed, andform.expiredare now valid values on your webhook subscription, delivered over the same HMAC-signed, retried delivery pipeline as merchant and transaction webhooks. form.created. Fires as soon as a boarding form is provisioned — from either the API or the dashboard — so you can log the form without a follow-up read.form.started. Fires the first time a merchant makes real progress on a form, exactly once per form, so you can measure engagement and boarding-funnel drop-off.form.updated. Fires on every form mutation. It is chatty by design, and it still fires alongsideform.started/form.completedwhen the same save triggers both — each event carries independent meaning, so subscribe only to what you need.form.completed. Fires when a form is officially completed, so you can activate an account or kick off next-step workflows.form.expired. Fires when a merchant fails to finish a form within its expiration window — the hook for a re-engagement or reset workflow. Expiration detection is forward-only: forms created before this release are not swept.personCompletingon the payload. Everyform.*payload now carries the welcome step's "person completing" block — first name, last name, email, phone, title, plus the server-stamped agreement timestamp and IP address — mirroring theGET /forms/{id}response, so you can record who completed the form without a second call.- Delivery attempts tagged as
form. Form webhook deliveries are recorded with their own entity type, so they can be audited and troubleshot the same way as merchant, transaction, and loan webhooks. - Subscribe from the dashboard. The
/webhookspage now exposes all fiveform.*events, so you can self-serve the subscription without engineering support.
Reference: Boarding Form Webhook Payloads documents the shared envelope, thedatafields carried by each event, and the delivery caveats worth designing around — including that payloads carry identifiers, status, and timestamps only (never the business, owner, banking, or document data the form collected), and thatform.completedmeans submitted, not approved.
Rebuilt label filtering across the dashboard
Merchant label filtering has been rebuilt on a single shared component, with clearer language and a filter state that survives a page reload.
- Include or exclude in one control. Each label now cycles through neutral, include, and exclude, so you can build "with Gold, without Trial" in a single list instead of managing two separate pickers.
- Chips on multi-widget pages. The Dashboard and RevOps Dashboard show applied filters as removable chips above the widgets, so the active filter stays visible across every chart.
- Stage and apply. Changes stage as you make them and commit on Apply — the table, widgets, and URL keep showing your last applied filter until then.
- Shareable filter URLs. Filter state serializes to the querystring, so a filtered view can be bookmarked or shared. Existing bookmarked links keep working.
- "Only merchants with no labels" is now a first-class option. Unlabeled-merchant filtering is its own explicit checkbox rather than a synthetic entry in the label list — which also stops a placeholder from ever being saved as a real label.
Rich text editing for boarding form welcome content
Boarding form template authors can now write the welcome step's introduction and agreement content in a visual editor — bold, italics, lists, and links — instead of hand-writing markdown. Content is still stored as markdown, so nothing changes for the rendered form.
"Person completing" on the merchant's Forms tab
Merchant Detail's Forms tab now shows who completed each boarding form — the contact details they supplied, plus whether and when they accepted the agreement — so you can verify a submission without digging through raw form data. Fields are configuration-driven, so the panel renders only what that form actually collected.
Improvements
Dashboard
- Design system rollout. API Keys, Users, Activity Log, Webhooks, Loans, Loans Export, Requirements Templates, and Boarding Form Templates have all been restyled onto the new Preczn design system, so table layout, row actions, status pills, and empty states are now consistent page to page in both light and dark themes.
- Simpler webhook add/edit. Creating and editing a webhook endpoint now uses a single, always-editable form instead of the previous three-mode, toggle-to-edit screen.
- Smoother loading placeholders. The shared loading placeholder used across merchants, transaction log, and the analyst dashboard now renders the design system's skeleton, so loading states match the rest of the app.
More design updates are on the way. We'll be rolling the new design system across the rest of the dashboard over the next several sprints. As you work in the refreshed pages, we'd like to hear how they feel — reach out to your Preczn contact or our support team with any feedback or questions.
Merchant API
completionDateon form responses. The form completion timestamp is now returned and documented on the form endpoints, so you can tell when a boarding form was completed without inferring it from other signals.statusandexpiresOndocumented. The form lifecycle fields that drive the new webhooks —status(ACTIVE/COMPLETED/EXPIRED) andexpiresOn— are now declared in the OpenAPI spec instead of only appearing in live responses.
Boarding form
- Redesigned unsaved-changes warning. The warning shown when you navigate back with unsaved changes now matches the modern confirmation modal used elsewhere in the app, with the same three choices — save and go back, discard, or stay — and a proper close control.
Bug Fixes
Boarding form
- Upload progress on image files. Uploading an image no longer completes with no visible in-progress indicator. Images and PDFs now show the same branded "Uploading…" state on every step.
- Hidden owner fields no longer block completion. An owner field hidden by template configuration is no longer enforced as required — it previously counted toward the missing-fields badge and triggered a "Fill required field" error with no field on screen to fill, making the form impossible to submit.
- Welcome step links open in a new tab. Links inside the welcome step's introduction and agreement content now open in a new tab, so clicking one no longer replaces the in-progress form.
- Accurate step-level progress. Every step now records its own distinct progress value. Previously the GreenSky and Ramp contacts steps recorded nothing at all, all terms & conditions steps collapsed into one value regardless of connection, and the three business sub-steps were indistinguishable — which made drop-off on those steps invisible or ambiguous.
Dashboard
- Link tooltip no longer clipped. In the welcome section's rich text editor, the link-entry tooltip is no longer cut off by the drawer edge when the highlighted text sits near the left of the editor.
- No more blank-icon flash. Icons inside dropdown menus, modals, and other lazily-rendered panels no longer flash blank on their first appearance in a session.
Merchant API
- Correct state/country validation on partial updates. Sending a state or province without its paired country no longer validates against the US state list by default. Canadian merchants can now update a province code on its own without a misleading rejection, and the inverse cases — patching a US state onto a Canadian record, or a US country onto a record holding a Canadian province — are now caught instead of silently persisting an inconsistent pair that would fail later at a downstream processor. The same fix applies to postal-code/country validation and to every DTO sharing these validators.
Questions about this release? Reach out to your Preczn contact or our support team.
