> 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.161.md).
# Version 0.161
Client Delivery V0.161 introduces two enhancements and six fixes. The headline additions are a new **Temporary Jobs** area in Settings for one-off maintenance runs, and a **Check-In confirmation** on the Mobile Care Worker App that brings Check-In into line with Check-Out. The fixes cover Participant Notes at Check-Out, Check-In and Check-Out permissions, Check-In error handling, Recurring Unavailability cancellation, Master Appointment promotion on cancellation, and multi-select lookups.
{% hint style="warning" %}
**Post-install steps required.** Two items in this release need an administrator to act after upgrading. See [Post-Install Steps](#post-install-steps) at the bottom of this page.
{% endhint %}
## 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 |
| --------------------------------------------------------------- | ----------- | ---------------------- |
| **Temporary Jobs in Settings** | Enhancement | Settings |
| **Check-In Confirms Success and Saves Checklists Cleanly** | Enhancement | Mobile Care Worker App |
| **Check-Out Proceeds Once Participant Notes Are Complete** | Fix | Mobile Care Worker App |
| **Check-In and Check-Out Report Unactioned Resources** | Fix | Mobile Care Worker App |
| **Check-In Errors Shown Clearly and Retried Reliably** | Fix | Mobile Care Worker App |
| **Recurring Unavailability Cancellation Refined** | Fix | Planner |
| **Master Appointment Promoted Chronologically on Cancellation** | Fix | Appointments |
| **Multi-Select Lookups Reload Cleanly** | Fix | Platform |
## Enhancements
### Temporary Jobs in Settings
**Reference:** CC-751
We have introduced a **Temporary Jobs** area in **Client Care Settings**, giving administrators a place to run the one-off maintenance jobs that ship alongside a release. Each job is listed with a description, a note explaining when to run it, a **Run Now** button, live progress while it runs, and a summary of the last run with a link to its log.
**What's changed**
* A new **Temporary Jobs** tab is available in **Client Care Settings**. It is an administrator-only area and is not stored as the default tab.
* Each job on the tab is shown as a card carrying a **Temporary** badge, and a **Running** badge while a run is in progress.
* **Run Now** starts the job. The button is unavailable while a run of that job is already queued or processing, and the server refuses a second launch independently of the button state.
* Once a run finishes, the card shows its status, completion time, who started it, and the run summary, with a **View log** link to the full record.
* Running a job requires the **Modify All Data** permission. This is enforced when the tab loads and again when a job is launched.
* This release ships one job: the **Schedule Master Diagnostic**.
**How the Schedule Master Diagnostic works**
The Schedule Master Diagnostic lists every Schedule whose Master Appointment is not the earliest still-active Appointment on that Schedule. It is read-only: it writes Log records and changes no Appointment or Schedule.
Each run writes a Warning log for every batch of Schedules that contains a result, naming the Schedule, its current Master Appointment and start time, and the earliest still-active Appointment and its start time. A single Info log records the run summary. Where a batch does not complete, it is reported in its own Error log and excluded from the summary counts, so the numbers in the summary always describe what was actually scanned.
{% hint style="info" %}
A Schedule listed by the diagnostic is a **review candidate**, not a Schedule that necessarily needs changing. A sibling Appointment that was legitimately rescheduled to start earlier than the Master produces the same state. Review each Schedule before changing anything.
{% endhint %}
{% hint style="warning" %}
Temporary Jobs are one-off maintenance runs that ship with a release. Each is intended to be run once, when the release notes ask for it, and is removed from Settings in a later release.
{% endhint %}
**Example scenarios**
* ✅ An administrator with **Modify All Data** opens the **Temporary Jobs** tab → the **Schedule Master Diagnostic** is listed with its description and, if it has been run before, its last run summary.
* ✅ A user without **Modify All Data** attempts to open the tab → they are told the **Modify All Data** permission is required to view Temporary Jobs.
* ✅ An administrator clicks **Run Now** while a run of the same job is already processing → the launch is refused and the existing run continues undisturbed.
* ✅ The diagnostic completes in an organisation with no results → the summary reports nothing to review in that organisation.
* ✅ The diagnostic completes with results → each affected Schedule is named in a Warning log alongside its current and proposed Master Appointment.
{% hint style="warning" %}
**Post-install steps required.** See [Schedule Master Diagnostic](#schedule-master-diagnostic) under Post-Install Steps at the bottom of this page.
{% endhint %}
***
### Check-In Confirms Success and Saves Checklists Cleanly
**Reference:** CC-754
We have refined the Check-In experience on the Mobile Care Worker App so that a successful Check-In is confirmed on screen the way Check-Out already is, and so that saving a checklist more than once in a single Check-In session updates the existing records rather than creating additional ones.
**What's changed**
* Completing a Check-In now displays a success confirmation naming the record type, for example **The Appointment has been Checked-In.** or **The Shift has been Checked-In.**
* Saving Appointment Checklist Items more than once within the same Check-In session now updates the records created by the first save. Each Checklist Item is matched to its existing record by Appointment and Checklist Item, and the saved record is handed back to the screen so subsequent saves address the same rows.
* Checklist saves for a given Appointment are serialised, so two saves submitted at the same moment cannot each create their own set of records.
* The busy state is now held from the start of the checklist save through to the end of the Check-In save, rather than clearing briefly in between. The Check-In button stays unavailable for the whole operation.
* Error messages raised by the app are now produced through a single shared routine, so the wording is consistent across Check-In, Check-Out, Participant Notes, Expenses, Travel, Breaks and Participant Photos.
**Example scenarios**
* ✅ A care worker completes a Check-In on an Appointment → a success message confirms the Appointment has been checked in, and the modal closes.
* ✅ A care worker completes the checklist, the Check-In is blocked, they correct the problem and submit again in the same session → exactly one record remains per Checklist Item, carrying the latest status.
* ✅ A care worker taps **Check-In** and then taps again before the first save returns → the button is unavailable for the full operation, so only one Check-In is submitted.
***
## Fixes
### Check-Out Proceeds Once Participant Notes Are Complete
**Reference:** CC-726
We have updated the Participant Notes requirement at Check-Out so that the requirement is satisfied once the required notes have been recorded, allowing the care worker to complete their Check-Out.
**What's changed**
* The Participant Notes requirement is now cleared once the number of completed Participant Notes reaches the number required for the Appointment, activating the **Check-Out** button.
* Only Client Notes that are linked to a Participant count toward the requirement. A note recorded against the Appointment without a Participant is no longer treated as a completed Participant Note.
* The required number continues to be taken from the Participant Notes Requirement on the Appointment's Delivery Activities. Where the requirement is **Required for all Participants**, one note satisfies it. Otherwise one note is required for each Participant on the Appointment.
**Example scenarios**
* ✅ A Delivery Activity requires a note for each Participant and the care worker records a note for every Participant → the requirement is met and the **Check-Out** button activates.
* ✅ A Delivery Activity is set to **Required for all Participants** and the care worker records one note covering everyone → the requirement is met with that single note.
* ✅ A Client Note exists on the Appointment but is not linked to a Participant → it does not count toward the Participant Notes requirement.
* ✅ A Delivery Activity has its Participant Notes Requirement set to **Not Required** → no notes are requested and Check-Out proceeds as normal.
***
### Check-In and Check-Out Report Unactioned Resources
**Reference:** CC-729
We have updated Check-In and Check-Out so that a care worker is told when the Resources they submitted could not be actioned, rather than the action appearing to succeed while nothing was recorded.
**What's changed**
* Where the submitted Resources cannot all be read by the current user, Check-In reports **No Resource was checked in. You may not have permission to check in other team members.** Check-Out reports the equivalent message for check-out.
* Where a Check-In or Check-Out is submitted with no Resources at all, but the Appointment still has Resources eligible to be actioned, the same message is returned. The eligibility test looks at the full set of Resources on the Appointment, so narrowed permissions cannot cause the action to pass silently without doing anything.
* Check-In now applies only to Resources with a status of **Accepted** that have not already checked in. A Resource that has already checked in keeps its original check-in time.
* Check-Out now applies only to Resources with a status of **Accepted** that have checked in and not yet checked out.
* Where the action is refused, neither the Appointment status nor any Appointment Resource is changed.
**Example scenarios**
* ✅ A care worker checks themselves in on a group Appointment → their own assignment is checked in and their colleagues' assignments are untouched.
* ✅ A care worker submits a Check-In that includes a colleague whose record they cannot access → the Check-In is refused with a message explaining they may not have permission to check in other team members, and no Resource is checked in.
* ✅ A Resource on the Appointment is still **Pending** rather than **Accepted** → they are not checked in.
* ✅ A Check-Out is submitted for a Resource who never checked in → they are not checked out and the Appointment status is unchanged.
***
### Check-In Errors Shown Clearly and Retried Reliably
**Reference:** CC-740
We have updated the Check-In screen so that errors are shown as a readable message inside the modal, and so that **Try Again** re-runs the Check-In.
**What's changed**
* Errors raised while completing a checklist are now routed to the Check-In screen's own error handler and displayed in the modal.
* The error message is cleared each time Check-In is submitted, so a retry after a corrected error starts from a clean state.
* Where **Check-In** is pressed before the checklist has finished loading, the screen now reports **The checklist has not finished loading. Please try again.** rather than failing as a component error.
* Error text across the Check-In, Check-Out and Appointment Checklist screens is now produced by a single shared routine, so the message shown is the underlying message rather than a generic failure.
**Example scenarios**
* ✅ A Check-In is refused by a validation rule → the message is displayed in the Check-In modal, and **Try Again** re-submits the Check-In.
* ✅ A care worker taps **Check-In** before the checklist has finished loading → they are asked to try again, and the modal stays usable.
* ✅ A first Check-In attempt fails and the second succeeds → the earlier message is cleared when the second attempt is submitted.
***
### Recurring Unavailability Cancellation Refined
**Reference:** CC-735
We have refined the cancellation and deletion of Recurring Unavailability records so that related Timesheet Entries are cleaned up, a full series delete removes every future occurrence, and the series structure is determined from the Schedule itself.
**What's changed**
* Cancelling an Unavailability now deletes any Timesheet Entry linked to it. The parent Timesheet is retained. Previously the Resource kept a Timesheet Entry for a period they were no longer marked unavailable for.
* Choosing to delete the whole series now removes future **Cancelled** occurrences as well as the rest of the series, rather than leaving them behind against a Schedule whose Master Unavailability has gone.
* Whether an Unavailability is part of a series, and whether it is the Master Unavailability of that series, is now determined from the Schedule relationship stored against the record.
{% hint style="warning" %}
The third point is a behaviour change on an existing action. Where a record is deleted through the simple confirmation path and that record is in fact the Master Unavailability of a series, the Master is now promoted to the next occurrence. Previously no promotion occurred on that path. This is worth confirming during your own testing.
{% endhint %}
**Example scenarios**
* ✅ A Resource cancels a single occurrence of a Recurring Unavailability that has a Timesheet Entry → the occurrence is marked **Cancelled** and its Timesheet Entry is deleted, while the parent Timesheet remains.
* ✅ A Resource cancels an occurrence with no Timesheet Entry → the occurrence is cancelled and nothing else changes.
* ✅ A coordinator deletes a series that contains both Submitted and Cancelled future occurrences → the Master Unavailability and both future occurrences are removed.
* ✅ A coordinator deletes the Master Unavailability and chooses the single-occurrence option → the Schedule's Master Unavailability is promoted to the next occurrence that is not cancelled.
* ✅ A coordinator deletes an occurrence that is not the Master → the Schedule's Master Unavailability is left unchanged.
{% hint style="warning" %}
**Post-install steps required.** See [Cancelled Unavailability Appearance](#cancelled-unavailability-appearance) under Post-Install Steps at the bottom of this page.
{% endhint %}
***
### Master Appointment Promoted Chronologically on Cancellation
**Reference:** CC-751
We have updated the cancellation of a Master Appointment so that the Appointment promoted in its place is the earliest still-active Appointment on the Schedule.
**What's changed**
* Where a Master Appointment is cancelled using **Apply changes to only this Appointment**, the new Master Appointment is now the chronologically soonest remaining Appointment on that Schedule that is not **Completed** or **Cancelled**.
* Where two remaining Appointments share the same earliest start, the selection resolves consistently, so the same Schedule promotes the same Appointment on every run.
* Where no active Appointment remains on the Schedule, the Schedule keeps its cancelled Master Appointment, and the Schedule's Start Date and End Date can still be edited.
{% hint style="info" %}
See **Recurring Schedules** in the Administration Guide for the full set of Schedule cancellation options. After a Master Appointment is cancelled, the Schedule Start Date should still be updated to match the new Master Appointment's start date.
{% endhint %}
**Example scenarios**
* ✅ A coordinator cancels a Master Appointment with **Apply changes to only this Appointment** on a Schedule with several future Appointments → the earliest remaining active Appointment becomes the new Master Appointment.
* ✅ Two remaining Appointments on the Schedule start at exactly the same time → one is promoted consistently, and repeating the cancellation on an equivalent Schedule gives the same result.
* ✅ The cancelled Master Appointment was the only active Appointment on the Schedule → the Schedule retains it as Master, and its Start Date and End Date remain editable.
{% hint style="info" %}
Existing Schedules affected by the previous behaviour can be identified with the **Schedule Master Diagnostic**. See [Post-Install Steps](#schedule-master-diagnostic) at the bottom of this page.
{% endhint %}
***
### Multi-Select Lookups Reload Cleanly
**Reference:** CC-739
We have updated lookup fields in multi-select mode so that adding or removing a selected record reloads the list of available records without error.
**What's changed**
* Adding or removing a selection in a multi-select lookup now clears the search term to an empty value, and the search itself handles an empty search term, so the record list reloads normally.
* A multi-select lookup configured to show all records now returns the full list when no search term has been entered.
**Example scenarios**
* ✅ A user removes a selected record from a multi-select lookup → the remaining selections are retained and the available records reload without an error.
* ✅ A multi-select lookup configured to show all records is opened with no search term entered → every available record is listed.
* ✅ A user types a search term, selects a record, then clears the term → the list returns to showing the available records.
***
## Post-Install Steps
### Schedule Master Diagnostic
Run this in every upgrading organisation to identify Schedules affected by the previous Master Appointment promotion behaviour.
#### Prerequisites
* Client Delivery package version **0.161** or later installed
* The **Modify All Data** permission
{% stepper %}
{% step %}
#### Open the Temporary Jobs Tab
1. From the App Launcher, open **Client Care Settings**
2. Append `#admin=true` to the page URL and reload the page
3. Select the **Temporary Jobs** tab
{% hint style="info" %}
The **Temporary Jobs** tab is only rendered when the page is opened with `#admin=true`, and the **Modify All Data** permission is required regardless of the URL.
{% endhint %}
{% endstep %}
{% step %}
#### Run the Schedule Master Diagnostic
1. Locate the **Schedule Master Diagnostic** card
2. Click **Run Now**
3. Wait for the progress indicator to report the run as complete
The job is read-only. It writes Log records and changes no Appointment or Schedule.
{% endstep %}
{% step %}
#### Review the Results
1. Refresh the **Temporary Jobs** tab to load the run summary
2. Click **View log** to open the run's Info log, which reports how many Schedules were flagged out of how many scanned
3. Open the **Logs** list, filter on a Source of **Schedule Master Diagnostic** and the Job Id of this run, and open the Warning logs
Each line in a Warning log names one Schedule, its current Master Appointment and start time, and the earliest still-active Appointment on that Schedule and its start time.
{% hint style="warning" %}
A flagged Schedule is a review candidate, not a Schedule that necessarily needs changing. A sibling Appointment that was legitimately rescheduled to start earlier than the Master produces an identical result. Review each Schedule with the relevant team before changing anything.
{% endhint %}
{% endstep %}
{% step %}
#### Repoint Confirmed Schedules
For each Schedule confirmed as needing correction, open the Schedule record and update its **Master Appointment** to the proposed Appointment named in the log.
Nothing is repointed automatically. Only the Schedules confirmed in the previous step should be changed.
{% endstep %}
{% endstepper %}
### Cancelled Unavailability Appearance
Complete this in upgrading organisations only. On a first-time install both values are populated automatically and no action is needed.
#### Prerequisites
* Client Delivery package version **0.161** or later installed
* System Administrator profile or equivalent permissions
{% stepper %}
{% step %}
#### Open the Appearance Settings
1. From the App Launcher, open **Client Care Settings**
2. In the left sidebar, select **Planner Management**
3. Select the **Appointments** sub-tab
4. In the **Appearance Settings** card, click **Edit**
{% endstep %}
{% step %}
#### Set the Cancelled Unavailability Values
1. Set **Cancelled Unavailability Colour** to `#AAAAAA`, or to the colour your organisation wants for cancelled Unavailability tiles
2. Set the **Opacity** alongside it to `50`, or to the percentage your organisation wants, between 0 and 100
3. Click **Save**
{% hint style="info" %}
Both values fall back to grey at 50% opacity when left blank, so cancelled Unavailability tiles render correctly either way. Setting them explicitly is what allows the appearance to be changed.
{% endhint %}
{% endstep %}
{% step %}
#### Leave Other Blank Settings Alone
While in the **Appearance Settings** card, do not populate any other blank Planner setting. A blank value elsewhere may be deliberate, and the package no longer writes defaults over Planner settings during an upgrade.
{% endstep %}
{% endstepper %}
## Verification Checklist
After completing the post-install steps above, verify the setup is working as expected.
* [ ] **Temporary Jobs** tab visible in **Client Care Settings** when opened with `#admin=true`
* [ ] **Schedule Master Diagnostic** shows a completed last run with a summary and a **View log** link
* [ ] Warning logs with a Source of **Schedule Master Diagnostic** reviewed, or the summary confirms nothing to review
* [ ] Any confirmed Schedules repointed to the correct **Master Appointment**
* [ ] **Cancelled Unavailability Colour** set on the **Appointments** sub-tab of **Planner Management**
* [ ] **Opacity** set alongside it
* [ ] A cancelled Unavailability renders on the Planner in the configured colour and opacity