Data Engine & Custom Reports
Grab your files right from a report
What's new: A file attachment column in a report used to say Has attachment: Yes/No, and that was the whole story. Useful, but it meant opening submissions one at a time, or exporting every file and deleting the ones you didn't want, just to track down a single screenshot. Now you can add a column that shows the actual file names as clickable download links.
See it in action:
- Open a custom report and edit its columns.
- Pick a file attachment field, and you'll see a new data point named after it: <field name> files.
- Add it, save, and run the report. Single files show one filename, and multiple files show them comma-separated, each its own link.
- Click any filename and the file downloads. That's it, no more ZIP archaeology. π
Good to know:
- Your existing Has attachment: Yes/No columns are completely untouched. This is a new, separately selectable data point sitting alongside it, so nothing you've already built changes.
- It's available in the feedback, user, and project report areas.
- You can filter on it too, with a new File name filter: Contains, Does not contain, Is equal to, Is not equal to, Starts with, and Ends with. There's also Is more than and Is less than if you want to filter by how many files are attached.
- Exports come along for the ride. XLSX gives you real clickable Excel hyperlinks, and PDF shows the filenames as plain text.
- Sign-in is always required to download, in every context, including a link clicked from a distributed or emailed report. Nobody gets file access they didn't already have, and existing file security levels still apply.
Form Engine & Custom Surveys
Survey presets show up in an order that makes sense
What we fixed: When you added a survey question from a preset, presets borrowed from other surveys in the same project came through in a seemingly random order. They were actually sorted by a behind-the-scenes name you never see on screen. On top of that, every other survey in the project got dumped into one giant undivided section. We've put presets back in proper question order, and each source survey now gets its own labeled group.
See it in action:
- Open a project with at least two surveys, where one of them has questions saved as presets.
- In a different survey, add a new element and open the preset drop-down.
- Presets from other surveys are now grouped under each survey's own name, listed in the same order the questions appear in that survey. π
Good to know: This is how community question bank presets have always behaved, and project surveys just weren't following the same rule. The difference is most obvious on large projects, where a hefty preset library made the old ordering genuinely painful to work through.
Each connection stores an instance name, a base URL, an authentication scheme (basic with a username and API token, or bearer with a personal access token), and the credentials themselves, encrypted at rest. You can set up as many instances as you need, so an engineering Jira and a support Jira can happily coexist.
Every connection card has a Test button. Select it and we call Jira, then show you the list of Jira projects those credentials can actually reach, 30 at a time. It's a quick confirmation rather than a project browser, and it catches the situation that generates the most support tickets today: a token that authenticates perfectly well but lacks the access the sync needs downstream. A successful test shows a green Connected badge. A failure shows a red Connection unsuccessful with the reason in plain language, like Token expired or Could not reach Jira at this URL. Save credentials without testing them and the card sits at Untested until you do.
In a project, the authentication fields on the Jira external destination are replaced by a Connection source drop-down. It lists your community's connections alphabetically, with Project-specific connection at the bottom. Choose a community connection and the instance details display read-only, so you go straight to the JSON mapping without hunting down a token. For a one-off integration, like a contractor's Jira account, choose Project-specific connection and enter the base URL, authentication scheme, and credentials the way you do today.
Switching between the two is safe in both directions. When you move a project from its own credentials to a community connection, the original credentials stay put behind the scenes, obfuscated. If that community connection later disappears, flip back to Project-specific connection and everything you entered is still there waiting.
The old inline drop-down for inserting dynamic tags into the JSON editor is retired. The dynamic tag button now opens the same search modal you already use elsewhere in the platform. Park your cursor in the JSON, open the modal, add the tags you need, close it, then move them where they belong.
Required on Duplicate closes that gap. You can now flag specific form elements as required on duplicate, so that when a participant claims an existing issue, they're prompted to fill in just those fields before the duplicate is recorded. A focused popup appears with only the fields you've marked, nothing else, so it stays quick for the participant while capturing what your team actually needs to triage.
That captured context travels with the duplicate. Each "me too" now creates a real duplicate submission, linked to the original, with the participant's data attached. From there it flows into your comparison view, reporting, and exports, the same as any other feedback. You're triaging from what people actually reported, not from a count and a guess.
A completed phase can now be reopened with one action. The new reopen control on closed phases flips the phase's status back to active and reactivates its surveys and activities, so participants can submit data again. Every submission, response, and attachment from the prior window stays intact. The reopened phase resumes its identity rather than starting over. If you've ever spun up new artifacts to run a follow-up round (and lost the historical thread doing it), this one's for you.
Date edits on past phases let you fix what was wrong without rewriting history. Deactivated phases now show the same date-edit controls as active and pending ones. Correcting a typo, retroactively labeling a phase to match what really happened, or aligning a phase to an external timeline is now a self-service edit. Changing a deactivated phase's dates doesn't reactivate it. The phase stays deactivated unless you also choose to reopen it.
Single-day phases finally just work. Set the start date to match the end date, and the platform accepts it cleanly. The timeline view renders the phase visibly rather than as a zero-width sliver, so single-day events stay recognizable next to multi-day ones. Useful for one-day kickoffs, focused field tests, or pinpoint survey distributions that didn't quite belong in a longer window.
Becomes:
---
---



