We're pleased to announce the latest release of Access Legal Case Management, Version 2.16.6.

This update includes various enhancements and bug fixes detailed below. A PDF copy of the release notes can also be found here.

Custom margin settings configured in ALCM Document Settings are now correctly applied when generating letters. Previously, the first-page margin settings were incorrectly applied to all pages, causing generated Word documents to display inconsistent formatting throughout. Margins are now applied as intended — first-page margins apply only to page one, with subsequent pages retaining their own distinct margin settings.

Resolved an issue where two-page document templates incorrectly inserted a section break at the end of page one during document generation. This section break prevented correct margin formatting from applying to page two, requiring users to manually delete it each time.

The root cause was a trailing empty section being created during the document's page-splitting and merging process. This has been corrected so that generated documents no longer contain unnecessary section breaks, and margin formatting is applied correctly throughout without any manual intervention.

Fixed an issue where navigating to Actions → IHT & Estate in a Probate file caused a 500 error ("Input string was not in a correct format") for firms using custom user screens that shared variable numbers with the Probate module. The conflicting data format now resolves gracefully, allowing the Assets and Liabilities Overview screen to load as expected.

Resolved an issue in the email template editor where clicking within the text area caused text to shift downward unexpectedly. Additionally, the toolbar incorrectly displayed "Arial" as the active font when clicking on an empty row, even when a different font had been applied to the template. Both issues were caused by styled elements being inserted into the document on each click.

Previously, running a Conflict Search by postcode would return no results for non-Client contact types (e.g. General contacts, other side contacts). This was caused by the search querying the wrong data field — postcodes for these contact types are stored against the Contact Company record, not the Contact record directly.

This fix addresses an issue in the Contact persistence flow where the Post Code value was not being properly saved to the Contact table during:

The postcode mapping logic was not consistently executed during the contact save/update process. As a result, some records were created or updated without persisting with the correct Post Code value in the database.

The implementation has been updated to ensure:

Please note: This fix will be effective against new records or newly edited records. A database update will be needed from our Customer Support to address the previous entries prior the fix.