Feature Requests

For media exports, there is currently some file naming capability through the Media File Name field (for example, using {title} as shown in the export dialog). However, the available options appear to be limited and do not provide the flexibility needed to create meaningful, project-specific file names and naming conventions. In addition, for other export formats, we have not found a way to specify the output file name before downloading. Once the export is generated, the resulting file names can be difficult to identify, and manually renaming multiple exported files afterward becomes time-consuming and error-prone. It would be extremely helpful if users could: Define custom file names for all export types. Combine multiple fields and static text when naming media files. Preview the resulting file name before export. Rename export files prior to download. Apply consistent naming conventions across media and non-media exports. Support batch renaming of exported media files using selected fields, templates, or naming rules. Include options such as Project Name, Record ID, Date, Location, and other metadata when generating file names. For projects involving large numbers of photos, records, and deliverables, robust file naming and batch renaming capabilities would significantly improve organization, reduce manual effort, and streamline downstream data management. I am also submitting this as a formal Feature Request because I believe it would provide substantial value to many field users and organizations managing large datasets. Thank you for considering this enhancement.

To have the ability to change what the symbol looks like when a point is placed. A good example is utility structures. At this time this is preventing us from expanding our use

Clicking on an app name in the app list should open the records page - the new update goes into the editor or the app dashboard depending on your role

Please add a function in record view to duplicate a record. This is available from mobile but not in the web browser

It would be great from a data security point of view to be able to enforce 2fa for all logins. Preferably google authenticator compatible ones.

For example, instead of a dot allow customization that would let me change it to a triangle or a square. To be able to distinguish records with specific criteria better in the map view. Like I want my MSTs to visually look different than my Handholes, besides just changing the status color.

Just your usual dark mode option for the app. We work at night doing surveys for animals, the dark screen is a lot easier on the eyes.

A tool that would allow straight-line measurements between points and between points and elements of background layers. This is a consistent complaint from our field crews about the app because not having one is hindering their in-field decision-making abilities.

Suggestion for a future release. Incorporate the capability to organize apps into folders or contianers so that like apps can be grouped together. For example, i might create a folder or container called vehicle inspections. inside that folder i would have my pickup truck inspection app, line truck inspection app, etc.. Would be an easy way to keep like or similar apps organized.

When a visibility rule is applied to a field in App Builder, there's a checkbox controlling whether previously entered data remains visible when the rule hides the field. This currently defaults to unchecked. The impact: field technicians lose sight of historic data in the record view. The only workaround is opening the History section under View Records and scrolling through change logs, which is impractical for field crews working on mobile devices in time-pressured environments. This default catches app builders out because the consequence isn't obvious at design time, and it only surfaces later as missing data reported from the field. We hit this across our smart metering programs (utility sector, Australia) and it caused genuine operational issues before we traced the cause. Request: change the default so historic data remains visible when a visibility rule is applied (checkbox checked by default), or remove the hide-historic-data behaviour entirely. If there's a legitimate use case for hiding prior values, the safer default is still to show them, with hiding as the opt-in.