> For the complete documentation index, see [llms.txt](https://knowledge.maica.com.au/maica-release-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://knowledge.maica.com.au/maica-release-notes/client-delivery/version-0.157.md). # Version 0.157 Client Delivery V0.156 introduces one enhancement and four fixes. The headline addition is a set of **Travel Management input refinements** that allow a distance of zero to be recorded and make the Timesheet Activity field on travel entries optional. The fixes cover validation error visibility in Planner modals, the default value of the Billable Participant Note flag, an Appointment Cost Calculation sibling-query fallback for non-time-based activities, and modal animation reliability. ## Installation Information Use the buttons below to install the latest version of **Maica Client Delivery** into the appropriate Salesforce org type. Select the link that matches your environment using the Buttons below. {% hint style="info" %} We always recommend installing the package into a **Sandbox** first to validate the release before deploying to **Production**. If you're unsure which option to select, please contact **Maica Support**. {% endhint %} **Production & Developer Edition Orgs**: Production URL **Sandbox & Scratch Orgs:** Sandbox URL {% hint style="success" %} If you are on a Journey Agreement with us, your Account Manager will connect with you to organise the upgrade. {% endhint %} ## At a glance | Headline | Type | Area | | -------------------------------------------------------- | ----------- | ---------------------------- | | **Travel Management input refinements** | Enhancement | Travel Management | | **Planner modals: Validation Errors Now Surfaced** | Fix | Planner | | **Billable Participant Note default value** | Fix | Participant Notes | | **Appointment Cost Calculation: Sibling Query Fallback** | Fix | Appointment Cost Calculation | | **Modal Animation Reliability** | Fix | Platform | ## Enhancements ### Travel Management input refinements **Reference:** CC-708 We have refined the Travel Management inputs in two areas: the distance input now accepts a value of zero, and the Timesheet Activity field on travel entries is no longer mandatory. Both changes bring Client Delivery in line with the equivalent behaviour previously delivered in Client Care. **What's changed** * The **Distance Travelled (km)** input in the Travel Management component now accepts **0** as a valid value. Previously, the input enforced a minimum greater than zero, which prevented recording travel events with zero distance (for example, where only time-based travel was applicable). * The **Timesheet Activity** field on travel entries in the Care Worker App is now optional. Previously, Support Workers were required to enter a Timesheet Activity for every travel entry, which was inconsistent with their day-to-day usage of the app. **Outcome** Care Workers and Schedulers can now record travel events with zero distance, and the Care Worker App no longer requires the Timesheet Activity field for travel. The change is fully backward compatible: organisations that already populate Timesheet Activity on travel entries can continue to do so. **Example scenarios** * ✅ A user records a travel entry with zero kilometres and a non-zero travel time → the entry saves successfully without surfacing a minimum-value validation error. * ✅ A Support Worker submits a travel entry in the Care Worker App without selecting a Timesheet Activity → the entry saves successfully. * ✅ A user records a travel entry with both distance and Timesheet Activity populated → existing behaviour is preserved and the entry saves as before. *** ## Fixes ### Planner modals: Validation Errors Now Surfaced **Reference:** CC-693 We have resolved an issue where validation rule errors triggered inside Planner modals were not displayed to the user. **What's changed** Previously, when a validation rule fired on a record being saved through a Planner modal (for example, a Participant Note validation rule), the Planner displayed a generic "Oops, that didn't work" message without revealing the underlying validation error. This made it difficult for users to understand what needed to change to save the record. Planner modals now surface validation rule error messages directly in the modal, using the same expandable **Show more** pattern that exists elsewhere in the product. Users can read the underlying validation message, correct the record, and save without leaving the modal. **Example scenarios** * ✅ A user creates a Participant Note in the Planner and triggers an organisation validation rule → the validation error is displayed in the modal, and the user can correct the input and save without dismissing and reopening the modal. * ✅ A modal save fails for reasons other than a validation rule (for example, a permission error) → the existing error handling continues to apply. *** ### Appointment Cost Calculation: Sibling Query Fallback **Reference:** CC-706 We have refined the Appointment Cost Calculation logic so that the Registration Group Number and Support Category Number are correctly inherited on non-time-based Delivery Activities, even when all sibling Delivery Activities on the Appointment have been Cancelled. **What's changed** Appointment Cost Calculation uses a sibling query to inherit **Registration Group Number** and **Support Category Number** onto a non-time-based Delivery Activity from other Delivery Activities on the same Appointment for the same Participant. Previously, the query excluded any sibling Delivery Activity with a status of **Cancelled**. Where every sibling was Cancelled, the query returned no results, and the inherited metadata fields were left blank. The query has been refined as follows: * The primary query continues to return only non-Cancelled siblings, preserving existing behaviour for the common case. * A fallback query has been added: when the primary query returns no results, the system performs a second pass that includes Cancelled siblings. The fallback ensures the inherited metadata is always populated from the most accurate available source. This change applies only to the sibling-query logic. How the inherited values are subsequently used in cost calculation is unchanged. **Example scenarios** * ✅ An Appointment has a non-time-based Delivery Activity and at least one non-Cancelled sibling Delivery Activity → existing behaviour is preserved. The metadata is inherited from the non-Cancelled sibling. * ✅ An Appointment has a non-time-based Delivery Activity and all sibling Delivery Activities have been Cancelled → the fallback query runs, the metadata is inherited from a Cancelled sibling, and the Registration Group Number and Support Category Number are correctly populated. * ✅ An Appointment has a non-time-based Delivery Activity and no sibling Delivery Activities at all → no change. The fields remain blank and existing handling applies. *** ### Modal Animation Reliability **Reference:** CC-712 We have resolved an issue where modals could open in the page without becoming visible to the user. **What's changed** Previously, certain modals opened correctly at the technical level (the modal was added to the page) but the animation that brings the modal into view did not consistently start. The result was a modal that existed on the page but was not visible or interactable. The animation handling has been refined so that modals reliably render and become visible when opened. Existing modal behaviour, including close and dismiss handling, is unchanged. **Example scenarios** * ✅ A user opens a modal from any Planner or record-page entry point → the modal reliably renders and animates into view. * ✅ A user dismisses a modal → existing close and dismiss behaviour is preserved.