Important
When upgrading to this version, if you have skipped any previous releases, please use the installation links below to proceed as usual. However, we recommend reviewing the release notes for the skipped versions to familiarise yourself with new features, issue fixes, and to ensure compatibility and correct setting requirements.
Compatibility
This package version requires the following mandatory packages in place before installation.
- Skedulo Core Package - 102.56+
- Lumary - 20.3.9+
- Enrite Care Services - 1.307+
No changes to package compatibility since the last release.
What’s New
Replication Date Data in Additional Fields
- When replicating jobs into a new period, date data in the Additional Fields section (e.g: sleepover start date) will be automatically and accurately set based on the new job dates:
- Example 1:
- Base template job:
- Job date: 01/01/2025
- Sleepover start date (or any other date additional fields): 01/01/2025
- Replicated job:
- Job date: 15/02/2025
- Sleepover start date (or any other date additional fields): 15/02/2025
- Base template job:
- Example 2:
- Base template job:
- Job date: 01/01/2025
- Sleepover start date (or any other date additional fields): 02/01/2025
- Replicated job:
- Job date: 15/02/2025
- Sleepover start date (or any other date additional fields): 16/02/2025
- Base template job:
- Example 1:
- The function is implemented when replicating jobs from base templates or from any rosters, and is available when replicating jobs on the Scheduling Console and the Resource Roster Console.
How to set up?
- Navigate to Setup > Custom Settings > Skedulo Configs > new setting Job_Replication_Additional_Date_Fields:
- Use this setting to configure one or many additional fields of Job Object with Date or DateTime data type that need to be date-sensitive and follow new job dates when replicating
- For example: "skedhealthcare__Registration_Date__c; skedhealthcare__Meal_break_start__c; skedhealthcare__Sleepover_start_2__c"
- Default value: blank
UX Enhancements when updating Job Times
- A toggle has been added onto the Schedule Job and Edit/Allocate Job modals whereby it controls whether any updates on job times will automatically reset or keep the service line item times unchanged.
- The toggle has two modes:
- Reset (default): when job times (including Start Time, Duration or End Time) get updated, times on all line items will be reset to match with new job times.
- Keep: when job times get updated, times on all line items will remain as is, allowing schedulers to manually update them afterward.
Service Agreement Date automatically follows Job Date
- In the Schedule Job and Edit/Allocate Job modals, the Service Agreement Date now automatically follows the Job Date, in order to reduce the risk of selecting invalid Service Agreements in case of scheduling future jobs.
Preventing Deletion of Service Agreement Items
- Lumary had advised that deleting Service Agreement Items would need to be prevented if the SAI is linked to any Job Service Items in Skedulo.
- Therefore, an update has been made to the "What to do if the lookup record is deleted?" option in the Service Agreement Item lookup field in the Job Service Item object:
- The value is updated from "Clear the value of this field" to "Don’t allow deletion of the lookup record that’s part of a lookup relationship".
- The value is updated from "Clear the value of this field" to "Don’t allow deletion of the lookup record that’s part of a lookup relationship".
Allied Health Calendar
- The first version of the Allied Health Calendar was released in October 2024
- The new features introduced in this release include:
- Filtering events by work type (jobs, shifts, activities)
- Holiday indicator
- Configuring hover fields
- Creating recurring shifts and activities
- Controlling the Create, Update and Delete actions on jobs, shifts, activities and availability
- Please follow our User Guide to prepare the access to the console (in case you have not) and get familiar with all functionalities that are currently available.
Client Deceased/Inactive Handler
An automatic process is introduced to handle the cases when a contact/client has become inactive or deceased.
This is a background process that will asynchronously update the status of the client as well as automatically cancel related jobs and detach the client from associated base templates.
How to set up and Prerequisites
- Navigate to Setup > Custom Settings > Skedulo Configs > new setting Enable_Client_Deceased:
- Default value: False, meaning the feature is disabled
- Switching the value to True to enable the user interface used to initiate the process
- Navigate to Setup > Custom Settings > Skedulo Configs > new settingClient_Deceased_Log_Exception:
- Default value: False, meaning the feature is disabled
- Switching the value to True to enable writing debug log for every process initiated
- In order to update the status of a client to deceased or inactive, there must be no remaining "active" Service Agreements. Hence to ensure all background actions are executed successfully (including updating the client’s status), the client’s Service Agreements must all be put to inactive states.
Initiating the process
- In a Contact record page, a button is added titled "Cancel Client".
- In case the Contact Record Type is different from "Client", this process is not supported, a warning will be displayed.
- In case the Contact Record Type is "Client", below data points are presented:
- Status:
- Choose this to update the value of the contact’s status field
- Configurations for single jobs:
- Choose these so the system has the data to populate on the cancelled single jobs
- Configurations for group jobs:
- Choose these so the system has the data to populate on the cancelled group attendees of the group jobs
- Status:
Background actions to be expected
- When the process is initiated, below are the expected outputs (very similar to cancelling a single job or a single group attendee, however in bulk with multiple records being processed):
- Single Jobs:
- Job object:
- Future single jobs that have one of these statuses (Queued, Pending Allocation, Pending Dispatch, Dispatched, Ready), will be cancelled (job status updated to Cancelled) with below information populated from the configurations for single jobs:
- Cancellation reason
- Cancellation note
- IsBillable
- Future single jobs that have one of these statuses (Queued, Pending Allocation, Pending Dispatch, Dispatched, Ready), will be cancelled (job status updated to Cancelled) with below information populated from the configurations for single jobs:
- Job Service Item object:
- Associated JSIs will have the data populated in the below fields:
- Cancellation checkbox updated to True
- Cancellation reason
- Cancellation note
- IsBillable
- Associated JSIs will have the data populated in the below fields:
- Job Allocation object:
- Future job allocations of above single jobs that does not have one of these statuses (Deleted, Completed), will be deleted (job allocation status updated to Deleted)
- The late cancellation process (Activities created for the Resources to get paid for) will kick in for the eligible jobs (read more about this here).
- Job object:
- Group Jobs:
- Group Attendee object:
- Group attendees of future group jobs that have one of these statuses (Queued, Pending Allocation, Pending Dispatch, Dispatched, Ready) will be cancelled with below information populated from the configurations for group jobs:
- Attended checkbox updated to False
- Cancellation reason
- Cancellation note
- IsBillable
- Group attendees of future group jobs that have one of these statuses (Queued, Pending Allocation, Pending Dispatch, Dispatched, Ready) will be cancelled with below information populated from the configurations for group jobs:
- Job Service Item object:
- associated JSIs will have the data populated in the below fields:
- Cancellation checkbox updated to True
- Cancellation reason
- Cancellation note
- IsBillable
- associated JSIs will have the data populated in the below fields:
- Group Attendee object:
- Group Event Templates:
- Group clients of group event templates that have status equal to Active, will be removed/deleted.
- Single Jobs in Base Templates:
- Any single jobs (past or future) belong to base templates will be removed/deleted from the base template (the association between the job and the base template will be removed)
- When the single jobs happen to be future jobs and belong to a base template, they will be cancelled and removed from the base template at the same time.
- Group Jobs in Base Templates:
- Group Attendee object:
- Group attendees of any group jobs (past or future) that belong to base templates will be:
- Cancelled with below information populated from the configurations for group jobs:
- Attended checkbox updated to False
- Cancellation reason
- Cancellation note
- IsBillable
- Cancelled group attendees will not be included in the replication process
- Cancelled with below information populated from the configurations for group jobs:
- Group attendees of any group jobs (past or future) that belong to base templates will be:
- Job Service Item object:
- Associated JSIs will have the data populated in the below fields:
- Cancellation checkbox updated to True
- Cancellation reason
- Cancellation note
- IsBillable
- Associated JSIs will have the data populated in the below fields:
- Group Attendee object:
- Single Jobs:
Debug log
- As the setting Client_Deceased_Log_Exception is enabled, the debug log can be used to monitor whether the process has been executed successfully or failed at any point.
Notes: Please contact your CSM or Tech Support or to [email protected] if requiring assistance with the debug log.
Other use cases for consideration
- Use case 1:
- Lumary packages might have triggers or logics that will automatically update the client’s status (for example when the "date of death" field is populated, the status will automatically change to Deceased) or in some cases, client’s status could also be manually updated to Deceased or Inactive by admins.
- The "Cancel Client" process can still be used just to cancel the jobs, the group attendees and clearing the association to the base templates.
- If the client’s status somehow has already been updated to expected value, the system will skip this action and continue on with the remaining.
- Use case 2:
- Client is only "on-hold" temporarily, only jobs within a certain timeframe will need to be cancelled.
- A client on-hold handler process can be utilised instead (check out our User Guide).
Issues Fixed
- The issue has been fixed whereby additional fields are not displayed in Job Edit modal due to conditional display logic.
- The issue has been fixed whereby the Apportionment field of group event jobs in the Timesheet Console did not allow schedulers to enter decimal numbers between 0 and 1.
- The issue has been fixed whereby not all jobs required were replicated via Base Template replication function.
- The issue has been fixed whereby the "Number of resources required" field on Salesforce’s edit job modal and "How many people are required" on Webapp’s job were not consistent.
- The issue has been fixed whereby an error was displayed when trying to submit a timesheet in the Timesheet Console.