1. New features and user-requested improvements

New features

New field event trigger: "On appear on screen"

Until now, field events could only be triggered when a field was edited. This created an important limitation in forms with conditional fields: if a field only appeared on screen after editing another field, the configured event could not reach it, because at the time of the trigger the target field did not yet exist in the interface.

With this delivery, a new trigger is now available: On appear on screen. It fires when a field transitions from hidden to visible, allowing automations to happen exactly when the field becomes accessible.

In practice, this solves scenarios like this: the "Main activity" field is conditional and only appears when the "Client type" field equals "Legal entity." When selecting the client, an event tries to automatically fill both "Client type" and "Main activity." The problem is that, at the moment the event fires, "Main activity" is not yet on screen, because "Client type" is still being filled and the visibility condition has not yet been satisfied. The result is that "Client type" is filled correctly, but "Main activity" remains empty. Now, with the "On appear on screen" trigger, it is possible to configure a second event directly on "Main activity": as soon as the field becomes visible, it is automatically filled, without needing to reopen the item or perform any manual action.

Some important details about the behavior:

• With this trigger, a field can target itself, since the trigger is based on rendering and not on editing, which eliminates the risk of loops.
• The expressions form_value, payload, and item_related are supported normally.

Want to learn how to configure field events? See the documentation.

New field event action: Reload fields

The available actions in field events (Edit, Reset, and Invalidate) did not always cover scenarios where the goal was simply to reprocess a field's rules without changing its value. Reset cleared the content, Edit replaced it, and Invalidate marked the field as invalid. There was no middle ground.

With this delivery, a new action is now available: Reload fields. It reprocesses the target field's logic (visibility conditionals, required status, validations, and dynamic filters for lists and relationships) without changing the value that is already filled in.

A usage example: a form has the "Region" field and the "Branch" field, which is conditional and only appears when "Region" is filled. A single event is configured to automatically fill both fields. However, at the moment the event fires, "Branch" is not yet on screen, because "Region" is still being filled and the visibility condition has not yet been satisfied. The result is that "Region" is filled correctly, but "Branch" remains empty. With the "On appear on screen" trigger combined with the "Reload fields" action, it is possible to configure an event on "Branch" that, as soon as it becomes visible, reloads the source field, causing the original event to be re-triggered and "Branch" to receive the value it had not been able to receive before.

Want to learn how to configure field events? See the documentation.

Improvements

Group and repeater subfields now allow width configuration

Subfields within Group and Repeater fields were limited to the default full width, with no possibility of adjustment. This restricted form layout control, especially in scenarios where it would make more sense for some subfields to occupy only half the row.

With this improvement, each subfield now has a configurable width option, with half and full choices. The control is available in both Group fields and Repeaters in list format.

Existing forms are not affected. The default width remains full, and the configuration is only applied when the configurator chooses to adjust it.

Want to learn how to configure group-type fields? See the documentation.

Want to learn how to configure repeater-type fields? See the documentation.

Expressions with fallback in field events

Field events allow using expressions to copy or calculate values automatically. One of these possibilities is defining a fallback value for when the source field is empty. For example: the expression {{form_value.field | 0}} means "use the field's value; if it is empty, use 0."

There was a problem with this feature: expressions in the {{field | value}} format did not apply the fallback correctly. When the source field was empty, the fallback value was ignored, which caused errors in the event results.

The fix ensures that the {{field | value}} fallback structure works reliably, regardless of the field type or the defined fallback value. In practice, this eliminates the need to create auxiliary fields or manual conditionals to handle empty values in field events.

Want to learn how to configure field events? See the documentation.

2. General product evolutions and fixes

Improvements

Reorganization of the field creation sidebar

The field creation sidebar (side panel) received organizational adjustments to make it easier to locate available field types. Separators with centered titles were added to group fields by category, and the order of basic configuration fields was reorganized to follow a more logical sequence.

The change applies to the creation and editing of all field types.

Want to learn more about field configuration? See the documentation.

Bug fixes

Error when creating items via relationship folder

When registering an item through a relationship folder (such as proceedings, payments, and hearings), the system displayed a red error message after saving, even when the item was saved successfully in the target category. The item did not always appear in the relationship folder: for some users, refreshing the page was enough to see it; for others, it was necessary to go to the items screen of the target category, where the item was actually registered.

The fix eliminates the false error and adjusts the creation flow via folder to ensure that the item and its data are correctly associated and persisted, reflecting immediately in the folder listing without the need for a refresh.

Created categories not appearing in the listing.

When creating a new category and confirming the registration, the screen updated, but the newly created category did not appear in the listing, giving the impression that the registration had failed. This could lead to repeated creation attempts.

The fix ensures that, after saving, the listing immediately reflects the new category, without the need for a manual refresh.