The EHS release sent out in late August 2026 includes several new features and improvements. The following is an overview of the changes that will roll out. If you have any questions, please submit a support ticket via Customer Hub.

Creating a subform from a Tab Section is one of the most common and important configuration interactions in the platform - and it was also one of the most awkward. You'd name the same thing three times, in three different places, with a click between each one, the subform would default without a form section, which you'd be forced to add before being able to add a question and by the end you'd be retyping a tab section title you'd already entered two minutes earlier.

That whole dance has been tidied up. When you hit Create New from the Tab Section modal, the New Sub Form page now opens with its Title already filled in from the tab section title you just typed. The new subform then arrives with a default form section ready to go, already named to match. And when you publish back, the tab section keeps the title it started with.

The result: a multi-step, multi-typing exercise is now essentially five clicks. Everything is still editable if you want something different; it's just no longer compulsory. Works in both the classic UI and the new UI.

While it’s not the flashiest thing we've shipped, it removes a common piece of friction and repetition that configurers hit constantly. Sometimes the best improvement is the one you stop noticing.

This release extends the existing 'Allow users to search for records outside of non-mandatory filter scope' feature (previously available on Main Form Relation, Multi Main Form Relation and Subform Relation fields) to Single Person Selector, Multi Person Selector, Location Select and Organisation Select fields.

Until now, configuring these selectors involved an awkward trade-off. You could filter the list down to only the most relevant options, such as managers at the record's location, and risk the right person occasionally not being there. Or you could leave the selector wide open and force end users to search through every user, location or organisation in the account, every time.

This feature creates the middle ground. You can now configure a tightly scoped, highly relevant default list, while still giving end users a 'Search other records...' option to broaden the search when the person, location or organisation they need sits outside that scope. Mandatory filters always remain in effect, so the broadened search stays safely within the boundaries you define.

To configure this, open the field configuration for a Single Person Selector, Multi Person Selector, Location Select or Organisation Select field. Wherever the filter configuration tool is available for the field, you'll now find the 'Allow users to search for records outside of non-mandatory filter scope' checkbox. This is the same setting you may already know from MFR, MMFR and Subform Relation fields, and it behaves the same way.

The important decision is which filters you mark as Mandatory. Non-mandatory filters define the relevant default scope that users can step outside of; mandatory filters define the hard boundary that always applies. For example, on an incident form you might scope a person selector to managers at the record's location as a non-mandatory filter, while keeping a mandatory filter restricting selection to a particular role. End users would see local managers by default, and 'Search other records...' would let them find a manager from another site, but never someone outside the permitted role.

The setting defaults to disabled for all new and existing fields, so nothing changes on release until you opt in per field.

This should take a lot of the compromise out of selector configuration: tighter, more relevant lists for the everyday case, with a safe escape hatch for the exceptions.

A single subform can appear in more than one active tab section. When that subform is used in a subform collection rule set (for example, as an event multiplier in an automation), a rule set that isn't scoped by tab section will return records from every tab section the subform appears in, not just the intended one.
​
This isn't always obvious while you're building, and it's harder again to spot after the fact when an automation is quietly producing more event occurrences than expected. It can also be introduced silently: a rule set that was correctly scoped when it was written becomes ambiguous the moment someone adds that subform to another tab section, potentially long afterwards and by a different configurer who has no reason to know the rule exists. The rule builder now surfaces an informational notice whenever the situation is detected, so it can be picked up during configuration or troubleshooting rather than going unnoticed.

A subform collection rule set can return subform records attached to any module record of that type, not only the record that triggered the automation. Used as an event multiplier, an unscoped collection will multiply the event across all of them, which can produce a far higher event occurrence count than the configurer intended and make a genuine mess of a record set.

Once you've been caught by this it seems obvious, but it's almost never intuitive the first time, and it remains an easy mistake to make afterwards. We already default the Parent Module Record ID condition into these rule sets, though a default only protects a build while the configurer understands what it's for; someone who doesn't may remove it while working on something else. The rule builder now warns when that scope is missing, so the protection holds even when the reasoning behind it isn't known.
​

Lookup ordering doesn't matter in the form view — but it does when lookups are performed off screen. Automations resolve lookups in top-to-bottom field order, so a Lookup Field positioned above its Lookup Source simply won't resolve. Because nothing looks wrong on screen, this was easy to miss until an automation silently failed. The form builder now flags it.

This release lets Actions and User Involvement reports be created inside the context of a module, with Actions reports also available at the subform level.

Until now, neither report type lived inside an individual module. They existed only at account level, which meant every report was built without any awareness of the module or form you were actually interested in, and that context had to be reconstructed manually through filters each time. It worked, but it put the burden on the report builder to know exactly which filters recreated the scope they wanted, and it left the report cluttered with options that had no relevance once that scope was in place.

Living outside a module had a second consequence: these reports couldn't be copied with a build, so now that they belong to a module, they are carried with it during bundle copy.

There's also a genuine capability gain here, not just a convenience one. Both new report types support the new Limit records by Report filters, which scope a report by the records in scope in a completely separate report. That opens these report types up to far more scoping than they could ever achieve as account level reports.

This lands alongside our broader focus on actions, particularly in-form action support. As more actions are raised from within main forms and subforms, more of them live inside a specific module or form structure, and finding and reporting on them needed to become easier.

When selecting a report source, you'll now see the new Actions option at the subform level, and both Actions and User Involvements at the module level. In each case the report is scoped to that point by definition: it only ever returns records attached to that module's records, or at subform level, to completions of that form.

To add further scoping, use the Limit records by Module Report or Limit records by Subform Report filter, which narrows the report by the records in scope of a separate report. This is what unlocks the more interesting use cases, for example:

None of those were reasonably achievable before. Each is now a matter of building the underlying Module Record or Sub Form Completion report first, which many accounts will already have, and referencing it. These filters were documented in some detail in the last release notes if you need a refresher on how they behave.

This closes a long-standing gap. Actions and involvements are two of the most reported-on record types in the platform, and until now they were the only ones you couldn't approach from inside the module they belonged to. Bringing them into module context makes them easier to build, considerably more flexible to scope, and safe to promote alongside the rest of a build.

This release introduces a full rewrite of the Translations page, focused on performance and usability.

Previously, translations were presented as a single flat list — workable for small accounts, but slow to load and difficult to navigate once an account carried a large volume of translatable content. Finding one specific string often meant scrolling or scanning through everything.

The rebuilt page loads faster, organises translations logically, and gives you tools to jump straight to the text you're after. Just as importantly, the rewrite gives this area a modern foundation, making future improvements much easier to deliver.

While the immediate wins are speed and navigability, the real value here is the foundation — improvements like module or form filters are now much easier to add, so expect this area to keep getting better.

This release adds a read-only Account Details section at the bottom of the existing Account Settings area in Settings, surfacing eight identifying values: Account Name, Account Subdomain, Account URL, Account Type, Account Management Type, Release Name, Server Identifier and Interface.

Until now none of this was visible inside Donesafe. Admins had no reliable way to confirm which account or environment they were working in, and support had to run a multi-step internal lookup before troubleshooting could begin.

Some of these values, including Account Type, are drawn from our own account records rather than being set within your account. If you notice a value here that looks incorrect - for example your production site being listed as a sandbox account - please let us know so we can correct the underlying data.

Small addition, but a genuinely useful one - it takes information that was previously locked behind an internal process and puts it in front of the people who need to reference it most during support and troubleshooting conversations.

When using infinite scrolling lists, at the end of the list it now displays a message "End of Records" so users know they're at the end of the list and no longer waiting for a list to load.

Improved readability of a subform's 'Config' audit trail.