We’re committed to keeping you fully up to speed with all of the features, enhancements and fixes we ship at Root. Here are all of the updates and improvements we shipped over the last month 🛠️

Features

We’re working on new features to expand what you can do on Root:

• Cancel pending applications: We're working on introducing the ability to cancel a pending application directly from the application details view on Dashboard.
• Field-level changes on applications: Event field-level change tracking is now available on applications, surfacing field-by-field updates in the same way they already appear for policies.
• Repeatable list blocks on claims: A new list block type for claim schemas lets product modules define repeatable groups of fields on a claim, for example, multiple claimed items, expense lines, or supporting documents. Each item can carry its own fulfilment, payout, or annuity request, with independent approval flows. Read the docs.
• Edit packageName via update_policy: Product modules can now update packageName through the update_policy lifecycle action, and the Workbench CLI's type definitions have been tidied so authors get clearer compile-time feedback.
• Invoicing module foundation: Significant work has been done on new invoicing capability on Root, including invoice creation, PDF rendering, payment linking, credit-note refunds, a REST API, a policy-level Invoices block in Dashboard, and rendering of invoice events in the policy activity timeline. This feature is in early development phases. If you're interested in providing feedback while it's being built, please reach out to our product manager at [email protected].
• Data delivery methods: Work was done to abstract data delivery details into a standalone feature so delivery methods can be created and managed in one place, reused across exports, and eventually used by other features. This feature is still in development and testing.

Platform Enhancements

• Performance Enhancements

  We’ve introduced enhancements to improve stability, efficiency, and visibility across Root:

  • Improved validation in product module tooling: The Root Platform CLI (rp push) now fails immediately with a clear error when duplicate alteration hook keys are present.
  • Clearer Workbench rp clone messaging: Messaging from the rp clone command has been aligned with rp pull, rp push, and rp publish for a more consistent experience when working with product module code.
  • Improved query performance safeguards: Work was done to catch slow database queries before they reach production.
  • Reduced duplicate blank document storage: When a document is generated from an empty template, the platform now points every blank attachment at a single shared blank PDF rather than re-uploading duplicates, reducing storage overhead.

• Billing Enhancements

  We’ve made several improvements to increase reliability, accuracy, and automation across Root’s billing processes.

  • Restored payment refund modal with improved refund-type options: Work was done to restore the payment refund modal, which had been unintentionally removed in a previous change. The modal includes three clear refund-type options: last payment amount, custom amount, and assign to a payment.
  • Improved reliability of payment batch submissions: Updates were made to prevent external-provider payment batches from getting stuck in a "submitting" state once their data export file has already been sent to the bank, keeping dashboard status consistent with actual submission state.
  • Continued work on the policy ledger: We're currently working on the migration and testing process for the new ledger to ensure smooth client rollout.
  • Prevent duplicate payment reversals: Safeguards were added to ensure each original payment can have at most one reversal, including under concurrent attempts. Direct API calls to reverse an already-reversed payment now return a clear conflict response rather than a generic error.
  • Lapse-eligible policies skip reversal retries: When a payment reversal occurs on a policy already eligible for lapse, the system now creates a pending lapse request directly instead of retrying the reversal.
  • Billing queries now read live product module settings: Billing-related queries (debit premium selection, missing-premium payment alerts, billing-run and payment-check reports) now read product module settings from the current live or draft version, rather than the snapshot stored on the policy. Changes such as debit timing or alert thresholds now take effect after a product module is republished, without needing a policy alteration.
  • Idempotent batch submission across retries: Batch submissions now use consistent file names and contents across retry attempts. If the same batch has already been submitted to the provider, the retry is treated as a no-op rather than risking a duplicate submission.
  • Per-module scheduled payment behaviour: Collection module authors will soon be able to configure scheduled payment behaviour on a per-module basis. This feature is currently in development.
  • SoftyComp DebiCheck enhancements: Two improvements to the SoftyComp DebiCheck integration which is currently in development:
    • DebiCheck mandates will be created automatically when a debit order is assigned on a SoftyComp billing policy, with the mandate persisted and linked to the policy.
    • A callback endpoint will be added so SoftyComp can notify the platform of mandate lifecycle changes, keeping mandates in sync.

• Bug fixes

  We’ve addressed key issues to improve system reliability:

  • Policy status not updating after payment method assignment: Resolved an issue where a policy could appear stuck (not active) after a payment method was assigned, because downstream callers were receiving a stale view of the policy.
  • Gender and date-of-birth update validation bypass: Fixed a bug where identity-related validation could be skipped on certain gender or date-of-birth update requests, allowing changes that should have been blocked.
  • Invalid application status filter: Resolved an issue where filtering applications by an invalid status would return a server error instead of a clear validation response. The invalid application status in question, which was the 'closed' status filter on the claims list view, has been removed.
  • Missing display for policy reactivation events: Added the missing display component for policy reactivation events on policy timelines. These now appear correctly alongside other policy events.
  • Coupon currency on non-ZAR policies: Resolved an issue where coupon redemptions and reversals recorded the policy ledger entry in ZAR regardless of the policy's actual currency.
  • Cross-environment UUID validation on data imports: Fixed a bug where the duplicate UUID check on data imports only looked within the same organisation and environment, which could allow a sandbox import to silently block or overwrite a production record. A clearer error message now surfaces when a UUID already exists elsewhere on the stack.

If you have any suggestions or feedback, please share them with your Client Success Manager or submit them via the Root product roadmap to make sure we always know what’s top of mind for you.