QA Release Date: June 03 2025

Production Release Date: June 17 2025

2025.6 Release Highlights

It’s 85 degrees and sunny here in Detroit as we approach summer - and things are also heating up at Fuuz HQ as we approach the end of Q2. We’ve got some exciting new features to highlight with the 2025.6.0 release - read on to learn more!

Custom Fields

This month’s release features significant new functionality to support simplified app customization: user-configurable Custom Fields!

First, some background. You might wonder why an app development platform with a schema designer needs “custom fields” at all - isn’t every field in an app technically a “custom” field? For customers who are developing their own apps, that’s true: they’d often be better served by adding new first-class fields to data models. However, as our ecosystem of partner- and Fuuz-built apps grows, we’ve found that customers needed a simple, error-proof way to store additional pieces of data on records inside these apps that doesn’t involve modifying an app’s schema or deploying data models. It should be simple and quick to add a note field, reference value, or piece of data about an integration. Our new Custom Fields feature addresses that use case!

There are two main parts to the Custom Fields system: custom field configuration, and the screen designer elements which allow custom fields to appear automatically in the UI once added. We’ll start with the configuration, which happens on the Data Model Custom Fields screen.

To add a custom field, an administrator simply needs to click the + button, select one or more data models to add fields to, select a type, and fill in a label and description. The moment they hit + on the dialog, the field will be added to the GraphQL API!

                              

There are lots of field types available for custom fields, and we plan to add a few that are currently missing, like Rich Text and Duration types.

                                                              

Okay, great - we’ve added a field and it’s available through the API for use in a data mapping or external API call… but your end users don’t interact with the field through data mappings. That’s where the Custom Field screen elements come in! There are two of these: a Custom Fields Input element and a Custom Fields Table Column Data element. These elements will automatically display all custom fields for the selected data model as grouped table columns or as a group of form inputs, as long as those custom fields are set to Show On Forms or Show On Tables. App designers simply need to place the Custom Fields input or column where they’d like the custom fields for a record to appear, and they’ll automatically show up as administrators add custom fields.

                                                                       

To make things even easier, there’s a toggle (automatically enabled) to generate the custom fields input or table column during screen generation. As you add lots of fields, you might find that some organization is in order - that’s what the optional Group Label field is for on the Custom Field. Any fields with the same Group Label will be grouped in a collapsing section/column with that label.

                                                                                           

There are a few small enhancements we plan to make to this system in coming releases - more field types, more UI configuration options, support for sorting query results on custom fields, and support for custom field inputs in create/edit dialogs - but we’re happy to have this new system capability out and ready to use!

Data Flow Log Level Configuration

The 2025.6 release includes a new feature to simplify transitioning data flows from the “development” to “production” stages, as well as debugging those flows once they’re on production: Data Flow Log Level configuration.

It’s very common to place Log nodes throughout data flows during development to track the progress of data through a flow and to simplify debugging when unexpected behavior occurs. Typically, though, those Log nodes are overkill for a production environment: they add a lot of noise to the Data Flow Logs table and put additional load on the system for minimal value. Historically, the solution to this would be to update flows before packaging for production to remove any superfluous Log nodes - but that’s tedious and error-prone, and then the logs aren’t available when you do need them. In practice, the Log nodes are often left in place, resulting in potentially millions of verbose debug and trace logs that no one ever looks at.

With this month’s release, we’ve added a new Log Level configuration to the data flow header which will skip logging any messages at a level below the selected verbosity. This means app builders can use lots of Log nodes set up at the Debug or Trace log level during development, then set the log level to Info on production so only the important informational logs are retained. If those debug logs are needed, the log level can be changed at any time to start logging them again!

For backwards compatibility, the default log level for all flows without a log level defined is “trace” - the most verbose level, equal to the behavior before this feature release. I’d recommend updating the log level to Info on any data flows that have a large number of debug logs to help eliminate some of that noise and make it easier to find the important logs; a future release may set the default log level to Info when packages are installed into production environments to streamline this process.

Other Highlights

Duration Field Type Improvements

This month’s release includes some improvements to the Duration scalar in our GraphQL API. Previously, Duration scalars always operated as ISO 8601 duration strings; that was handy as a compact and portable representation, but made it difficult (or, in some cases, impossible) to leverage API features like sorting, filtering, and aggregation.

With the 2025.6 release, Duration fields now store both a string value and an integer number of milliseconds; users can provide either when setting a Duration field in a mutation, and can use a field-level argument to request a Duration as either one. We’ll be adding a new predicate to support filtering duration fields soon!

                                                                                                          

Font Size Configuration

Finally, the June release includes new Font Size configuration options for text-style input screen elements, including Text, Number, and Color. You can now independently configure the label and data font sizes - handy for mobile screens or wallboards where a larger display size is helpful!

                                                                                                                           

Full Release Notes: 2025.6.0

Data

GraphQL API

• Added user-configurable Custom Fields and matching column/input screen elements

• Updated Duration scalar type to allow users to provide and request values as either an ISO duration string or an integer number of milliseconds

Data Management

• Added a 5-year TTL to export history records

• Fixed a bug that could cause the data export service to crash while completing an export

Document Designer

• Added a currentDeploymentId field to match the field name used in other versioned models

DevOps

• Updated base Docker images to latest available for Node 20

Integration

Device Gateway

• Updated profobufjs package dependency to latest version

• Updated EthernetIP driver to address a potential socket leak

• Updated $executeDeviceFunction, $executeDeviceGatewayFunction, and $executeFlow bindings so return formats align with usage elsewhere in the platform

Orchestration

Data Flow Designer

• Added Data Flow Log Level configuration, allowing the log level of a flow to be changed without deployments

Transformations

• Upgraded url-parse package dependency to latest version

User Interface

Framework

• Converted frontend HOC and utility libraries to Typescript

• Added a framework for UI integration tests

• Added a generic “screen runner”, making any deployed screen available through a standardized URL path of /screen/:screenId

Components

• Fixed an issue causing some Timeseries charts and visualizations to fail to render

Screen Designer

• Added an option to Select inputs to always re-query the available options when the select list is opened

• Added Label Font Size and Data Font Size configuration options on text-style inputs

• Updated styling on the Rich Text display element so it correctly fills the available space

• Fixed an error that could occur when configuring dynamic colors on button groups

• Fixed an error that could occur with dynamic properties (e.g. additionalFilter) supplied to Select inputs