Skip to main content

Orchestrate Version 7.84 Release Notes

Written by Charnjit Singh Dharival

We are pleased to announce the release of Access Orchestrate version 7.84


What’s new

The following features are included in this release.

Copy Live to Play

Copy Live to Play rebuilt: progress window, notice period and cancellation

Copy Live to Play has been rebuilt in Orchestrate 7.84. It is now requested and watched from a dedicated Copy Live to Play window instead of a series of message boxes that had to be left open. The window is not modal, so Orchestrate can be used while a copy is waiting or running, and closing it does not affect the copy - reopening it, or opening it on another machine, shows the copy already in progress. Before requesting a copy it shows what will be copied where, whether the Play database exists, how many users are logged in to Play, and the result, timing and requester of the last copy, with a single clearly labelled option for whether the Play users, passwords and permissions are kept or overwritten with Live.

Play users are given notice, and a copy can be cancelled. Play users are told that a copy has been requested, who requested it and how long they have left to finish what they are doing, and are signed out when the copy starts. The notice period ends early once everyone has logged out and is skipped when there is nobody in Play to give notice to. Anyone permitted to run a Copy Live to Play can ask for one to be cancelled, with a message explaining why; the person who requested it is shown the request and can accept it, leaving Play untouched, or reject it and restart the notice period. They can also cancel their own copy outright. Play users can log in again as soon as the copy finishes, is cancelled or fails.

The progress of the copy is now visible. The window shows which of the four stages the copy has reached, who requested it and how long is left of the notice period, and, once copying starts, each of the seven steps as it is reached with a progress bar and the elapsed time. It finishes on a page showing how long the copy took, what was copied from and to, whether the Play user information was kept, and the version of the new Play database. A copy that fails names the error, the step it failed on and whether it can be tried again, with a button to copy the detail for reporting it.

Bug fix: Play user permissions are now restored correctly. When a Copy Live to Play was asked to keep the Play system's user information, permissions given directly to individual Play users were lost - only users, roles and role permissions were put back, so those permissions had to be set up again after every copy. They are now restored along with the users and roles. The import data sources of the previous Play database are also restored, so Play does not end up importing from the Live source systems.

The new Copy Live to Play needs Orchestrate 7.84 or later and Orchestrate Service Agent 1.4 or later. Where either is older, Copy Live to Play behaves exactly as it did before, and Orchestrate says so before falling back to it. The setting that enables Copy Live to Play and the user permission it needs are unchanged.


Administration, Security and Permissions

New permission to control the Error List opening from saved views

Whether restoring a saved view automatically opens the Error List is now controlled by a permission, Auto Show Error List From Saved Views. All existing roles are granted the permission when the database is upgraded, so behaviour is unchanged until an administrator revokes it for a role. Users without the permission no longer have the Error List opened for them when they switch to a saved view that carries the setting, and saving or re-saving that view does not clear the setting for users who do have it. Opening the Error List manually, and the Error List appearing for genuine task conflicts or data errors, are unaffected.

Configurable display time zone for Task History

Administrators can now choose the time zone used to display History Created Date in Task History, under Tools > Options > Other > Task History > Timezone. Times are converted correctly for each entry, including across daylight saving changes, and the Task History screen shows which time zone is being used. The setting is blank by default, so existing sites see no change until a time zone is selected. Non-administrators can view the setting but not change it.

Evo Apps Users: * wildcard row and access-check search; SFDC Staff access-check search

Administrators can now check at a glance whether a user can access the Evo Apps or SFDC. The Evo Apps Users and SFDC Staff forms have a search box: type or paste an email address to see whether that user has access and which row decided it. The Evo Apps Users list now also accepts a * row, so you can express rules such as "everyone except...". The most specific row decides access: a row for the user's own email first, then their @domain row, then the * row; if nothing matches the user has no access. As before, everyone has access when per-site user restriction is off or the list is empty.


Shop Floor Data Capture (SFDC)

Optional ERP Task Ref uniqueness check before publishing to SFDC

Where the SFDC API identifies tasks by their ERP Task Ref, Orchestrate can now make sure that reference is unique before it publishes to SFDC.

A new System Setting, Evo Apps > SFDC API enable ERP Task Ref, controls this. With the setting enabled, publishing to SFDC checks that no two SFDC operations would end up holding the same ERP Task Ref. If they would, the publish stops before anything is sent to SFDC and reports every conflicting works order and operation step, so the duplicate references can be corrected in the ERP. Tasks with no ERP Task Ref are unaffected, and any number of them may be left blank.

The setting is off by default, so publishing to SFDC behaves exactly as it did before until it is switched on. Turning it on is recommended for sites using the SFDC API with ERP Task Refs, as a reference held by two operations means SFDC bookings can be returned against the wrong ERP task.

Faster SFDC publish: planned/removed operations step

Publishing a plan to SFDC is faster. The step that works out which shop floor operations are planned or should be removed now updates only the operations whose values have actually changed, instead of rewriting the whole operation list on every publish, and a supporting index on the tasks table has been widened so the work needed for each operation is a single covering lookup.

There is no change to what the shop floor sees; only the time taken to publish is affected. Note for upgrades: the release rebuilds an index on the task table, which is an offline rebuild on SQL Server editions without online index rebuild support, so it should be applied in a maintenance window on large databases.

Faster SFDC publish: several of the most expensive stages optimised

Publishing the plan to SFDC is significantly faster. Several of the most expensive stages of the SFDC publish have been optimised and no longer rewrite data that has not changed, reducing the overall publish time by more than half on a large test database. The data shown in SFDC is unchanged.


Planning and Scheduling

Add to Plan is much faster for large works orders

Add to Plan could take 20–25 seconds for a single works order on plans where an order expands into a large number of tasks. Planning now completes in well under a second for the same order — a customer order that previously took 23.4 seconds now takes 0.26 seconds — with no change to the resulting plan: the same tasks are created and scheduled exactly as before.

Planning could also perform a full second planning pass in situations where only one pass was needed, and the planning trace window did not open when planning was started from the progress bar; both are corrected. No configuration change is required.

Faster Close Gaps for large multi-order selections

Running Close Gaps on a large multi-order selection is much faster. On a plan with around 21,000 active tasks it could previously run for more than ten minutes without completing; large selections are now processed order by order.


Demand Planner, Stock and Pegging

Demand Planner: more accurate handling of BOMs and target stock

The Demand Planner now handles bills of materials and target stock more accurately. Obsolete sub-assemblies no longer create demand for their components. Topping up a parent item's target stock now also creates the requirements for its components. Changing Target Stock by Date values now refreshes the Demand Planner straight away.


Gantt Chart and Views

Right-click menu on Gantt resource rows and item plots

Right-clicking directly on a resource row or an item plot row in the Gantt chart now offers options for that row: you can open the resource's or item's details for editing, hide the row from the current view, or move it to the top, bottom, up or down one position so the rows you care about sit together. Row ordering applies to the plan you are working in for the duration of the session and is not saved with the plan; the editing options only appear if your user account has permission to edit resources or items. All new menu captions are available in the supported languages.

Clearer borders between adjacent dark task bars

Where two consecutive tasks in a plan were coloured black or a very dark shade, the border of each task bar was the same colour as the bar itself, so the boundary between the bars was invisible and the tasks appeared to be one continuous task. This made task sequencing difficult to read, particularly for users with impaired colour vision.

Task bar borders are now drawn in a colour chosen to contrast with the bar's fill: dark bars are outlined in a light grey, while lighter bars keep the existing dark outline. Adjacent dark task bars now have a clearly visible dividing line, consistent with tasks in other colours, on screen, in print preview and in exported output. Critical path, locked and completed task bar styling is unchanged.

Right-clicking a resource row keeps the selected task

Right-clicking an empty part of a resource row, or the resource name, on the Gantt chart no longer clears the task you have selected. The Edit Tasks pane stays on that task, and the menu shows the resource options (Insert Task, Edit Resource Details, Hide Resource, Move) without task-only options. Left-clicking an empty part of a resource row, the resource name or empty space still clears the selection. Ctrl + Left-click on a task that is already selected now deselects it, leaving the other selected tasks selected.


Task Editor and Actuals

Actuals tab explains why actuals can or cannot be edited when SFDC is enabled

The Actuals tab in Edit Tasks now tells you precisely why a task's actuals can or cannot be edited when SFDC is enabled. Previously a generic "managed in SFDC" warning was shown, and actuals were locked, even for tasks that were never published to SFDC. Tasks that are not published to SFDC are now editable again and the warning explains the reason (for example: no order, no item, not planned, completed, outside the SFDC look-ahead window, secondary resource only, or resource not in a view published to SFDC). When a mixed selection is made, the message shows how many of the selected tasks are managed in SFDC.


Data Screens (Processes, BOM, Resources, Orders)

Apply on process details no longer reloads the whole plan

Clicking Apply after editing process details (op steps, dependencies, secondary resources, cost outcomes) no longer triggers a full plan reload and reschedule, so the Edit Processes screen responds immediately instead of taking 18-20 seconds on a large plan, and the resource "searching" window no longer appears. Adding, copying, deleting or renaming a process still refreshes all screens as before. Works orders added to the plan after the save are expanded using the newly saved process details.

Process detail edits reach existing tasks at the next reschedule, not when Apply is clicked.

Process step KPI imports can identify the multiplier attribute by name

Process step KPIs imported into Orchestrate can now identify their multiplier attribute by name rather than by Orchestrate's internal attribute id. Import definitions that populate MultiplierAttribName (optionally with MultiplierAttribObjectTypeName) previously lost the multiplier entirely, because only the internal id was carried through — forcing integrations to hardcode an id that is not portable between databases.

The named attribute is now resolved during the import. If the name matches no attribute, or is ambiguous across attribute object types, the import fails with a clear message instead of silently storing the wrong attribute. Existing imports that supply the id directly are unaffected and continue to work, so the hardcoded id can be removed at your convenience.

Resource Groups / Labour Groups search improvements

Searching for resources or resource groups on the Resource Groups and Labour Groups screens now handles punctuation such as brackets, asterisks, percent signs and apostrophes, which previously could produce an error or the wrong list of matches. Typing in the search boxes is also more responsive on sites with large numbers of resources.

BOM save errors now list the offending rows and reasons

When a Bill of Materials cannot be saved, Orchestrate previously reported only that errors had been found, leaving you to search the grid for the rows at fault. The message now lists the offending rows by Parent Item, Recipe Qty and Child Item together with the reason each was rejected — a duplicated combination, a parent that is the same as its child, or a circular reference — showing up to five rows plus a count of any remaining ones. The validation rules themselves are unchanged, so the same BOM entries are accepted or rejected as before.

Faster editing and saving of large numbers of processes

Editing large numbers of processes at once is now much faster. Opening a large selection of processes for editing no longer loads the same data twice, and saving only re-checks the processes you actually changed rather than every process on screen, so screens that previously appeared to freeze with several hundred processes selected now open and save promptly. Where another planner already has one of the selected processes open for editing, that is now always reported correctly.


Fixes

Administration, Security and Permissions

Recently added UI text not translated (FR, DE, HU, JA)

User interface text added over the last six months is now provided in French, German, Hungarian and Japanese. This covers the Reset Actuals feature, the Plan Details panel, task Chat, View Properties, the Audit Log column headings, result counts, the Gantt Chart minimum label size option and the resource calendar Displayed Resources heading.

Workspace user provisioning: duplicate or failed user updates

User provisioning from Workspace is more reliable. Users are now matched correctly regardless of how their email address is stored in Orchestrate, so updates no longer create duplicate users or fail, and a change of email address in Workspace updates the existing user. If a Windows account is already assigned to a different Orchestrate user, provisioning now stops with a clear message naming both users. Deactivating users also now works for all stored email formats.

Security: CVE-2026-84008 (System.Security.Cryptography.Pkcs)

A third-party component (System.Security.Cryptography.Pkcs) has been updated to address security vulnerability CVE-2026-84008.

New database creation failed with a password-length error

Fixed an issue where creating a new Orchestrate database could fail with a "password too short" error.


Shop Floor Data Capture (SFDC)

SFDC showed Ready To Start while a predecessor was incomplete

SFDC could show an operation as Ready To Start even though one of its predecessor operations had not been completed. This happened straight after an operator booked a preceding operation, when the incomplete predecessor sat on a different branch of the job's dependency network from the one that was booked. The status corrected itself on the next full plan publish, so shop-floor operators could briefly be shown work as available before it genuinely was.

Operation statuses in SFDC now take every predecessor into account as soon as a booking is made, so they match the status shown in the Orchestrate plan immediately and no longer change on the next publish.

Reset Actuals failed on databases converted to SFDC with a WDB file

Databases that were created through Database Management and later converted to Shop Floor Data Capture (SFDC) using a WDB file were missing two required database objects. As a result, the Reset Actuals screen failed with an Invalid object name error and could not be used on those databases.

The missing view and stored procedure are now created automatically as part of the SFDC conversion, so Reset Actuals works on databases converted to SFDC after they were created. No user action is required — the objects are applied on upgrade.

SFDC actuals could be deleted from View Actuals

Actuals that originate from Shop Floor Data Capture (SFDC) can no longer be deleted from the View Actuals screen. If a selection contains at least one SFDC-linked actual, the whole delete is blocked and a warning is shown – those actuals must be removed through the Reset Actuals workflow. Deleting non-SFDC actuals now asks for a Yes/No confirmation (defaulting to No) that states how many rows will be deleted. All new messages are fully localised (EN, DE, ES, FR, HU, JA).

Database upgrade failed when SFDC was switched off or never installed

Upgrading a database that had the SFDC integration switched off, or had never had it installed, could fail during the database upgrade and leave it incomplete. These upgrades now complete. Upgrades of SFDC databases are unchanged.

Part-allocated material usage blocked stock consumption on task start

Where Orchestrate is configured to consume stock automatically when a task is started (SFDC auto-allocation), tasks whose material usage had been left part-allocated no longer fail to consume stock. Previously such a task showed the registered usage but the buffer stock was never reduced, and running Reset SFDC Actuals could not clear the condition, so the task could never consume stock again.

Starting an affected task now repairs the usage and deducts the stock as expected (for example a 150 kg usage against a 1,000 kg buffer now leaves 850 kg). Reset Actuals clears a stale usage allocation while keeping the usage value that was recorded, so the next start consumes cleanly. Material usage that was already allocated correctly is untouched and is never consumed twice. No configuration change is required.

SFDC views listed tasks via secondary resources when the option was off

When the option to show tasks on secondary resources was turned off, SFDC views could still list a task that only reached the view through one of its secondary resources, and turning the option off did not remove tasks that were already showing. A view now lists only the tasks whose primary resource belongs to that view, and changing the option updates every view the next time a plan is saved.

Additional attribute changes did not reach SFDC operations

Changing an additional attribute on a task, works order or item did not always reach the shop floor: the operation kept showing the value it had when it was last sent, and no later edit or refresh would correct it. Attribute changes now appear against the operation the next time data is published, including operations that have already been completed but are still inside the retention period.

SFDC operation-chat comments duplicated as Orchestrate Messages

Comments posted in the SFDC operation chat are no longer duplicated under "Orchestrate Messages" after the plan is saved. Existing duplicate comments are removed automatically during the upgrade, and the clean-up and future comment deletions run quickly on large databases.

Publish to Web view edits did not reach SFDC until an unrelated change

Changes made to a Publish to Web view in View Manager, such as adding, removing or renaming labels or adding resources, now appear in Shop Floor Data Collection on the next scheduled publish. Previously, SFDC could keep showing the old labels for hours or days, until unrelated scheduling data changed or a full republish was run.


Planning and Scheduling

Task deadline lost on the final op step after editing and saving a plan

Task deadlines are no longer lost when a plan is edited and saved. Previously, the deadline on the final operation of an order could be cleared automatically and saved to the database as empty, so a manually re-entered deadline disappeared again on the next save. Deadlines set on tasks, and deadlines derived from the order, are now retained.

When several tasks with different deadlines are selected in the Task Editor, the deadline field no longer writes over the individual task deadlines unless the deadline is actually shown and edited. The same applies to the earliest start date.

Behaviour change: a deadline derived from the first pegged usage is now kept when the pegging is removed (for example when demand is cancelled or an order quantity is reduced). It is no longer cleared automatically and can be cleared by the planner in the Task Editor.

Full shuffle of a single capacity resource left a task unplaced but flagged as planned

If tasks were dragged onto a single instant on a single capacity resource and that resource was then fully shuffled, a selected task could be left at those collapsed dates — occupying no time on the resource — while still being shown and saved as planned. The shuffle now recognises a planned task that has work time but no duration and replans it, so both tasks are placed in sequence with their real durations.

In addition, when a shuffle genuinely cannot find anywhere to place a task, the task is now returned to the times it held before the shuffle and the existing "tasks could not be planned" warning is raised, instead of the collapsed dates being published as a successful plan.

Repair Pegging Links ignored Usage KPIs measured at task end

Repair Pegging Links did not respect a Usage KPI measured at the end of a task. Where a consuming task recorded its material usage at task end, repair moved the task so that it started at the time the material became available, instead of finishing then, pushing the task later than necessary and, in the ticket scenario, planning it well beyond what the pegged supply required.

Repair Pegging Links now applies the material-availability date to the correct point of the consuming task — its start for usages measured at start or during the task, and its finish for usages measured at task end — so tasks move by the minimum valid amount, keep their duration, and remain valid against calendars and resource capacity. Tasks with a mix of start-side and end-side usages satisfy each independently. No configuration change is required.

Delete All Tasks for Orders did not synchronise to other users

When a user deleted all tasks for an order from the Order Planner, other users who had the same plan open could still see those tasks after saving or refreshing the plan — the deletion only disappeared for them once they closed and reopened the plan. This could make deleted orders look as though they still existed, produce apparently duplicated tasks if the order was added to the plan again, and show misleading resource overload warnings. Deleting from the Gantt chart was not affected because it used a different internal route.

Both delete routes now share the same corrected process, so every connected user sees the deletion on their next save or refresh, and a delete that cannot be completed is now reported to the user instead of failing silently. No configuration change is required; the fix applies automatically on upgrade.

Unplan missing from Order Planner for partially planned orders

In the Order Planner, the right-click Unplan option disappeared for a works order that was only partially planned — for example after unticking some of its tasks in the task planner — even though the order still had planned tasks that could be unplanned. Users had to unplan those tasks another way.

Unplan is now offered whenever the selected order still has at least one planned task, and unplans those tasks. It remains hidden for orders with nothing planned, and the Planner permission requirement is unchanged.

Plan open appeared stuck at Step 17 of 20

Opening a plan could appear to hang at around 85% ("Step 17 of 20") with the application unresponsive, forcing users to close Orchestrate. The plan was not actually stuck: the automatic shuffle performed on plan open had failed — typically because an operation's resource group has no valid rate, rule or shift pattern for the required window — and the warning dialog reporting it was being drawn behind the always-on-top loading progress bar, waiting for a response that could not be given.

The warning now appears in front of the loading progress bar and can be dismissed, after which the plan finishes opening normally. The underlying planning condition is a data issue and is still reported in the same warning, so no configuration change is required.

Plan reload/refresh froze when a single task could not be planned

Reloading or refreshing a plan — for example after editing production rates via Items → Production Rates — could freeze Orchestrate for several minutes and end in a generic "Load Orchestrate Plan Data — An unexpected error occurred" message with the plan only half loaded, requiring a forced close. This happened when a single existing task in the plan could not be planned during the automatic shuffle, because its process had no valid rate, rule or shift pattern on its resource group.

The load or refresh now completes: the rest of the plan is shuffled as normal, the task that cannot be planned is left unplanned, and a Plan Shuffling warning names the process, operation step, resource group, item and order concerned so the data can be corrected. The same warning is now also shown after a refresh, not just when a plan is first opened.

Works orders with only archived tasks shown as Planned in Order Planner

Works Orders whose tasks are all archived no longer appear as Planned when they have no active planned tasks.

Plan would not open with an unsatisfiable Start-Start maximum offset

A plan would not open when it contained a Start-Start dependency whose maximum offset could not be satisfied by the resources of the tasks involved. The shuffle that runs while the plan loads was abandoned part-way and the plan never opened (in 7.82 it reported that it had opened when it had not).

The plan now opens. The task set that cannot be planned keeps the dates and resources it already had and is marked with a "CANNOT PLAN: Maximum offset conflict with Op Step ..." note, and every other task is shuffled as normal. A warning notification naming the plan is shown so the conflicts can be reviewed and resolved in the Error List. The same warning is now also raised for a plan refresh and for an interactive shuffle, which previously reported nothing until the next time the plan was loaded.

Any other planning problem still stops the load as before, so genuine failures are not hidden.

Secondary resources lost when an order was unplanned and replanned

Tasks could lose their secondary resources when an order was unplanned and replanned. The task looked correct while the plan stayed open, but after the plan was saved and reopened (or copied) a replan allocated the primary resource only, so the secondary resource requirement defined on the process was silently dropped.

Secondary resource requirements created in Orchestrate (through the task editor or when creating a task) are now saved to the database with the rest of the plan, and replanning recovers a task's secondary resources from its existing allocations if the requirements are missing, so unplan/replan keeps both primary and secondary resources with their original quantity and timing. Plans already saved without their secondary resource requirements are repaired automatically by the database upgrade.

Save plan error when several planners saved at the same time

Saving a plan could report "an unexpected error occurred" when several planners saved at around the same time, even though the plan had in fact been saved — pressing OK and carrying on was the only workaround. The error came from the housekeeping step that removes tasks belonging to cancelled orders, which runs after the plan has been committed and timed out while waiting on locks taken by the other saves.

That cleanup now has a sensible time limit and, if it cannot complete, no longer fails the save: the plan is saved as normal and a warning is shown in the status bar instead of an error dialog. The cleanup also runs whenever a plan is opened, so any tasks it skipped are removed then.

Shuffle slow once a works order or item is applied to a task (7.83 regression)

Shuffling a plan could take from ten seconds to a minute once a works order or item had been applied to a task, on plans where it had previously been quick. Shuffles now complete in the time they used to take and produce the same plan as before. Larger plans and busier resources see the biggest improvement.

Unrelated tasks drifted days later on each save when overloads allowed

When a plan was set to allow overloads, editing or saving it could push tasks that had nothing to do with the change several days later, and the movement built up on every save until resources showed as overloaded in random parts of the plan. Tasks now stay where they are unless a change has genuinely broken one of their dependency links, in which case they still move to keep the link valid. Dates that had already drifted are not moved back, but no further drift will occur.

Tank Filling: Clean task dependencies differed between Plan All and replan

Fixed an issue with the Tank Filling functionality where the Clean task on a buffer order received different dependencies depending on how it was planned. Previously, after running Demand Planner → Plan All, a buffer order's Clean task was only linked to its Final Make task, and the Filling → Clean dependencies only appeared once the order was unplanned and replanned on its own via Order Planner → Add to Plan.

The Clean task now receives the same Finish-Start dependencies (its Final Make task plus one link from every Filling task pegged to that buffer batch) whether the order is planned through Plan All or replanned individually. Task positioning and existing shuffle behaviour are unchanged.

Saving a task removed its link to the order release date and deadline

Saving a change to a task (for example editing Task Notes) no longer removes the task's link to its Order Release Date and Order Deadline. Tasks now continue to follow the order dates when those dates change.

Algorithm Planner showed 'No algorithm has been found' after switching algorithms

Algorithm Planner now shows the correct step details when you switch back from an algorithm that has no steps; previously the message "No algorithm has been found. Please define one." stayed on screen. When the selected algorithm has no enabled steps, the planner now says so and points to Planning > Algorithm Manager. "No algorithm has been found" is only shown when no algorithm exists.

Algorithm Planner: Demand Planner step error showed '{0}' and opened behind Orchestrate

When a Demand Planner step fails during an Algorithm Planner run, the error dialog now shows the actual error message instead of placeholder text. It also opens in front of Orchestrate instead of behind it. The same message fix applies to Demand Planner Plan All.

No feasible result when a same-resource chain had to move later to meet a max offset

Fixed an issue where planning a works order could fail with "No feasible result" even though the resource had enough free time. This happened when operations linked to run on the same resource had to move later to meet a maximum offset with a following operation, and the resource group contained only one resource. The planner now moves the linked operations later on the same resource and the order plans successfully.

Reduce Waiting Times did not move the task to its Secondary Min Offset

With secondary offsets enabled, Planning > Replan > Reduce Waiting Times now moves the selected task so that the waiting time is reduced to the Secondary Min Offset. Previously the task did not move.

Dragging Use Rate Table op steps past a rate From Date kept the old rate

After dragging op steps that use a rate table past a rate From Date on the Gantt chart, the rate for the new date is now applied. Previously the op steps kept the rate for their original start date.

Changing only Work Start did not move a locked task (Drag Tasks Insert Successors OFF)

With the Drag Tasks Insert Successors system parameter OFF, changing only the Work Start of a locked task in Edit Tasks was ignored, so the task stayed where it was. The task now moves to the new Work Start and stays locked, even if that is before its Start no earlier than. Unlocked tasks linked to it by a fixed start-to-start offset follow it. Unlocking the task afterwards moves it back to its Start no earlier than or later. With the parameter ON the task already moved, and it still does. Dragging a locked task on the Gantt chart is still blocked, as before.


Demand Planner, Stock and Pegging

Stock plot negative straight after a production task was completed

The stock plot could dip below zero as soon as a production task was booked as complete, even though the underlying stock figures were correct. Production of an item with a shelf life was added to headline stock with no date and then expired as a single block shortly after the plan's status date, so demand later in the plan had nothing left to consume and the plot showed a negative balance.

Production booked against an item that has an expiration period is now recorded as an individually dated stock lot, one lot per quantity booking, with its own expiry date taken from the booking date plus the item's expiration days — so three bookings of 100 on three different days create three lots expiring on three different days. Opening stock is now only expired for the quantity the rest of the plan does not need. The stock plot therefore stays non-negative after completion while genuinely expiring surplus stock exactly as before. All booking routes (the Orchestrate Actuals form, Evo SFDC and ERP-imported actuals) behave the same way, and items with no expiration period are unaffected. The change applies to newly booked production only; quantities already sitting in headline stock are not converted.

Booking production did not convert consuming tasks to Usage (Stock)

Booking a production actual now moves the consuming tasks from Usage (Planned) to Usage (Stock). Previously the booked quantity was added to the item's stock but the tasks consuming it carried on showing Usage (Planned), so the plan did not reflect that the material physically existed.

- The booked quantity is converted to Usage (Stock) on the consuming tasks, earliest usage first, and a partial booking converts only what was booked.

- A corrective (negative) booking takes the Usage (Stock) back off again, so the plan does not claim stock that no longer exists.

- Pegging you have locked by hand is left alone, and a booking never converts more than the item's stock can cover.

Plan calculation corrections found by extended automated testing

Corrections to plan calculations found by extended automated testing: stock and KPI plots no longer fail when an item has no production plot, demand planner rows for obsolete or unpegged items are removed instead of being left behind, saving a plan no longer attempts to write a database-managed timestamp column, task Ready To Start statuses are refreshed after planning, and an empty filter group is no longer loaded as an incomplete filter condition.

Demand Planner planned batches too late with the Start By Date method

In the Demand Planner, made items added to the plan with a Start By Date method were released later than the Start By date shown in the grid — later by exactly the item's supplier lead time — so the batch could only ever be planned late and available capacity between the Start By date and the release date could not be used. With a 4-day supplier lead time, a batch with a Start By date of 15 November was released, and therefore planned, from 19 November. Adding the same demand with the Add to Plan Date method behaved differently, which is why the two methods gave inconsistent results.

Made items planned by Start By Date are now released on the Start By date itself, so the batch can be scheduled into any free capacity from that date onwards and meets its required date where capacity allows. Where the demand genuinely cannot be met, the existing planning exception is still raised rather than a batch being silently planned late. Purchased items, the Add to Plan Date and Campaign Start Date methods, and target-stock replenishment are unchanged. No configuration change is required.

Demand Planner: Start By (Start of Week/Month) used the Planning Start Date's week/month

In the Demand Planner, the Start By (Start of Week) and Start By (Start of Month) values now fall at the start of the week or month of the item's Start By date. Previously they could be moved to the week or month of the Planning Start Date instead.

Demand Planner (Start By Date): target stock replenishment released too late

In the Demand Planner, with the Start By Date method, target stock replenishment batches are now released as early as possible after the Start By date (taking purchased component availability into account where that check is enabled). Previously they could be released at the end of the look-ahead period less lead times, so batches were planned much later than necessary.


Gantt Chart and Views

Print Preview (Ctrl+F2) stopped working in Agenda View and Work List

Fixed an issue where the Print Preview keyboard shortcut (Ctrl+F2) stopped working in the Agenda View and Work List after a task was selected. Ctrl+F2 now opens Print Preview in these views whether or not a task is selected.

Material Dependencies view (Items) crashed with a duplicate key error

The Material Dependencies view could crash with "An item with the same key has already been added" when it was displayed with the view option set to Items for an item that is both produced and consumed by the same task (for example rework, by-product or scrap-back scenarios). Once the error occurred the view failed to build and further errors appeared when navigating between screens.

The view now correctly handles a task that both produces and uses the same item, listing that task once instead of raising an error. The Material Dependencies view opens and refreshes normally for these items. No data changes are required.

Material Dependencies Resource Capacity toggle did not draw capacity

The Resource Capacity button in the Material Dependencies panel now plots capacity as soon as it is switched on. Previously the button appeared to do nothing until you clicked a task or the plan refreshed. With a task selected in the Material Dependencies panel, switching the toggle on immediately shows the used and available capacity of that task's allocated resources, making overloads visible straight away. Switching the toggle off continues to remove the capacity rows.

Grey pegging lines disappeared when a task scrolled off screen

When viewing a plan on the Gantt chart, the grey dotted line showing

where a task's material comes from disappeared as soon as the supplying task was scrolled out of view, making it hard to follow a demand across a long plan. The line now stays on screen and points towards the supplying task even when that task is outside the visible area, matching how the blue dependency lines already behave.

Gantt vertical scroll position reset on refresh or save

Previously, refreshing or saving a plan moved the Gantt chart back to the very first row, so you had to scroll down again to find where you were working. The chart now stays where you left it when you refresh or save. Choosing a different planner view still starts you at the top of the chart, as before.

Zoom stopped responding after Algorithm Planner Execute All Steps

Fixed an issue where zooming the Gantt chart (right-click drag, or the toolbar Zoom In/Out buttons) stopped working after running Algorithm Planner > Execute All Steps, until the Current Plan was reopened. Zoom now responds normally.

Error List opened on every task edit for existing resource rule warnings

The Errors and Warnings panel opened by itself every time a task was edited or applied on a plan that already had a resource rule warning, even though nothing new had gone wrong. It now opens only when an edit actually introduces a new resource rule violation.

View Manager: Saved Views not pre-selected with the view in use

View Manager now opens with the view currently in use already selected in the Saved Views list, so after changing that view you can simply click Save instead of having to reselect it or use Save As.

View Manager: error when saving with a blank view name

In View Manager, clearing the view name in the Saved Views box and then clicking Save no longer causes an unexpected error. The previously selected view name is restored and the save applies to that view.

View Manager: duplicate entry after overwriting a saved view

In View Manager, overwriting an existing saved view with Save As no longer shows the view twice in the Saved Views list.

View Manager: Critical path offered when Critical Path Analysis is disabled

View Manager no longer offers the "Critical path" option when Critical Path Analysis is not enabled. Previously the option could be ticked and saved but had no effect.

View Manager: Delete after filtering deleted the wrong view

In View Manager, typing to filter the view list and then clicking Delete now deletes the view you selected, rather than the first view in the list. The confirmation prompt now names the view that will be deleted. Save, Save As and Set Default also now always apply to the selected view after filtering. Note: views deleted in error before this fix can only be recovered from a database backup.

Gantt could not scroll or zoom to the end of the planning horizon

On the plan chart, scrolling or zooming towards the end of the planning horizon could stop short, so tasks scheduled near or beyond the end of the planning range appeared to vanish or jump back into view. The chart now scrolls and zooms all the way to the last scheduled task, and the planning range setting is applied in years as intended.

Sites that entered a large number to work around the old behaviour should check the planning range setting, as it is now read in years.

Edit Resource Details opened an empty form for Labour resources

Right-clicking a Labour resource on the Gantt chart and choosing Edit Resource Details now opens the Labour form with that labour record loaded. Previously an empty form was shown. The option is now hidden for resource types that have no details form (Utilities and Projects), and for Labour rows when Labour is switched off.

Mouse-wheel vertical scrolling stopped with many task overview labels

Vertical mouse-wheel scrolling on the Gantt chart now keeps working when a view has many task overview labels or Windows display scaling is above 100%. Previously wheel scrolling could stop once a certain number of labels was configured, although the scrollbar still worked.


Task Editor and Actuals

Schedule tab links overlapped dates at display scaling above 100%

On screens using a display scale above 100%, the Task Editor's Schedule tab could draw the "set earliest start" and "set deadline" links on top of the date they sit beneath, making the date hard to read and awkward to click. The Schedule tab now lays those rows out to suit the display scale, so the dates, the components ready and required on plan information, and the links each sit on their own line at any scaling.

Actuals tab: 'must be saved into the current plan folder' warning hidden

When SFDC is enabled, the Actuals tab in Edit Tasks now correctly shows the warning "This plan must be saved into the current plan folder to record an actual" for plans outside the current plan folder. Previously this warning was hidden or replaced by the "managed in SFDC" message.

Actuals tab: status list stayed restricted to Completed

On the Actuals tab, after looking at a task that is managed on the shop floor system, the Status list stayed limited to Completed when a task that is not managed there was selected next. The full set of statuses is now available again as soon as such a task is selected.

Attributes tab blank on first task opened; Apply could clear attributes

Fixed an issue where, after opening a plan, the first task opened in the Edit Tasks panel (e.g. by double-clicking it on the Gantt chart) showed blank values on the Attributes tab, even though the attributes were set and visible on the Gantt label. Clicking Apply, or moving/changing the task, would then overwrite the task's attribute values with blanks.

Task attributes are now displayed correctly the first time a task is opened, and applying changes on the Edit Tasks panel only saves attributes that have actually been changed, so existing attribute values can no longer be cleared accidentally.

KPIs grid quantity columns showed 2 decimal places instead of 3

In the Task Editor KPIs grid, the Total Item Stock, Stock Value, Planned Value and Unplanned Value columns now show three decimal places, consistent with Total Value, so equal values no longer look different.


Data Screens (Processes, BOM, Resources, Orders)

Edit Processes: repeating 'Value cannot be null' error

Fixed an issue on the Edit Processes screen where leaving a Process Code (or a resource code) blank produced a repeating "Value cannot be null. Parameter name: key" error that could not be dismissed, forcing users to discard their changes. A missing code is now reported as a normal mandatory-field validation message, and if an unexpected grid error does occur the offending entry is undone so the screen stays usable. Duplicate-code checking also now ignores surrounding spaces and no longer reports a record as a duplicate of itself.

Suppliers: adding a new supplier failed

Adding a new supplier on the Suppliers screen failed with the message Column 'UpdateTimestamp' does not allow nulls, preventing the supplier from being saved. Suppliers can now be added and saved as normal.

Deleting purchase orders and works orders failed

Deleting purchase orders or works orders no longer fails with an unexpected error. Deleting an order previously threw an error when no plan was open, threw a concurrency error when a plan was open, and could also fail with a database error when the order was involved in defined pegging, so the order was never deleted cleanly.

Orders can now be deleted from the Purchase Orders and Works Orders forms with or without a plan open. The tasks of the deleted orders are removed from every plan (previously only the open plan), and any defined peggings for those orders are removed with them.

Copied process not shown in Process Details until saved

On the Processes screen, a newly copied process is now carried across to the Process Details tab without having to save first. Previously the grid selection stayed on the original process, so Process Details showed the original rather than the copy that had just been created and edited, unless Apply was clicked beforehand.

Copying several processes at once selects the last copy created. There is no change to any other navigation on the screen, and no configuration change is required.

Error saving a stored filter changed by another user

Fixed an unexpected error when saving or deleting a stored filter that had been changed or deleted by another user (or another screen) since it was loaded. Your change is now saved: if the filter was edited elsewhere, your version is kept; if it was deleted elsewhere, it is re-created with your criteria. Deleting a filter that is already gone no longer shows an error.

Unexpected error applying order edits with an unset order code

Applying order edits now gives a clear field-validation message when an order code is unset, instead of an unexpected-error dialog. Existing automatic numbering for new orders is unchanged.

Edit Processes: typed Code lost when clicking another row

On the Edit Processes screen, typing a Code for a process that had no Code and then clicking directly onto another row no longer raises an error and no longer discards the Code you typed. The Code is now kept as expected.

Errors in the Op Dependencies and Task Dependencies grids

Fixed unexpected errors in the Op Dependencies grid on the Processes screen and in the Task Dependencies dialog. Moving the mouse over the grid's row headers, or copying/editing a dependency row before its Relation Type has been chosen, no longer causes an "unexpected error" message.

Edit Processes: deleting processes took around 20 seconds

Deleting a process on the Edit Processes screen could take around twenty seconds, and the screen appeared frozen while it happened, on systems with a large number of processes. Deletion is now effectively immediate, and the screen no longer flickers while the related op steps, dependencies and resource requirements are removed.

Yearly Data / Target Inventory: cursor landed on the wrong row after editing

On the Yearly Data and Target Inventory screens, changing the value the list is sorted by and then moving straight to another row could put the cursor on the wrong row, because the list re-ordered itself while the cursor was still moving. The list now re-orders once the move has finished, so the row you clicked is the row you land on and the edited row stays selected as it moves to its new position.

Error deleting rows on Edit Resources and other data entry screens

Fixed an unexpected error that could occur when deleting rows on the Edit Resources screen and other data entry screens.

Order Planner: custom attribute column blank when its code contains a space

In the Order Planner, a works order or item custom attribute whose code contains a space now shows its value in the grid. Previously the column was always blank, although searching on the value still found the order.


Messages

Messages badge counted the whole imported SFDC chat history; dialog hung on open

On sites with a long SFDC Operation Chat history, the Messages toolbar button no longer counts every imported historical message as unread, and the Messages dialog no longer hangs repeatedly when opened.

Messages slow with Only current view; Mark All As Read ignored filters

The Messages dialog is now fast with Only current view ticked, including when the Gantt view changes. Mark All As Read now asks for confirmation when the current filters hide some messages, so messages you have not seen are not marked as read without warning.


Stability

Five crashes reported by customer telemetry on 7.83

Five crashes reported by customer telemetry on 7.83 have been fixed. Each occurred in a situation where the application was closing or a database connection had dropped:

- Closing Orchestrate with a plan open could crash the client (the most frequent of the five).

- If the database connection dropped while a plan was loading during sign-in, the client terminated at sign-in instead of reporting the lost connection.

- A plan shuffle could abort with an internal error when a task appeared more than once in the task list.

- Clicking the Gantt views button on a plan window that was closing could crash.

- Pasting a block of cells that extended beyond the last row or column of a grid could crash after the paste had already been applied.

No behaviour changes on normal operation and no configuration change required.

Plan load failed with 'ExecuteReader requires an open and available Connection'

Loading a plan could fail with "ExecuteReader requires an open and available Connection", and in some cases take the client down at sign-in, because the database connection being used by the load was closed by another part of the application while the load was still running. The step reported in the error varied, since no single query was at fault.

Plan loading now uses its own dedicated database connection for the whole load, and other screens no longer close a shared connection that they only borrowed, so long plan loads are no longer interrupted. A separate fix stops a grid failing to release resources when a window closes. No configuration change is required.

Intermittent error allowing or disallowing resource overloads

Fixed an intermittent error that could appear when allowing or disallowing resource overloads, or when a resource capacity constraint was changed, on plans where resource capacity was being recalculated.

Intermittent error while tasks were being shuffled

Fixed an intermittent unexpected error that could appear while tasks were being shuffled. If a task was removed from the plan, or the plan's setup or relationship data was not yet available while a shuffle was running, Orchestrate now skips that task instead of showing an error dialog.

Intermittent error in Demand Planner or Close Gaps while the plan was changing

Fixed an intermittent unexpected error that could appear in the Demand Planner, or when using Close Gaps, while the plan was being changed by another operation at the same moment. Orchestrate now treats the plan as changed and carries on, instead of showing an error.

Crash in auto-complete fields under Remote Desktop / Citrix

Orchestrate no longer crashes when a text box or drop-down with auto-complete is opened in a Remote Desktop / Citrix session. Previously, if the Windows user profile registry keys used by auto-complete were unavailable, the application could fail with an unhandled error (0x800703FA). Auto-complete suggestions are now switched off automatically in Remote Desktop sessions so that affected screens open normally. Auto-complete continues to work as before for users running Orchestrate locally.

Intermittent error displaying resource rules that reference attributes

Fixed an intermittent unexpected error that could occur when displaying resource rules that reference attributes.

Orchestrate froze for minutes when closing on some databases

Fixed Orchestrate freezing ("Not Responding") for several minutes when closing the application on some databases. Closing Orchestrate now completes in a few seconds. Old attribute-deletion tracking records are now cleared automatically as part of the regular old-data cleanup, so they no longer build up over time.

Error on sign-out with Shift Pattern Assignment open

Fixed an unexpected error in Orchestrate Planner when the session ended, the user was signed out (for example the session expired, an administrator terminated the session, or the user signed in on another computer), or the application closed while the Shift Pattern Assignment window was open with changes. The window now closes cleanly and sign-out finishes without the "unexpected error" message.

Task History Service Broker conversations accumulated in the database

Task History no longer leaves database messaging conversations open each time history is recorded. On busy databases these could build up into many thousands of entries.


Additional information

Compatibility and prerequisites

· The new Copy Live to Play experience requires Orchestrate 7.84 or later and Orchestrate Service Agent 1.4 or later. Where either is older, Copy Live to Play behaves as it did before and Orchestrate says so before falling back to it. The setting that enables Copy Live to Play and the permission it needs are unchanged.

Upgrade notes

· The upgrade rebuilds an index on the task table. On SQL Server editions without online index rebuild this is an offline rebuild, so apply the upgrade to large databases in a maintenance window.

· The following data corrections run automatically during the upgrade, with no user action required: duplicated SFDC operation-chat comments are removed; plans saved without their secondary resource requirements are repaired; the view and stored procedure needed by Reset Actuals are created on databases converted to SFDC with a WDB file.

· Upgrades of databases that have SFDC switched off, or have never had SFDC installed, no longer fail during the database upgrade.

· The first SFDC publish after the upgrade takes longer than usual, because operation labels are refreshed for every view once. Sites with very large plans are most affected.

New settings and permissions

· New permission Auto Show Error List From Saved Views. All existing roles are granted it when the database is upgraded, so behaviour is unchanged until an administrator removes it from a role. Roles created after the upgrade do not have it until it is granted.

· New System Setting Evo Apps > SFDC API enable ERP Task Ref, edited in Orchestrate System Manager. It is off by default; turning it on is recommended for sites that use the SFDC API with ERP Task Refs.

· New option Tools > Options > Other > Task History > Timezone. Blank by default (no change); only administrators can change it.

· Evo Apps Users now accepts a * row, and the most specific row decides access (email, then @domain, then *). Review existing lists if you plan to add a * row.

Behaviour changes to be aware of

  • A task deadline derived from the first pegged usage is now kept when the pegging is removed (for example when demand is cancelled or an order quantity is reduced). The planner can clear it in the Task Editor.

  • Actuals that came from SFDC can no longer be deleted from the View Actuals screen; use Reset Actuals instead. Deleting other actuals now asks for confirmation.

  • The Errors and Warnings panel now opens by itself only when an edit introduces a new resource rule violation.

  • Auto-complete suggestions in text boxes and drop-downs are switched off in Remote Desktop / Citrix sessions, so affected screens open without crashing. They still work for users running Orchestrate locally.

  • Gantt row ordering set from the new right-click menu lasts for the session and is not saved with the plan.

  • Production booked against an item with an expiration period is now recorded as individually dated stock lots. Quantities already held in headline stock are not converted.

  • Task dates that had already drifted because of the overload issue fixed in this release are not moved back automatically, but no further drift will occur.

  • Views deleted in error by the View Manager filter issue fixed in this release can only be recovered from a database backup.

  • Process step KPI imports that supply the multiplier attribute by name now fail with a clear message if the name matches no attribute or is ambiguous, instead of losing the multiplier.


Localisation

User interface text added in recent releases (Reset Actuals, Plan Details, task Chat, View Properties, Audit Log and more) is now translated into French, German, Hungarian and Japanese.

Security

Third-party component System.Security.Cryptography.Pkcs updated to address CVE-2026-84008.


How this version will be made available

Request: Please start a conversation on the Access Community Portal. How to contact Support via the MyAccess Portal | Orchestrate Help Centre

Did this answer your question?