See below for what's included with Inspire Planner's October 2025 - Maintenance 1 ().
Released To:
All Environments: December 1, 2025, at 10 PM ET
Available In:
All Environments: December 2, 2025
Please note:
Content in this release notes are subject to change until December 1, 2025.
Previously, when a user manually assigned a task through the “Assigned To” field, Inspire Planner automatically created a Project Team record for that resource if one did not already exist. This auto-generated record contained no role.
However, if this Project Team record (with a blank role) was later deleted, the system did not unassign the corresponding project tasks from the resource. As a result, tasks remained assigned even though the associated team membership no longer existed.
This behavior has now been fixed.
When a Project Team record without a role is deleted, all project tasks assigned to the same resource with no role association are now automatically unassigned, keeping task assignments consistent with the current team structure.
Project Status no longer incorrectly overridden by Custom Settings.
An issue was identified where the workflow responsible for updating a Project’s Status to In Progress (when % Complete is greater than 0 but less than 100) was incorrectly referencing values from the Custom Setting intended only for Project Task statuses. This has been fixed. Projects will now correctly maintain their intended status values based solely on project-level automation.
After migrating Workflow Rules and Process Builders to Flows, an issue occurred where task assignments failed for Contacts without a value in the First Name field.
This issue has been resolved. The system now correctly sends assignment notification emails even when a Contact’s First Name field is blank.
The Beacon process has been enhanced to check whether any jobs in the chain are still running before starting the next one. This prevents overlap between jobs that could cause record locking issues in Salesforce.
Additionally, the ProjectTaskActualCostRollupBatch job has been updated to better handle Salesforce “record locked” errors. When such an error occurs, affected Sync Queue (SQ) records are now automatically marked as Failed instead of remaining unprocessed.
These improvements ensure smoother job execution, prevent data lock conflicts, and improve system reliability.
The RestoreSharingJob properly handles share records and no longer triggers an exception when encountering failed or invalid upsert results.
Fixed an issue where Sync Queue records created between batch jobs caused missing Actual Effort calculations by ensuring the second job only processes records handled by the first job.
Fixed an error occurring during managed package upgrades in sandbox environments. The trigger logic now skips ContentVersion processing during installation or upgrade, preventing NoAccessException errors.
This section contains fixes we've made specific to the Gantt LWC.
Two issues related to the Save As (Project Cloning) feature have been resolved:
When cloning a project, collaborators with the Editor role were incorrectly downgraded to Viewer in the new project. This has been fixed so collaborator roles are now preserved correctly.
When choosing Not Started as the new project status during cloning, the original project’s status was still being copied over. This has been corrected so the selected status is now applied properly to the cloned project.
These fixes ensure more accurate and predictable behavior when creating projects with the Save As feature.
Previously, when a Time Entry was logged for a child task, Rollup and Team Rollup Sync Queue (SQ) records were created and processed correctly, but no Parent Rollup SQ record was generated. As a result, the parent task’s rollup values were not saved, leaving the UI in a locked state with an “Unsaved Changes Detected” message.
This enhancement ensures that a Parent Rollup SQ record is now automatically created and processed after Rollup and Team Rollup SQ records. This update keeps parent task data synchronized and prevents the UI from remaining locked after time entries are logged.
Further enhancements have been made to the dependency validation updates introduced in GLWC-614. These improvements make the messaging clearer and provide users with actionable options when resolving issues.
Enhancements include:
Adding the word “Row” to the displayed row numbers for improved clarity
Updating the term “cycle” to “cyclical dependency”
Providing a clearer message outlining the steps required to resolve the issue (e.g., a cyclical dependency must be deactivated or removed)
Adding an option for users to deactivate or remove the problematic dependency directly from the message
These improvements create a more intuitive and guided resolution experience for users.
When switching to the LWC version of the component, the Parent Task was incorrectly recalculated and no longer included the completed Milestone in its date roll-ups.
This behavior has now been corrected.
Parent Tasks now properly recognize and include completed Milestone tasks in date roll-up calculations when using the LWC component.
The Project Schedule properly reloads and renders its layout and styling after returning from the Resource Utilization view in Project Team.
The logic has been updated so that the User Default Layout is now applied to all new Projects, including those created from Templates that already contain default settings.
This section contains fixes we've made specific to the Resource LWC (BETA).
Utilization is now calculated and plotted correctly for tasks of any duration, including durations shorter than a full day.
The Attributes bar in the Resources tab now correctly returns and assigns the selected attribute.
This section contains items that are scheduled for or have been deprecated.
The Locked__c field on the Project object will be removed, as it is no longer used. Project locking was previously updated in IP-643 (June 2024 – Maintenance 2 release) to leverage the Lock object instead.